在很多人看来，DNS只是为外部提供DNS解析服务（我以前也是这么认为的，直到膝盖中了一箭），但作为互联网的基础设施，DNS远没有想象的那么简单。如果你没有听说过DNS查询、反向解析、zone传输、动态更新、DNS安全，那你可以从本文中得到关于他们的最简明的诠释。
一、 DNS协议
DNS在53端口上监听请求并提供响应的服务。出于性能的考虑，DNS查询请求用UDP协议交互并且每个请求的大小小于512字节，但是如果返回的请求大小大于512字节，交互双方会协商使用TCP协议。
二、 DNS查询
DNS中的域名服务器最主要的功能就是响应域名解析器的查询请求（这个域名解析器可能是PC端的解析器，也可能是具有解析功能的另一台域名服务器）。域名解析器是安装在PC端的软件，它负责向本地DNS（local DNS）发起域名解析请求。
DNS系统中有三类查询：
1，递归查询
域名服务器将代替请求的客户机（下级DNS服务器）进行域名查询，如果域名服务器不能直接回答，则域名服务器会在域各树种的各个分支的上下进行递归查询，最终将查询结果返回给客户机，在域名查询期间，客户机始终处于等待状态。递归解析的过程如下图所示：
上图中需要注意的是，许多授权域名服务器都不会提供递归查询的功能（为什么？），比如根域名服务器.和二级域名服务器.com都不提供递归查询的功能，所以真正意义上的递归查询是由Local DNS来完成的。
一般情况下，递归查询的时候会收到以下三种可能的返回结果：
1），一个或若干个A记录，或者带有CNAME链的A记录。A记录即要请求的域名的IP地址，带有CNAME链的A记录就像上一篇博客“DNS开源服务器BIND最小配置详解”里面请求ftp.cobb.com时会先将ftp.cobb.com CNAME到 ljx.cobb.com，然后返回ljx.cobb.com的A记录。
2），一个标示域或主机不存在的错误信息。需要注意的是这个错误信息也可能含有CNAME记录。例如我要请求ftp.cobb.com，而我的域名服务器将ftp.cobb.com CNAME到了ljx.cobb.com，但是ljx.cobb.com这个主机不存在，这个时候就返回CNAME记录和错误信息。
3），暂时性的错误信息。它主要是因为网络不可达该主机，网络不可达不一定表明该主机不存在。
2，迭代查询
域名服务器在返回一些下一次查询的指引或者主机IP地址，域名解析器在收到指引后会再次向这些指引发起查询请求，直到收到主机IP地址。迭代解析的过程如下图所示：
一般情况下，递归查询的时候会收到以下三种可能的返回结果：
1），A记录或者带有CNAME链的A记录。
2），标示域或主机不存在的错误信息。
3），暂时性错误。可能因为网络不可达。
4），可以给出下一步域名解析的域名服务器（包括它的IP地址）的列表。告诉解析器再去哪里进一步解析。
3，反向查询
反向查询是根据一个资源记录查询域名。这个资源记录可能是A记录，CNAME记录或者MX记录（见“DNS开源服务器BIND最小配置详解”）。
为了实现反向查询，DNS中有一个特殊的域名IN-ADDR.ARPA来专门作反向查询定义。详情见RFC3425。
三、域维护
域维护是指通过DNS协议来在主域名服务器和从域名服务器之间维护同一个zone文件。
DNS中有两种域维护手段，一种是全量传输AXFR(full zone transfer)，另一种是增量传输IXFR(incremental zone transfer)。
1，全量传输AXFR
全量传输时，从域名服务器从主域名服务器上请求zone文件，poll的时间间隔由SOA记录中的refresh标签定义。请求zone文件的过程是从域名服务器向主域名服务器发送查询来实现，如果主域名服务器中SOA记录中的序列号(serial number标签定义)大于从域名服务器SOA记录的序列号，从域名服务器就会向主域名服务器发送全量传输请求。所以主域名服务器一旦改变了zone文件，则需要增加它该zone中的序列号。整个SOA记录的完整格式见下图：
通常情况下，序列号sn遵循“年+月+日+编号”的格式，如图中的2003080803表示该zone是2003年8月8日的第三次更新。
全量传输时在TCP的53端口上进行。
2，增量传输(IXFR)
传递非常大的zone文件是非常耗资源的（时间、带宽等），尤其是只有zone中的一个记录改变的时候，没有必要传递整个zone文件，增量传输是允许主域名服务器和从域名服务器之间只传输那些改变的记录。
需要注意的是，不是所有的域名服务器都支持增量传输，当不支持增量传输时，主从间就采用全量传输的方式。
3，通告(NOTIFY)
从上面的分析中可以看出，从服务器每隔refresh时间向主服务器发送请求，只有主服务器的SOA中的序列号大于从服务器的序列号才传输，但是如果这个时间间隔比较大的话（比如12个小时），快速变化的网络环境可能不允许有如此大时间的差异。
所以在实现了通告消息的DNS集群中，DNS主服务器的zone文件发生改变后，它立即向从服务器发送一个NOTIFY消息，告诉从服务器我的zone文件发生改变了，接着从服务器马上对比两者的序列号，再采用上面介绍的全量传输或者增量传输的方法请求zone文件。
BIND本身支持通告，通告的配置是在named.conf中的zone中的option中配置，配置指令是notify, also-notify和notify-source，具体见这里。
4，动态更新
每次需要更新zone文件的时候都需要停止域名服务器并重启，这样当zone文件很多的时候域名服务器重启时加载zone文件需要很多的时间。所以需要有一种不停止查询服务而且快速更新zone文件地方机制，这种机制主要有两种：
一种是允许外部进程在服务器运行的时候更新zone文件；
另外一种是将zone中的资源记录RR存储在数据库中，每次查找zone中记录的时候动态读取；
四、DNS安全
像其他的任何公共服务一样，DNS也会受到各种各样的安全威胁。这节看看DNS服务器会受到什么样的安全威胁？聪明的人们又是怎么应对这些威胁的。
为了了解DNS受到的安全威胁和响应的应对措施，首先需要了解一下DNS的正常数据流。如下图所示：
上图中的每个数据流都会受到响应的安全威胁：
1）zone文件受到的威胁可能有：文件被无意或有意篡改或删除。这种威胁是较好应对的，最主要的方法是制定很好的系统管理策略，zone文件和其他的配置文件需要严格而安全的读写权限。
2）3）动态更新和域传输受到的威胁可能有：未授权的更新、zone文件在传输过程中被篡改（经常是把域名篡改为别的IP）。这种威胁通常的应对方法是TSIG(Transaction SIGnature)策略（这个策略定义在RFC2845中）。TSIG策略中会计算出一个key，这个key是通过单向散列(能轻松地从输入得出值，但很难通过值猜出输入)计算出来的，然后传输zone文件的双方在传输过程中都带上这个key，如果key不对就拒绝传输。
4）5）远程查询受到的威胁可能有：cache污染（IP欺骗、数据拦截或错误的master主机地址）。cache污染是指cache中内容可能将您的域名重定向到了一个错误的服务器。这种威胁通常的应对方法是域名系统安全扩展（DNSSEC, Domain Name System Security Extensions），它是为DNS客户端（解析器）提供的的DNS数据来源，数据完整性验证，但不提供或机密性和认证的拒绝存在扩展集。关于DNSSEC的资料见这里。关于这部分内容，我会在后续的博客中专门介绍，请关注：www.cnblogs.com/cobbliu
五、参考文献：
2，《Pro_DNS_and_BIND》
3，维基百科
声明：您如果觉得这篇文章对您有帮助，可以任意引用，学习的乐趣在于分享！by -- @西凉元朔