当我为继续写《通解DNS（下）》的时候，我才发现，我遇到了一些难题，在解决这些问题的时候，我才理解到了DNS与之关联的技术还是比较复杂的  -丁胖胖

六、DNS中特殊的@与FQDN

在DNS设置中，@符号是一个比较特殊的符号，它用来代表ZONE，所以在如z00w00.local这样的ZONE文件中，所以在SOA中有一个“responsible mail addr”配置的地方，你不会找到@符号，但那确实是一个E-MAIL地址（图6.1）

（图6.1）

FQDN-Fully Qualified Domain Name 中文译名为“完全合格域名”（微软官方是如此称呼）但也有的会翻译为“完全限定域名”（赛门铁克的官方） 我这里不是闲的蛋疼来咬文嚼字说中文译名的，而是要说，DOMAIN中的FQDN中是这样的

以www.51CTO.com. 为例（图6.2）

（图6.2）

注意com后面的“.”才是我要阐述的关键，windows dns中是这样的（我比较懒，于是就COPY来岳雷老师的一副图了（图6.3）

（图6.3）

对于普通用户来说，那个“."似乎无关紧要，但是对于技术人员来说，那就必须要搞明白了。如果没有那个“."就不是真正的FQDN

很多诈骗的网站其实就是利用这点制造了二级域名，如:www.51cto.com 我变成了www.51cto.com.z00w00.

真是的诈骗网站类似这样的：www.qq.q1q.com.

七、A记录和PTR记录

   我并不想阐述A记录-正向主机解析记录，因为A记录相对用的较多，就是一个域名转换成IP，其实很多用户都知道在DNS的客户端中设置HOSTS文件设置而无须DNS解析（图7.1）

（图7.1）

上图中的内容之所以变得如此怪异，是因为我使用了文本编辑器设置了格式（....代表空格，CR,LF代表结束和换行符）

为了照顾新手朋友，我重新换了一副记事本打开的HOSTS文件，图7.2

（图7.2）

我也不想阐述PTR记录-因为反向IP解析记录，因为PTR的用途确实较少，除了电子邮件用来反向解析一个收发邮件服务器的域名外， 一个容易理解PTR的实践是当你使用NSLOOKUP交换机查询时，会首先进行反向解析LDNS的FQDN，如下7.3

（图7.3）

如果是内部的DNS（关于内部DNS请见前文描述）因为没有创建反向解析区域-PTR记录，NSLOOKUP的时候就会出现(UN KNOW-未知状态)

我个人认为，在这里反向解析LDNS会首先检查其可用状态，如果出现UN KNOW，（特别是不是内部DNS）你就要小心了，DNS很可能设置错了，如果有问题了，下面是我自己构造的一个错误的DNS服务器地址，图7.4

（图7.4）

在确保像上图中DNS服务器地址没错的情况下（我故意输出为8.8.8.9），很可能就是DNS服务器挂了。

注：我发现很多人都喜欢用PING工具来测试DNS服务器，我强烈不建议用这种方式，理由有如下：

1、PING在连接的时候首先会像WEB的客户端程序如浏览器先检查HOSTS文件然后检查DNS客户端的缓存

（WINDOWS下利用 ipconfig /displaydns查询）如果你已经浏览器了www.51cto.com 并且再次ping www.51cto.com 只要WEB服务器没挂，肯定会正常返回包，但这并不意味着DNS可用，如果你第一次访问如www.360dns.com这样网站的时候很可能就无法访问。

2、并不是所有的DNS都允许ICMP回传，就如同很多企业网站为是禁PING的，禁PING的理由无法是为了安全。如

北京联通的202.106 DNS服务器

八、CNAME-别名记录

     我想着单独谈一下CNAME别名记录，原因是这个别名记录也把我搞晕了一下。

首先我们先做一个有趣的实验，当你ping www.baidu.com的时候，不知道结果是不是会和我出现一样的结果呢，见图8.1

（图8.1）

亮点我已经用红框标出来了，怎么ping www.baidu.com的时候变成了www.a.shifen.com 了呢？

为了做对比，我将ping www.51cto.com 做了对比，如下图8.2

（图8.2）

很明显，虽然PING 出现超时，但是返回结果并没有变化

不知道有没有人会认为是域名劫持呢？说实话，这个念头我也闪过一下，但是还是通过强大的搜索找了原因

为了不影响篇幅，简单说一下：原来shifen.com 这个域名最早就是百度起家的时候用的，就是baidu的竞价排名系统，名字就叫十分系统 ,据说因为最早的时候每一下的点击率可以赚取10分钱。有兴趣的可以继续挖掘一下。

其实我并关心这个，我所关心的是：www.baidu.com和www.a.shifen.com 肯定有一个是A记录，有一个是CNAME记录了。那么到底谁是谁的别名呢？我查了一下网上说的，网上有一个问答系统和一篇博文都说www.baidu.com是A记录，www.a.shifen.com 是CNAME别名记录 但是我用NSLOOKUP看了一下，确得到完全不同的答案 图8.3

（图8.3）

即使你不懂计算机，如果稍微知道点英文就应该明白Aliases的意思吧？那我们在nslookup一下www.a.shifen.com 吧，结果如下图8.4

（图8.4）

看到没，并没有出现ALIASES的字样，看来网上和那篇文章的解释是错误的。为了进一步佐证我们的判断，使用DIG工具再看一下，图8.5

（图8.5）

根据RR记录格式CNAME记录格式如下：

主机别名（WWW.BAIDU.COM)  IN CNAME 实际代表这个主机别名的主机名字(WWW.A.SHIFEN.COM）

由此我们得出前者是后者的别名

由此我们得出结论：

1、当解析一个主机地址的时候，如WWW.BAIDU.COM 会查询是否A记录，如果是A记录，那么解析出其IP地址

2、如果记录WWW.BAIDU.COM是一个CNAME记录，那么先找到其A记录，然后根据A记录解析出其IP地址。

有人可能会说：“胖胖，你搞了半天就是要搞明白WWW.BAIDU.COM究竟是A记录还是CNAME记录呀，这个意义大吗？”

这里我要解释说：其一，首先要搞清楚CNAME记录是如果被解析的；其二，CNAME记录还有其他的大作用，先在这里卖一个关子，我们后面会说到。

九、DNS轮询

    之前我们说过，DNS作为网络的基础架构，主要是为了解析域名为IP地址，很多应用程序都需要这个过程，拿用途最多的WEB进行继续阐述。大家知道，为了保障WEB的高可用性和业务连续性，WEB服务器不止一台，当有多个WEB服务器时，DNS如何解析呢？见下图9.1

（图9.1）

当用户访问www.z00w00.com的时候，dns服务器ns.z00w00.com会去解析其A记录，结果发现有3条A记录，这个时候按照默认不做任何策略的时候，会按照顺序提供A主机对应的IP地址，当第二个用户访问的时候就会返回第二台主机的IP地址，如下9.2

（图9.2）

这就是DNS轮询，不过需要注意一点的是，如果用户1与用户2同时设置了同一台LDNS（本地的DNS）因为缓存的关系，可能会得到同一个IP地址。DNS虽然支撑轮询访问WEB，但是也有一些缺点，最大的缺点之一就是当其中一台WEB宕机或其它原因无法访问的时候，DNS并不能判断是否宕机，依然会解析IP地址给用户，当然用户就无法正常访问了。后来人们想了一个办法，就是在WEB前端放一个负载均衡设备，可以判断WEB集群的健康状态，如下图9.3

（图9.3）

负载均衡并不是我们讲述的重点，所以只是简单提一句。

十、 主/辅DNS模式

单点风险，是很多IT公司最不愿意承受的，所以绝大部分的IT公司并不会仅仅允许1台DNS进行权威解析，如果一台DNS因为故障而无法解析，那么你所有需要访问的用户都无法正常访问，不要告诉你的用户用IP访问呦。所以DNS是允许多台进行解析的，不过DNS服务器仅允许一台DNS进行写操作，而其它DNS只允许读操作。这样方式有点像MYSQL数据库的主/从模式，可写操作的被称为主要区域DNS,剩下可读操作的被称为辅助区域DNS。如下图10.1

（图10.1）

ns1.z00w00.com 为主区域，ns2.z00w00.com为辅助区域 由于辅助区域服务器不能写操作，所以ns2.z00w00.com的区域记录（基于z00w00.com的正向或反向）通过区域文件复制得到，什么时候复制，依据什么复制，是通过SOA记录完成的，下面我们以51cto.com为例，看一下SOA记录，如下图10.2

（图10.2）

primary name server 代表主区域服务器是谁

responsible mail addr 代表管理员E-MAIL

serial 序号代表数据库文件新旧，如果辅助区域发现其值比当前值小，就会进行区域复制

refresh 是更新频率 3600秒辅助区域向主区域进行更新

retry 失败重新尝试时间 如果辅助区域无法连接主区域，那么连接的时间就是这个值

expire 失效时间

dafault TTL 缓存时间

十一、CDN与DNS

当很多企业正在为TCP连接数、并发过高、DDOS攻击、用户抱怨访问较慢发愁而思考如何更改架构、增加带宽、买防DDOS设备的时候，一些ICP已经提供了一些解决方案，那就是CDN。CDN技术还是很复杂的，并且我不打算在这里阐述CDN。只是说一下CDN与DNS的关系。

CDN是内容分发系统，可以通过CDN技术将你自己的源站内容推送的CDN服务器上，而CDN分步在全国各电信、联通、移动等机房；用户可以就近访问自己需要的内容，从而也隐藏了真实的WEB服务器，一举多得。还记得我们之前说到的CNAME记录吗？CNAME记录就是和CDN有密切关系的。如图11.1

（图11.1）

z00w00.com的权威解析服务器ns1.z00w00.com 将www.z00w00.com改该cdn.www.z00w00.com的CNAME记录

    当用户要求解析其IP地址时，首先访问到权威服务器，但是权威服务器发现这是一个别名，然后将别名记录提交到设置为A记录的CDN的DNS服务器，CDN的DNS服务器会根据用户本地DNS的IP地址判断选择里用户最近的一个CDN节点服务器并提供IP地址，然后用户访问这个CDN节点服务器。

当然这只是最简单的过程，CDN比这要复杂的多，实际上还有CDN节点服务器如果没有获取到用户所需的资源，还要回源处理（从原始WEB服务器模拟用户提供申请，取得数据）另外CDN如何判断用户所在区域，并根据其节点调度提供IP地址。因为我们不是在解释CDN，此复杂细节略过。

   其实，我还想写的更多，如DNSSEC，DNS劫持等；但在《通解DNS（上）》发布后并没有得到大家的更多关注，所以暂时放弃了这些内容。写原创技术文章，确实很辛苦。除了需要构思内容，有些东西知识点还需要认真思考，尽量不要出错，毕竟我本人不是大神。当然我也可以写一篇DNS部署的文章，若干行命令，按照部署的流程走一遍，甚至负不负责的不反复推敲排除特殊环境变量。但这不是我的风格，我希望有网友能通过这上下两篇文章，得到一些启示，这就够了。当然，如果在描述的有不准确，或者在知识点上就有错误，也希望大神给予指出。

本文出自 “丁胖胖的BLOG” 博客，请务必保留此出处http://z00w00.blog.51cto.com/515114/1426555