openstack and Dragonflow DNS

为什么会有这篇文章,这篇文章总结了openstack和dragonflow有关DNS的技术点,search 和 domain 经常出现在dns配置当中,于是就借此机会来个大总结。详细见后文

默认情况下的三层云主机的DNS

云主机内部的DNS配置,如下图所示

针对于linux系统DNS配置位于/etc/resolv.conf

默认openstack配置建立的云主机DNS指向DHCP服务器的地址,云主机内所有DNS请求流量会发给网络节点的DHCP namespace,该DHCP namespace中含有一个53端口dnsmsq服务,接收到该DNS请求后

会向已经配置的DNS服务器转发DNS请求,如果配置的外网DNS服务器不可达则,该53端口的DNS代理服务向云主机回复refused,告知云主机无法获取DNS

默认情况下的二层云主机的DNS

在创建二层云主机子网的时候,往往指定DNS服务器地址,这样通过该DHCP获取ip的云主机DNS会设置成配置的DNS服务器地址

Dragonflow DNS设置

通过研究openstack DNS设置情况可知,云主机内部的DNS解析地址是根据DHCP服务器获取的,如果没有直接指定就使用DHCP服务器地址作为DNS解析地址。

Dragonflow 支持分布式DHCP,其默认DNS发生了些变化,dragonflow核心思想是为了去除集中式,拥抱分布式。所以DHCP服务器分布到不同HOST节点上,还去除了dnsmsq服务

它的默认配置可以在dragonflow配置中[df_dhcp_app]指定,当然如果此时建立子网时候也配置了DNS服务器地址,按照子网配置为准。在子网没有配置DNS服务器时,就采用dragonflow配置的df_dns_servers服务器

如果没有做配置draonfow配置就按照drafonflow代码中指定的默认配置,默认时8.8.8.8 和8.8.4.4;当然在中国建议改成114.114.114.114

DNS疑惑知识点

关于DNS 云主机常用的配置会在下面进行解释,该解释主要通过实验方式;且会将实验数据也进行记录,并分析,详见下文

search openstacklocal 是什么?

背景

在/etc/resolv.conf 配置如下

1
2
3
#     DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN
search openstacklocal
nameserver 114.114.114.114

试验1:

1
2
stack@p-controller:~/dragonflow/dragonflow/controller/apps$ ping ab
ping: unknown host ab
1
2
3
4
5
listening on br-ex, link-type EN10MB (Ethernet), capture size 262144 bytes
19:39:53.287070 08:00:27:12:3f:5b > d6:aa:3e:a1:1c:bb, ethertype IPv4 (0x0800), length 77: 192.168.56.155.38054 > 114.114.114.114.53: 16466+ A? ab.openstacklocal. (35)
19:39:53.295123 d6:aa:3e:a1:1c:bb > 08:00:27:12:3f:5b, ethertype IPv4 (0x0800), length 152: 114.114.114.114.53 > 192.168.56.155.38054: 16466 NXDomain 0/1/0 (110)
19:39:53.295365 08:00:27:12:3f:5b > d6:aa:3e:a1:1c:bb, ethertype IPv4 (0x0800), length 62: 192.168.56.155.42830 > 114.114.114.114.53: 57622+ A? ab. (20)
19:39:53.302207 d6:aa:3e:a1:1c:bb > 08:00:27:12:3f:5b, ethertype IPv4 (0x0800), length 137: 114.114.114.114.53 > 192.168.56.155.42830: 57622 NXDomain 0/1/0 (95)

说明:域名ab 没有点,认为其不是域名的可能性大些,因为配置了openstacklocal,所以先添加后缀,进行查找,查找失败后以域名的方式再次进行查找

试验2:

1
2
stack@p-controller:~/dragonflow/dragonflow/controller/apps$ ping ab.c
ping: unknown host ab.c
1
2
3
4
19:47:07.151911 08:00:27:12:3f:5b > d6:aa:3e:a1:1c:bb, ethertype IPv4 (0x0800), length 64: 192.168.56.155.46028 > 114.114.114.114.53: 14292+ A? ab.c. (22)
19:47:07.159660 d6:aa:3e:a1:1c:bb > 08:00:27:12:3f:5b, ethertype IPv4 (0x0800), length 139: 114.114.114.114.53 > 192.168.56.155.46028: 14292 NXDomain 0/1/0 (97)
19:47:07.159833 08:00:27:12:3f:5b > d6:aa:3e:a1:1c:bb, ethertype IPv4 (0x0800), length 79: 192.168.56.155.57417 > 114.114.114.114.53: 10459+ A? ab.c.openstacklocal. (37)
19:47:07.167700 d6:aa:3e:a1:1c:bb > 08:00:27:12:3f:5b, ethertype IPv4 (0x0800), length 154: 114.114.114.114.53 > 192.168.56.155.57417: 10459 NXDomain 0/1/0 (112)

说明:ab.c被认为是域名,所以先进行查找,如果无法查找到ip后,加上openstacklocal继续进行查找

试验3

1
2
stack@p-controller:~/dragonflow/dragonflow/controller/apps$ ping ab.
ping: unknown host ab.
1
2
19:48:21.188557 08:00:27:12:3f:5b > d6:aa:3e:a1:1c:bb, ethertype IPv4 (0x0800), length 62: 192.168.56.155.45154 > 114.114.114.114.53: 27691+ A? ab. (20)
19:48:21.196942 d6:aa:3e:a1:1c:bb > 08:00:27:12:3f:5b, ethertype IPv4 (0x0800), length 137: 114.114.114.114.53 > 192.168.56.155.45154: 27691 NXDomain 0/1/0 (95)

说明: ab. 以. 结尾,则被认为是域名,不需要继续在域openstacklocal 查找,所以不会继续添加.openstacklocal. 后继续dns查询

试验4:

1
2
3
4
5
stack@p-controller:~/dragonflow/dragonflow/controller/apps$ ping www.qq.com
PING www.qq.com (180.163.26.39) 56(84) bytes of data.
64 bytes from 180.163.26.39: icmp_seq=1 ttl=50 time=7.38 ms
64 bytes from 180.163.26.39: icmp_seq=2 ttl=50 time=5.52 ms
64 bytes from 180.163.26.39: icmp_seq=3 ttl=50 time=5.23 ms
1
2
3
4
19:49:18.360814 08:00:27:12:3f:5b > d6:aa:3e:a1:1c:bb, ethertype IPv4 (0x0800), length 70: 192.168.56.155.46482 > 114.114.114.114.53: 35785+ A? www.qq.com. (28)
19:49:18.368714 d6:aa:3e:a1:1c:bb > 08:00:27:12:3f:5b, ethertype IPv4 (0x0800), length 86: 114.114.114.114.53 > 192.168.56.155.46482: 35785 1/0/0 A 180.163.26.39 (44)
19:49:18.377071 08:00:27:12:3f:5b > d6:aa:3e:a1:1c:bb, ethertype IPv4 (0x0800), length 86: 192.168.56.155.40497 > 114.114.114.114.53: 55908+ PTR? 39.26.163.180.in-addr.arpa. (44)
19:49:18.383946 d6:aa:3e:a1:1c:bb > 08:00:27:12:3f:5b, ethertype IPv4 (0x0800), length 145: 114.114.114.114.53 > 192.168.56.155.40497: 55908 NXDomain 0/1/0 (103)

说明:www.qq.com 被认为是域名,先进行查找,结果获取到了ip,所以就没有继续添加.openstacklocal. 后继续dns查询

总结:

如果域名无法查询到ip,配置search 后,会继续添加配置的serach 域再次查找

如果是域名称(没有.),则先加上serach 后缀进行查找,如果无法查找到结果后,直接将该域最为终极域名进行查找

如果查找到域名,就不再加上serach 后缀进行查找了

domain openstacklocal是什么?

背景

在/etc/resolv.conf 配置如下

进行过如下试验,对域名 ab ab. .ab ab.c 进行试验

实验1: ab

###

  • 解析ab
1
2
stack@p-controller:~/dragonflow/dragonflow/controller/apps$ ping ab
ping: unknown host ab
  • 抓包结果
1
2
3
4
5
6
7
stack@p-controller:~$ sudo tcpdump -i br-ex -ne -a udp
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on br-ex, link-type EN10MB (Ethernet), capture size 262144 bytes
19:22:27.959705 08:00:27:12:3f:5b > d6:aa:3e:a1:1c:bb, ethertype IPv4 (0x0800), length 77: 192.168.56.155.39978 > 114.114.114.114.53: 58424+ A? ab.openstacklocal. (35)
19:22:27.969578 d6:aa:3e:a1:1c:bb > 08:00:27:12:3f:5b, ethertype IPv4 (0x0800), length 152: 114.114.114.114.53 > 192.168.56.155.39978: 58424 NXDomain 0/1/0 (110)
19:22:27.969777 08:00:27:12:3f:5b > d6:aa:3e:a1:1c:bb, ethertype IPv4 (0x0800), length 62: 192.168.56.155.42798 > 114.114.114.114.53: 30556+ A? ab. (20)
19:22:28.096722 d6:aa:3e:a1:1c:bb > 08:00:27:12:3f:5b, ethertype IPv4 (0x0800), length 137: 114.114.114.114.53 > 192.168.56.155.42798: 30556 NXDomain 0/1/0 (95)
  • 抓包结果解析说明

如上,抓取的数据包所示,配置了domain openstacklocal , 因为该查询的名称最后没有小数字点,就自动补充 .openstacklocal. 到ab 的末尾

实验2: 解析ab.

  • 解析ab.
1
2
stack@p-controller:~/dragonflow/dragonflow/controller/apps$ ping ab.
ping: unknown host ab.
  • 抓包结果
1
2
3
19:31:43.677121 08:00:27:12:3f:5b > d6:aa:3e:a1:1c:bb, ethertype IPv4 (0x0800), length 62: 192.168.56.155.39224 > 114.114.114.114.53: 17912+ A? ab. (20)
19:31:43.678045 66:2f:fa:40:17:6e > 52:54:00:12:35:00, ethertype IPv4 (0x0800), length 62: 1.1.1.14.39224 > 114.114.114.114.53: 17912+ A? ab. (20)
19:31:43.685143 d6:aa:3e:a1:1c:bb > 08:00:27:12:3f:5b, ethertype IPv4 (0x0800), length 137: 114.114.114.114.53 > 192.168.56.155.39224: 17912 NXDomain 0/1/0 (95)
  • 抓包结果解析说明

如上,抓取的数据包所示,虽然配置了domain openstacklocal , 但是解析的域名 ab. 末尾含有 “.” ,因此不会给其末尾加上 .openstacklocal.

当然也尝试过 .ab ab.c 这两种情况,一种情况 “.” 在首部 ,一种情况 ‘.’ 在中间, “.”放在首部,域名无法解析

在中间情况和试验1 相同

总结

“domain”指定本地的域名,如果查詢時的名称沒有末尾包含小數點,自动补充domain 带到末尾

如果多个nameserver 执行顺序如何,主DNS 异常,多久能切换到备用DNS ?

使用cirros系统进行测试工作,这种情况下,cirros云主机会先使用第一个nameserver地址,如果无法联通,尝试约5s后,使用第二个nameserver地址,所以应该使得nameserver中所有的dns列表均是可用的dns

所以nameserver中配置的域名一定要是高可用的,且不能存在废弃的域名解析,假设,你在DNS首位配置了一个无法解析的DNS服务器地址,虽然第二个DNS服务器可用,针对于linux 那么你每次DNS解析

要花费5s+ 的时间,这就给用户带来了非常差的上网体验