关于01月23日全国范围内DNS污染，域名解析故障的根源，资深的IT人士都知道原因是什么，并非国家
互联网应急中心发出的遭受攻击一说。
因此这里介绍一下DNS服务器的查询原理，也就是递归查询和迭代查询。
下图比较简明的描述了DNS服务器为客户端解析主机www.163.com的全过程.
根域名服务器:是互联网域名解析系统（DNS）中*别的域名服务器，全球有386台根服务器,被编号为A到M共13个标号。中国北京有两台编号为F的根服务器镜像，编号为I、J、L的各一，共5台镜像，在香港有A、F、I、J、L五台根服务器镜像，全部借由任播（Anycast）技术，所有编号相同的根服务器都是同一个IP，386台根服务器总共只使用了13个IP，因此可以抵抗针对其所进行的分布式拒绝服务攻击(DDoS)。
根域名服务器列表: (a-m.root-servers.net)
客户端通过域名访问站点时，必须要有DNS服务器解析到指定的IP地址上，才能进行下一步的
访问。客户端发起访问请求后，首先检查本地host文件，检查是否存在对应的IP映射关系，如果有则
直接通过映射的IP进行访问；如果没有则将请求发送给首选的DNS服务器。
客户端和DNS服务器之间使用的是递归查询，而DNS服务器之间使用的是迭代查询.
递归查询时要求所请求的DNS服务器应答给客户端所请求的域名和IP的映射关系;
迭代查询时所请求的DNS服务器应答给客户端的不一定是域名和IP地址的映射关系，也可以是另一台
DNS服务器，让客户端再将请求发送到另一台DNS服务器.
下面按上图根据实例介绍DNS解析全过程.
客户端发起访问请求www.163.com:
1.查看本地hosts文件，发现没有www.163.com IP 映射关系，将请求发送给本地DNS服务器
----递归查询----
2.本地DNS服务器不包含163.com的权威域，不存在对应的www记录，因此将请求转发到根域名服务器
(假如 a.root-servers.net.)
3.根域名DNS服务器会返回负责.com域解析的服务器(假如 a.gtld-servers.net.)给本地DNS服务器，
本地DNS服务器再将请求发送给 a.gtld-servers.net
4..com域名服务器只能返回负责163.com域的解析服务器(如 ns1.nease.net.)给本地DNS服务器,本地
DNS服务器再将请求发送给ns1.nease.net.
5.由ns1.nease.net.域名服务器返回www.163.com 的 IP映射关系给本地DNS服务器
(2-5过程)----迭代查询----
6.本地DNS服务器将结果保存到本地缓存，并保持TTL时间，同时将结果应答给客户端.
----递归查询---- ----查询结束----
7.当其他客户端再次向本地DNS服务器查询www.163.com时，在TTL时间内，本地DNS服务器不再向根
域名服务器转发请求，而是直接从缓存中读取数据应答给客户端. 如果已经超过TTL时间，则本地DNS
服务器会再次经历一次上诉2-6的过程.
本地DNS服务器在代替客户端向其他服务器查询时，客户端完全处于等待状态。
递归查询时，返回的结果只有两种:查询成功或查询失败.
迭代查询，又称作重指引,返回的是最佳的查询点或者主机地址.
了解了以上原理,就可以很容易的判断DNS解析故障了，甚至于前日的全国DNS污染问题。
当然了解原理后，还需要了解相关的工具和命令: dig,nslookup,host等.其中以dig命令的功能最为强大和灵活.
dig命令典型应用形如
dig @server name type
@server: 指定域名服务器
name:指定查询请求资源的域名
type:指定查询类型，如A、CNAME、SRV、MX、SIG等，如果不指定type，默认为A
比如:
默认情况下DNS使用UDP查询，我们使用查询选项设置为TCP查询
[shizhenning@zabbix ~]$ dig @8.8.8.8 163.com +tcp; <<>> DiG 9.3.6-P1-RedHat-9.3.6-20.P1.el5_8.6 <<>> @8.8.8.8 163.com +tcp
; (1 server found)
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 36041
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;163.com. IN A
;; ANSWER SECTION:
163.com. 277 IN A 123.58.180.8
163.com. 277 IN A 123.58.180.7
;; Query time: 54 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: Thu Jan 23 13:56:25 2014
;; MSG SIZE rcvd: 57
查询MX记录:
[shizhenning@zabbix ~]$ dig @8.8.8.8 163.com MX; <<>> DiG 9.3.6-P1-RedHat-9.3.6-20.P1.el5_8.6 <<>> @8.8.8.8 163.com MX; (1 server found);; global options: printcmd;; Got answer:;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 41000;; flags: qr rd ra; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 0;; QUESTION SECTION:;163.com. IN MX;; ANSWER SECTION:163.com. 13741 IN MX 50 163mx00.mxmail.netease.com.163.com. 13741 IN MX 10 163mx01.mxmail.netease.com.163.com. 13741 IN MX 10 163mx02.mxmail.netease.com.163.com. 13741 IN MX 10 163mx03.mxmail.netease.com.;; Query time: 41 msec;; SERVER: 8.8.8.8#53(8.8.8.8);; WHEN: Thu Jan 23 14:01:02 2014;; MSG SIZE rcvd: 136
查询CNAME记录:
[shizhenning@zabbix ~]$ dig @8.8.8.8 www.163.com CNAME; <<>> DiG 9.3.6-P1-RedHat-9.3.6-20.P1.el5_8.6 <<>> @8.8.8.8 www.163.com CNAME; (1 server found);; global options: printcmd;; Got answer:;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 27024;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0;; QUESTION SECTION:;www.163.com. IN CNAME;; ANSWER SECTION:www.163.com. 347 IN CNAME www.163.com.lxdns.com.;; Query time: 41 msec;; SERVER: 8.8.8.8#53(8.8.8.8);; WHEN: Thu Jan 23 14:01:54 2014;; MSG SIZE rcvd: 61
查询DRV记录:
[shizhenning@zabbix ~]$ dig @8.8.8.8 163.com SRV; <<>> DiG 9.3.6-P1-RedHat-9.3.6-20.P1.el5_8.6 <<>> @8.8.8.8 163.com SRV; (1 server found);; global options: printcmd;; Got answer:;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 41227;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0;; QUESTION SECTION:;163.com. IN SRV;; AUTHORITY SECTION:163.com. 1800 IN SOA ns4.nease.net. admin.nease.net. 20130823 7200 1800 1209600 3600;; Query time: 137 msec;; SERVER: 8.8.8.8#53(8.8.8.8);; WHEN: Thu Jan 23 14:02:46 2014;; MSG SIZE rcvd: 80
我们要查询某个域名解析的全过程:(此时为迭代查询)
[shizhenning@zabbix ~]$ dig @8.8.8.8 163.com +trace; <<>> DiG 9.3.6-P1-RedHat-9.3.6-20.P1.el5_8.6 <<>> @8.8.8.8 163.com +trace; (1 server found);; global options: printcmd. 19586 IN NS a.root-servers.net.. 19586 IN NS b.root-servers.net.. 19586 IN NS c.root-servers.net.. 19586 IN NS d.root-servers.net.. 19586 IN NS e.root-servers.net.. 19586 IN NS f.root-servers.net.. 19586 IN NS g.root-servers.net.. 19586 IN NS h.root-servers.net.. 19586 IN NS i.root-servers.net.. 19586 IN NS j.root-servers.net.. 19586 IN NS k.root-servers.net.. 19586 IN NS l.root-servers.net.. 19586 IN NS m.root-servers.net.;; Received 228 bytes from 8.8.8.8#53(8.8.8.8) in 62 mscom. 172800 IN NS m.gtld-servers.net.com. 172800 IN NS l.gtld-servers.net.com. 172800 IN NS k.gtld-servers.net.com. 172800 IN NS j.gtld-servers.net.com. 172800 IN NS i.gtld-servers.net.com. 172800 IN NS h.gtld-servers.net.com. 172800 IN NS g.gtld-servers.net.com. 172800 IN NS f.gtld-servers.net.com. 172800 IN NS e.gtld-servers.net.com. 172800 IN NS d.gtld-servers.net.com. 172800 IN NS c.gtld-servers.net.com. 172800 IN NS b.gtld-servers.net.com. 172800 IN NS a.gtld-servers.net.;; Received 485 bytes from 198.41.0.4#53(a.root-servers.net) in 134 ms163.com. 172800 IN NS ns2.nease.net.163.com. 172800 IN NS ns3.nease.net.163.com. 172800 IN NS ns4.nease.net.163.com. 172800 IN NS ns5.nease.net.163.com. 172800 IN NS ns6.nease.net.163.com. 172800 IN NS ns1.nease.net.;; Received 238 bytes from 192.55.83.30#53(m.gtld-servers.net) in 137 ms163.com. 600 IN A 123.58.180.7163.com. 600 IN A 123.58.180.8163.com. 172800 IN NS ns2.nease.net.163.com. 172800 IN NS ns5.nease.net.163.com. 172800 IN NS ns6.nease.net.163.com. 172800 IN NS ns3.nease.net.163.com. 172800 IN NS ns4.nease.net.163.com. 172800 IN NS ns1.nease.net.;; Received 270 bytes from 114.113.197.12#53(ns2.nease.net) in 34 ms
掌握dig命令后,DNS解析故障就很容易排查了.
关于域名服务器缓存污染只是一种技术，没有对错之分，有时我们企业内部也需要刻意使用这种技术
来满足企业需求。关于DNS污染技术在企业中的应用场景，详见 浅谈活动目录域名称空间设计。
本文出自 “史振宁的技术博客” 博客，请务必保留此出处http://magic3.blog.51cto.com/1146917/1354084