最新消息:

编译bind9支持edns-client-subnet

dns admin 270浏览 0评论
智能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

转载请注明:热门技术 » 编译bind9支持edns-client-subnet

发表我的评论
取消评论
表情

Hi,您需要填写昵称和邮箱!

  • 昵称 (必填)
  • 邮箱 (必填)
  • 网址