背景：
智能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
zhxfei@zhxfei-HP-ENVY-15-Notebook-PC:~$ 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
zhxfei@zhxfei-HP-ENVY-15-Notebook-PC:~$ 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目前还不支持，但是从最新的bind-utils中的dig工具已经支持了此项的调试，无需编译就可使用。具体使用见后面的测试
PS：就小的看来HTTPDNS会越来越火，DNSPod也推出了相应的方案，听说现在已经集成到一部分app 的SDK里面了，做为正常DNS解析失常的备用方案。有时间研究下另开一篇胡说八道
环境搭建（ADNS测试）
编译bind
edns-client-subnet（下简称ecs）其现在还没有正式被bind支持。需要对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作为用户所在的网段：
zhxfei@zhxfei-HP-ENVY-15-Notebook-PC:~$ 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作为用户所在的网段
zhxfei@zhxfei-HP-ENVY-15-Notebook-PC:~$ 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
