编译bind9支持edns-client-subnet

智能DNS智能否

众所周知，DNS解析是我们访问internet的“第一跳”，若域名解析失常那是一件很可怕的事情。所以这一步走的需要更快，更稳。现在业界普遍采用了智能DNS来实现，其原理就是根据自身所保存的表项的ip和用户的所在位置对应来就近分配服务器的主机记录给用户。智能DNS现在用途很广泛，如：在CDN网络中，根据智能DNS实现GSLB全局负载均衡，就近分发可请求的缓存服务器（也有可能是下级GSLB的site ip）；在跨多数据中心组网，其也很好的实现异地多活。等等。但是智能DNS真的是完美，智能吗？在DNS解析中，帮我们出去向根递归的是LDNS，如果我们的LDNS和本地用户不在一个地理位置，那么用户则会得到一个LDNS所在位置最近的IP地址，例如我们很多人喜欢吧LDNS设置为8.8.8.8（google的公开DNS，稳定），这样我们智能DNS则会让用户得到一个美国服务器IP这显然是不合理的。

做个小实验

先将LDNS指定google的8.8.8.8，再将LDNS指定为学校的DNSserver

$ dig -t A www.alibaba.com @8.8.8.8
 
; <<>> DiG 9.10.3-P4-Ubuntu <<>> -t A www.alibaba.com @8.8.8.8
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 3653
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1
 
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;www.alibaba.com.	IN	A
 
;; ANSWER SECTION:
www.alibaba.com.	164	IN	CNAME	www.gds.alibaba.com.
www.gds.alibaba.com.	114	IN	A	198.11.132.23
 
;; Query time: 201 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: Sun Jul 24 22:04:38 CST 2016
;; MSG SIZE rcvd: 82

 

耗时201ms，解析结果为198.11.132.23，所在地美国，GeoIP: San Mateo, California, United States

$ dig -t A www.alibaba.com @202.119.160.11
; <<>> DiG 9.10.3-P4-Ubuntu <<>> -t A www.alibaba.com @202.119.160.11
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 18762
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 2, ADDITIONAL: 1
 
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;www.alibaba.com. IN A
 
;; ANSWER SECTION:zhiwei
www.alibaba.com. 300 IN CNAME www-cn.gds.alibaba.com.
www-cn.gds.alibaba.com. 120 IN A 106.11.62.61
 
;; AUTHORITY SECTION:
gds.alibaba.com. 6460 IN NS gdsns1.alibaba.com.
gds.alibaba.com. 6460 IN NS gdsns2.alibaba.com.
 
;; Query time: 34 msec
;; SERVER: 202.119.160.11#53(202.119.160.11)
;; WHEN: Sun Jul 24 22:08:59 CST 2016
;; MSG SIZE rcvd: 127

 

耗时34ms，解析结果为106.11.62.61，所在地上海，GeoIP: Hangzhou, Zhejiang, China

solution

面对这个情况，现在我知道的有以下两种解决方案：

• HTTPDNS 来源于腾讯，将DNS请求借由HTTP来向HttpDNS接口发起查询。于绕过了运营商的LocalDNS，用户解析域名的请求通过Http协议直接透传到了腾讯的HttpDNS服务器IP上，用户在客户端的域名解析请求将不会遭受到运营商解析转发，DNS污染，劫持，出口多NAT等等困扰
• ECS：来源于google，对EDNS0的扩展。在DNS请求的包中插入client的网段地址带到ADNS上，ADNS收到ECS段位的包根据client的IP去进行DNS记录匹配，google的公开name server已支持，此方式需要LDNS和ADNS（授权域名服务器）同时支持。现在大多数有CDN的厂商都支持了edns-client-subnet，但是运营商的LDNS都不支持，所以现在还是为正式被广泛使用。原生的bind目前还不支持目前只有在最新的bind9.11才被支持，而一般较新版本的bind-utils中的dig工具已经支持了此项的调试，无需编译就可使用。具体使用见后面的测试

PS：就小的看来HTTPDNS会越来越火，DNSPod也推出了相应的方案，听说现在已经集成到一部分app 的SDK里面了，做为正常DNS解析失常的备用方案。有时间研究下另开一篇胡说八道

环境搭建（ADNS测试）

编译bind

edns-client-subnet（下简称ecs）其现在还没有正式被bind9支持，但是bind9给出了实验版本。需要对bind重新编译，ISC上有支持ecs authoritative的源码，git克隆到到本地编译即可。

完成的环境：

[root@localhost ~]# uname -a
Linux localhost.localdomain 2.6.32-431.el6.x86_64 #1 SMP Fri Nov 22 03:15:09 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux

 

安装

git clone https://source.isc.org/git/bind9.git
cd bind9/
./configure
make && make install

设置ECS elements

设置bind的主配置文件，编辑/etc/named.conf：

[root@localhost ~]# vim /etc/named.conf
acl localnet{
  ecs 120.0.0.1/24;
};		
acl externet{
  any;
};
options {
  directory "/var/named";		# 指定bind主目录
};
view internal {		#intermal视图配置
  match-clients { localnet; };	#只有匹配localnet的用户进入internal域解析
  recursion yes;		#允许递归
  zone "." IN {	#根域解析
    type hint;	#区域类型为提示域
    file "named.ca";	#指定根域的解析文件，可用dig -t a .>/var/named/named.ca生成
  };
  
  zone "zhxfei.com" IN {
    type master;
    file "zhxfei.com.localnet.zone";	#指定区域解析文件
    allow-transfer { none; };
  };
};
view external {
  match-clients { externet; }; #不匹配ecs的用户进入此视图解析	
  recursion no;	#不允许递归
  zone "." IN {	#根域解析
    type hint;	#区域类型为提示域
    file "named.ca";	#指定根域的解析文件，可用dig -t NS .>/var/named/named.ca生成
};
  
  zone "zhxfei.com" IN {
    type master;	#指定bind对这个区域的解析角色
    file "zhxfei.com.externnet.zone";	#指定区域解析文件
    allow-transfer { none; };	#不允许区域传送
  };
};

 

如上，在ADNS上的bind上，写acl来匹配ecs对应的ip，来看其作用：

ACLs can now include “ecs” elements which specify
an address or network prefix; if an ECS option is
included in a DNS query, then the address encoded
in the option will be matched against “ecs” ACL
elements.
Also, if an ECS address is included in a query,
then it will be used instead of the client source
address when matching “geoip” ACL elements. This
behavior can be overridden with “geoip-use-ecs no;”.
When “ecs” or “geoip” ACL elements are used to
select a view for a query, the response will include
an ECS option to indicate which client network the
answer is valid for.

简单翻译下：即在ADNS上如果ECS地址包含在查询内，它将使用其代替源IP进行解析查询（在没有使用“geoip-use-ecs no的情况下”），并将ECS 的网段地址写进response报文中，回复给LDNS，表明采用了ecs解析。

查询过程是这样的：

在我写的规则中，ACL localnet只有120.0.0.1/24这个网段，只有在收到的query报文中有ecs段位且匹配到了这个ecs的网段，才能命中internal视图

测试准备

通过 named 来开启bind进程，之后通过查看日志检查bind是否正常启动，以及端口是否开放正常

named
tail /var/log/message
netstat -tunlp | grep named

 

可以看到bind和rndc开放正常：

[root@localhost ~]# netstat -tunlp | grep named
tcp        0      0 172.16.130.129:53           0.0.0.0:*                   LISTEN      2124/named          
tcp        0      0 127.0.0.1:53                0.0.0.0:*                   LISTEN      2124/named          
tcp        0      0 127.0.0.1:953               0.0.0.0:*                   LISTEN      2124/named          
tcp        0      0 :::53                       :::*                        LISTEN      2124/named          
tcp        0      0 ::1:953                     :::*                        LISTEN      2124/named          
udp        0      0 172.16.130.129:53           0.0.0.0:*                               2124/named          
udp        0      0 127.0.0.1:53                0.0.0.0:*                               2124/named          
udp        0      0 :::53                       :::*                                    2124/named

 

验证结果

在本地用dig调试

用200.0.0.1/24作为用户所在的网段：

$ dig -t A www.zhxfei.com @172.16.130.129 +subnet=200.0.0.1/24
 
; <<>> DiG 9.10.3-P4-Ubuntu <<>> -t A www.zhxfei.com @172.16.130.129 +subnet=200.0.0.1/24
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 11779
;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 2
;; WARNING: recursion requested but not available
 
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
; CLIENT-SUBNET: 200.0.0.0/24/0
;; QUESTION SECTION:
;www.zhxfei.com. IN A
 
;; ANSWER SECTION:
www.zhxfei.com. 86400 IN A 1.1.1.1
 
;; AUTHORITY SECTION:
zhxfei.com. 86400 IN NS ns.zhxfei.com.
 
;; ADDITIONAL SECTION:
ns.zhxfei.com. 86400 IN A 172.16.130.129
 
;; Query time: 0 msec
;; SERVER: 172.16.130.129#53(172.16.130.129)
;; WHEN: Mon Jul 25 01:00:43 CST 2016
;; MSG SIZE rcvd: 103

 

用120.0.0.1/24作为用户所在的网段

$ dig -t A www.zhxfei.com @172.16.130.129 +subnet=120.0.0.1/24
 
; <<>> DiG 9.10.3-P4-Ubuntu <<>> -t A www.zhxfei.com @172.16.130.129 +subnet=120.0.0.1/24
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 21300
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 2
 
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
; CLIENT-SUBNET: 120.0.0.0/24/24
;; QUESTION SECTION:
;www.zhxfei.com. IN A
 
;; ANSWER SECTION:
www.zhxfei.com. 86400 IN A 10.0.0.1
 
;; AUTHORITY SECTION:
zhxfei.com. 86400 IN NS ns.zhxfei.com.
 
;; ADDITIONAL SECTION:
ns.zhxfei.com. 86400 IN A 172.16.130.129
 
;; Query time: 0 msec
;; SERVER: 172.16.130.129#53(172.16.130.129)
;; WHEN: Mon Jul 25 01:00:53 CST 2016
;; MSG SIZE rcvd: 103

 

验证如上，匹配到ecs elements的查询替代了源172.16.130.1的解析结果

抓包

附带抓包结果，有兴趣看一下：
第一次解析


第二次解析

其他

可能出现的问题

实验的时候可能会出现这样的回复：

原因是DNS server的防火墙策略将query REJECT,关闭iptables即可

f5不支持edns-client-subnet

现在很多智能DNS都做在了专业的应用交付设备上，常用的有三款：F5的GTM（广域网流量管理器），citrix的NetScaler，还有radware linkproof。
其中F5的BIG-IP系列的GTM独占鳌头。但是遗憾的是不支持edns-client-subnet，即当其收到带有ecs段位的报文，会将请求drop掉。
详细情况请看sol16240: The BIG-IP system treats as malformed and drops DNS queries containing the EDNS Client subnet option