Chapter1 基础
1.1 常见问题
1.1.1 域名对应的IP地址修改完要将近一天的时间才能有效果？
因为DNS的数据库一般来讲是在跑在DNS服务器的内存当中的，但是我们如果临时增加一条的话其实是写到了硬盘当中，当数据库服务刷新的时候新增的新记录才会被记录到内存当中。
这其实也会是与DNS的缓存有关系的，举个例子你的主机在.com下注册了域名1.1.1.1，后来又换成了2.2.2.2，在一天的时候当中你会发现当你ping主机的时候域名解析还是1.1.1.1，为什么？因为不仅DNS不仅PC本地有缓存，而且互联网上很多的DNS都有缓存，当它们所有的缓存都失效后才再去解析，所以这一通下来，也差不多是一天的时间。
1.1.2 递归和迭代：
递归查询就是我们发出一个请求就一定能得到最终结果的查询，所以递归是对于我们的主机而言的，主机可以发一次查询就可以通过自己设置的DNS得到结果，但是我们设置的DNS可能要费很大的力气才能帮助我们查找到，所以递归是针对主机而言的，主机发一个查询请求，主机不管DNS服务器费了多大的力气，它反正只要最后的结果，它一次查询的结果就是递归。
迭代就是说本地DNS服务器想要得到最终的答案需要多次查询，这就是迭代，所以迭代是针对本地DNS而言的，它要通过多次查询才能帮助客户端查询到查到对应的IP，它多次查找的过程就是迭代。
1.1.3 在公司内网部署DNS服务器的意义何在？
在内部搞一个DNS服务器之后，客户端可以通过此DNS实现递归，客户端自己发一次查询就好；同时如果在本公司内部有一个服务器不打算让互联网上的人访问，只想让公司的人访问的话，那么就把此服务器的域名和IP写入到本地搭建的DNS服务器的数据库当中，这样的话，本公司内部的人访问自己的服务器时把DNS指向自己搭建的DNS服务器就可以实现内部事务内部解决，如果想访问互联网的的主机时，本地的DNS会帮助客户端实现递归，它自己去迭代。所以说非常的方便。内网的DNS服务器万一坏了怎样办，要设置主从。
迭代非常浪费资源，所以尽量给组织内部的人提供迭代，但是ISP必须得自己搭建让自己自足，谷歌帮助全人类提供了一台迭代8.8.8.8，4.4.4.4。
1.1.4 正向和反向区域解析：
通过域名解析成IP是正向解析，通过IP解析域名是反向解析。通过正向区域可以实现正向解析，通过反向区域可以实现反向解析，值得一提的是反向区域在一定程序是依赖正向区域，正向区域完全不依赖反向区域。正反向区域是两个不同的系统，可以位于同一个主机，也可以位于不同的主机。
互联网的.com等域只支持迭代，不支持递归，所以这些哉不能帮助我们递归，而客户端也不支持，只能找一个中间人，这个中间人一般由ISP提供，人家只是中继一下帮你查询的，它有帮客户端递归的能力，而客户端就是需要这种能力。
1.1.5 服务器的主机名一定要与提供的服务一样吗？
baidu.com是一个域名，而www是一个主机，但是www主机所指向的主机的名字不一定就非得叫www，所以说网络的标识某一台服务器的的名字和服务器本身主机的名字没有一毛钱的关系，顶多就是IP的对应关系，你在.com域名下注册了一个域名baidu那么.com就在自己的数据库就加上一条
1.1.1.1 baidu
一旦有人来找.bom查询百度的对应的IP，把1.1.1.1返回就是了，至少你是访问www还是mail还是什么，.com不管，.com只看到了你访问的是baidu。
1.1.6 DNS服务器的类型：
缓存DNS服务器，主DNS服务器、从DNS服务器、转发器
运营商给客户提供的DNS服务器，比如联通给提供的202开头的DNS服务器，它不负责任何域的解析，它仅仅给通过自己上网的客户端做递归的服务器（牺牲自己做迭代，自己麻烦最后把结果返回给客户端），其实这种的DNS就叫做缓存DNS，因为它只有缓存的功能，不负责解析任何域，当一个内网的主机请求时，如果它本地没有，它就去找根，进行迭代查询。虽然本地PC会缓存DNS，但是过一会儿就会失效了，失效之后再访问同一个网站还要去向DNS服务器查询，这其实就浪费了带宽，如果在内网我们自己搭建一个DNS服务器，让内网的DNS服务器去帮助我们迭代多好呀，还能节省带宽，会节省一部分带宽，它迭代的内容同样也有有效期，这个有效期是权威DNS规定的。其实家里的小米路由器就是一个缓存DNS服务器，通过小米路由器获得的DNS是网关，而路由器也有一个DNS,这个DNS指向的就是联通公司给分配的DNS，小米路由器充当了缓存器，帮助用户节省了带宽。
因为要冗余，所以DNS服务器通常会成双出现，所以有了主从之分。
1.1.7 主从DNS之间的区域传送、全量传送，增量传送
但是内网当中的部署的DNS服务器挂了之后怎样办？所以通常还会有一个从DNS服务器，那么这个主从是如何区分的呢？主DNS服务器挂了之后，从DNS要立马顶上，所以就要求它们的底层数据库是相同的，从DNS服务器的数据库从主DNS服务器那里复制过来的，从DNS服务器从主DNS服务器复制数据库的过程就是区域传送的过程。区域传送也有两类型，如果从DNS服务器刚刚配置好数据库什么东西都没有，下一步就要把主DNS服务器那里把所有的内容都复制过来，这是全量传送；假如主DNS的数据库变化了，从DNS服务器保存的还是原来全量传送时的数据，在这种情况下，从DNS服务器只要复制主DNS服务器被修改的部分即可，用不上全部复制了，这个过程又被称做增量传送。
1.1.8 主从DNS之间的解析库序列号、刷新时间、重试时间间隔、过期时长：
上文提到，主从DNS服务器之间的解析库需要进行增量传送，两台DNS服务器的解析库要及时同步，但是当主DNS的解析库更新了之后从DNS服务器怎样才能知道呢？解析库是序列号的，解析库的序列号是随着修改的次数而递增的，就比如主DNS的解析库原来的序号是1，从DNS服务器对主服务器的解析库进行了全量传送，从DNS服务器的解析库的序列号也是1，现在主DNS解析库里面又加了一条记录之后 ，主DNS服务器的解析库序列号又递增为2，此时，从DNS服务器解析库的序列号还是1，从DNS服务器并不知道主DNS服务器的序列号已经发生了改变，从DNS服务器要定期去主DNS服务器上查看解析库序号又没有变化，那么多长时间去查看一次好呢？这个时间我们是可以定义的，这个时间就是刷新时间。现在要考虑一种情况，实际上从DNS服务器向主DNS服务器查询解析库的过程就是两台主机相互通信的过程，只要是通信就有失败的可能，如果从DNS在与主DNS服务器通信时没有刷新成功，假如说是主DNS挂了怎么办？如果第一次通信失败的话，从DNS服务器会认为是网络阻塞，并不会立马认定主DNS已经挂了，在第一次通信失败之后，再隔一会儿从服务器还会再去与主DNS服务器同步一下尝试能不能通信成功，这个隔一会儿就是重试时间间隔（如刷新时间一样都是可以定义的），重试时间应该小于刷新时间，因为重试时间要是大于刷新时间的话，在等待重新刷新时又重新刷新了一次，这样没有任何意义。假如刷新一直失败怎么办？有过期时长，假如一直刷新失败的话，从服务器并不会趁此机会上位，它们比人要有人性多了，假如从服务器一直联系不上主服务器，从服务器认为主服务器已经停止服务了，既然主服务器停止服务器，从服务器提供服务也没有什么意思了，所以从服务器当发现主服务器失联时自己也会停止所有的服务，与主服务器一同“赴死”。所以在我们人的角度来考虑，当主服务器宕机时要尽快修复主服务器，不然从服务器也会跟着罢工的。
1.1.9 主从同步的缺点：
值得声明的一点是，主从服务器实际上一起提供服务器，并不是一台工作，另一台闲着。它们两个通常会负载，它们是不是负载取决于上一级DNS服务器的解析库记录，同一个域名对应两个IP地址，这样就会负载均衡，如果其中的一个联系不上了，就给第二个来解析。肯定会有这样的情况，假如主从的刷新时间为5分钟，在从服务器刚同步完后的1秒之后主服务器的解析库发生了变化，但是从服务器要等到刷新时间到了之后才能把新增加的内容同步到自己的解析库当中，如果在此期间，正好有人找从服务器解析来解析新增加的这一条内容的话，这样不就解析不到了吗？ 通常是这样，当我们在DNS解析库里面加了一条记录之后主DNS服务器会通知从DNS服务器过来同步，即便是刷新还没有到，这样在一定程度上缓解了主从两台主机解析库不一致的情况。
1.1.10 当主机第一个DNS服务器时并没有解析结果时，会再解析第二个DNS服务器吗？
如果一个主机上设置两个DNS服务器，使用第一个的时候解析不成功，那么还会使用第二个吗？并不会的，因为第一个在查找第一次的时候肯定访问了根，根没有找到才返回给你没有找到的信息，这样的话，第一个都解析不出来，第二个肯定也不成的，所以根本没有必要使用第二个DNS。
1.1.11 什么时候会用到第二个DNS服务器呢
当第一个DNS服务器连接不上的时候才会使用第二个DNS。
1.1.12 域和区域
我们讲课一起讲区域传送，为什么不讲成是域传送呢？
区域要么正向的，要么是反向的，而域没有正向反之说，域在概念是包括了正向和反向。
1.1.13 FQDN
正向区域和反向区域不是使用一个数据库。
FQDN:full qualified domain name，完全限定域名，如www.baidu.com. 注意最后有一个点
主机名+域名的格式就被称为完全限定域名（FQDN）
域是一个概念，比如baidu就是一个域，在这个域之下还有区域，也就是所谓的正向区域和反向区域。
正向区域就是把FQDN解析成IP，而反向区域就是把IP解析成FQDN。
1.2 必背内容
1.2.1 一次完整的查询请求经过的过程
hosts（本地hosts文件）
DNS server：local cache（本地缓存）—recurtion（递归）—server cache（服务器缓存）----intertive（迭代）
具体的含义的解释：
1. 客户端首先在本地的hosts文件查看，没有就找指定的DNS服务器
2. 通常DNS都是缓存服务器，比如8.8.8.8 223.6.6.6这些DNS服务器，这些DNS服务器本身不具有解析的功能，只能帮你递归解析罢了。
3. 客户端找到223.6.6.6，阿里的DNS首先在自己的缓存当中查找
4. 如果缓存当中没有，就去递归（找根解析）
5. 递归回来之后在本地缓存
6. 然后把结果返回到客户端
1.2.2 答案类型
如果DNS帮你找了正确的答案就是肯定答案
如果DNS没的找到答案的话就返回一个否定的答案，就是就是否定答案，否定答案并不代表对方不在线，只是没找到你想到的答案，否定答案其实也有缓存。
其实无论是肯定答案还是否定答案都有权威与非权威之分。
那么何为权威答案？权威答案就是你访问www.baidu.com.时，缓存DNS服务器帮你递归时从负责百度这个域里面的区域明确回应的，就是权威答案。
那么何为非权威答案？非权威答案就是访问www.baidu.com.时，缓存DNS服务器没有去找负责百度这外域里面的区域，而是直接从自己的缓存当中找到了答案，这就是非权威应答。
其实这种分布式系统的缓冲带来的好处就是给DNS服务器减小了压力，缺点就是在某一个时刻肯定失去了一致性，就比如一个缓存服务器刚刚缓存了一答案，但是权威DNS服务器更改之后，缓存服务器并不会立马收到，这就失去了一致性，但是还好，当缓存失效之后就会一致了。如果没有缓存的话，的确得到的答案都是权威答案，但是服务器的压力会很大。
1.2.3 区域解析库
每个域都要维护一个区域解析库，而区域解析库都是由一条条的记录组成的，而每一条记录就被称为资源记录（resource record RR）.
我们知道大多数域名下面都不仅仅有www服务器，可能还会有mail、等服务，用来标识不同服务的资源记录类型是不一样的，也就是说资源记录有多种类型，般来计，常见的资源记录类型有：A/AAAA/PRT/SOA/NS/CNAME/MX
l SOA记录：任何解析库的第一条都必须是SOA记录，start of authority 起始授权记录，一个区域解析库有且仅能有一个SOA记录，且必须在第一条。说明当前这个区域解析库为哪一个区域所用，由谁负责。
l A记录：作用是把FQDN解析成为IPV4的IP地址
l AAAA记录：使用是把FQDN解析成为IPV6的IP地址
l PTR：pointer 指针记录，作用是把IP解析成为FQDN
l NS：name server 专用于标识当前区域的DNS服务器
l CNAME：canonical name 别名记录
l MX：mail exchanger邮件交换器，当我们写邮件的时候收件人通常会这样写[email protected]，其实我们想把邮件发送给746620446这个用户，但是首先肯定会是先找到QQ.COM然后通过QQ.COM再找到746620446这个用户，那么QQ.COM其实是一台服务器主机，这个记录就是用来标识QQ.COM对应的那台服务器主机的Ip地址，总结就是一名话，当有人给QQ.COM这个区域发送邮件时由谁来中转此邮件，毕竟不能一下直接发给746620446 这个用户，必须要有一个中转服务器，然后通过中转服务器再转发给746620446这个用户。
1.3 资源记录
1.3.1 资源记录通用格式
通用格式：
name [TTL] IN rr-type value
name：当前的区域的名字，例如magedu.com. 注意最后的点一定不能省略。
TTL可以省略从全局继承，也可以自行定义，单位是秒，所谓的TTL就是DNS记录在客户端的缓存时长（秒）
@可以用于引用当前区域的名字
IN代表internet，没有实际意义，可以当做固定格式。
rr-type当前资源记录的类型
value由多个字段组成，其中以SOA的格式最为奇特。
1.3.2 资源记录详细格式
1.3.3 SOA
SOA记录当然也有通用的部分，SOA记录与其它记录不同的是就是value部分，SOA的value部分由很多的字段组成。
value：有多部分组成：
1. 负责当前区域的主DNS服务器FQDN，也可以使用当前区域的名字，用@可表示当前区域的名字
2. 当前区域管理员的邮箱地址，但是地址不能有@符号，一般用.来代替，例如15069028007.163.com
3. (主从服务器协调属性的定义以及否定的答案的统一的TTL)
例如：
baidu.com. 86400 IN SOA www.baidu.com. zhanghe.163.com. (
2017102501 序列号
2H 刷新时间
10M 重试时间
1W 过期时间，一星期
1D 否定答案的TTL，一天
）
NOTE：如果后面不加单位，默认是秒钏
1.3.1 A
name某主机的FQDN，例如www.magedu.com.
value:主机名对应主机的IP地址
例如：
www.magedu.com. IN A 1.1.1.1
www.magedu.com. IN A 1.1.1.2 #多条会出现轮询
mx1.magedu.com. IN A 1.1.1.3
mx2.magedu.com. IN A 1.1.1.3、
注意：
*.magedu.com. IN A 1.1.1.4
magedu.com. IN A 1.1.1.4
避免用户写错名称给错误答案，可通过泛域名解析进行解析到某个特定地址。
1.1.1 AAAA
name FQDN
value IPV6
1.1.1 PTR
name vlue
name是IP地址有特定的格式，把IP地址反过来写，比如1.2.3.4要写成4.3.2.1而且有特定后缀：in-addr.arpa.所以完成的写法为：
4.3.2.1.in-addr-arpa.
value：FQDN
例如：
4.3.2.1.in-addr.arpa. IN PTR www.magedu.com.
可以简写成：
4 IN PTR www.magedu.com.
注意：网络地址及后缀可以省略，主机地址依然需要反着写。
1.1.1 NS
name:当前区域的名字
value：当前区域某DNS服务器的主机名，例如ns.magedeu.com.
注意，一个区域可以有多个NS记录
例如：
magedu.com. IN NS ns1.magedu.com.
magedu.com. IN NS ns2.magedu.com.
注意：
相邻的两个资源记录的name相同时，后续的可以省略
对NS记录而言，任何一个ns记录后面的服务器名字，都应该在后续有一个A记录。
1.1.2 MX
name 当前区域的名字
value:当前区域的某邮件服务器（smtp服务器）主机名
一个区域内，MX记录可以有多个，但每个记录的value之意应该有一个数字（0-99），表示此服务器的优先级，数据越小优先级越高。
例如：
magedu.com. IN MX 10 mx1.magedu.com.
IN MX 20 mx2.magedu.com.
注意：对mx记录而言，任何一个MX记录后面的服务器名字，都应该在后续有一个A记录
1.1.3 CNAME
name:别名的FQDN
value:真正名字的FQDN
例如：
web.magedu.com. IN CNAME www.magedu.com.
Chapter2 中级
2.1 概念
2.1.1 -子域授权
整个DNS的架构是分等级的，最高层就是根，其次顶级域、子域、子域下面还有子域。
一个子域想要在互联网使用的话就必须向上层的域进行注册，注册之后自己就成为上层的子域，对于上层为说，这个过程就叫做子域授权。
举个例子，对于.com来说，它的上级就是根，但是我们也找一台主机也叫.com的话是不会生效的，为什么？因为真正的.com主机是向根注册过的，而真正的根是由某个商业组织把持着的。
假设现在.com下面向根注册的话，.com主机先要找到该公司在本国家的代理商，如果在中国的话，最有名就是万网和新网，当你交完费用之后，该公司就会在根服务器上的后台数据库写入这样的记录：
.com. IN NS ns1.com. #前两条是NS记录，把.com.这个授权给DNS服务器，ns.com.就是某个DNS服务器的名字
.com. IN NS ns2.com. #上面那个主，这个为辅
ns1.com. IN A 2.2.2.1 #后两条就是主机A记录，上面两条仅指明主机的名字，这里是指明主机对应的主IP
ns2.com. IN A 2.2.2.2 #指明主机对应的辅IP
当根在自己的数据库加上以上的内容之后，在互联网上只要再找两个主机把IP设置成2.2.2.1和2.2.2.2那么如果有人要解析.com.下的域名的话根就会指向2.2.2.1 2.2.2.2因为有两个所有会轮询；而我们的公司如果想在.com.下注册一个域名magedu，一般我们都要去.com.下注册，.com这个DNS服务器也会和根一样向下做子域授权
magedu.com. IN NS www.magedu.com. #.com.把magedu.com.这个域名的解析权授于www.magedu.com.（这是一台公网DNS服务器的名字）
magedu.com. IN NS mail.magedu.com. #.com.把magedu.com.这个域名的解析权授于ftp.magedu.com.（这是一台公网DNS服务器的名字）
magedu.com. IN NS ftp.magedu.com. #同上两行，为什么一个域名要三个DNS服务器做解析呢?当然是冗余和负载，一个宕机之后不至于公司业务中断
www.magedu.com IN A 1.1.1.1 #这就是A记录了，记录了公网DNS服务器的IP地址，下面两行亦是如此。
mail.magedu.com. IN A 2.2.2.2
ftp.magedu.com. IN A 3.3.3.3
如果我们公司真的有三种类型的服务的话，难道还要专门找三台服务器来做DNS服务器器吗？如果是这样的话成本真的就太大了，其实不用这样的，当我们注册之后，代理商会在他的服务器集群里随机找三台DNS服务器给我们做解析，把解析的任务委托这三个服务器，这个过程就过程子域授权，代理商会给你提供一个图形界面的管理，你在这个管理界面设置完成之后可以保存到这三台服务器上的，记住这只有注册域名而已。
个人如果小公司如果想建立一个自己的网站的话，那么我们可以去国内的阿里、百度等等等提供虚拟化的平台上申请一个linux主机，假如说你申请的linux主机的IP地址是1.2.3.4的话，想让别人能够通过www.zhanghe.com访问它的话，先进入域名代理商（万网、新网等等）注册域名时给提供的图形界面里面，把www.zhanghe.com.对应的IP：1.2.3.4写入并提交，提交之后其实就意味着把此NS记录写入到了负责zhanghe.com这个域名的DNS服务器里面的解析库当中（就是上文提到过后三台DNS服务器，写入完成后要两个小时以后才会生效）。
最好去国外的网站申请，因为国内太麻烦了，在国内使用万网或者网申请的话，需要去公信部认证之后才能真正在公网上访问，前前后后要跑几十次，而且一不留神就要被禁用。
https://sg.godaddy.com/zh/domains/searchresults.aspx?checkAvail=1&tmskey=&domainToCheck=zhanghe.com&key=dpp_leaf_com&tld=.com #这是godaddy的中文网站，hehezhang现在无人注册
我们如果不是去一线大型互联网公司的话，比如batm的话，配置DNS的机会很少，但我们要清楚DNS的每一个配置步骤，因为这个很多服务的基础，内功也~
如果我们的公司不差钱（这种情况很少遇到）的话，而且有两台服务器和两个公网地址的话，老板非要使用自己的公司的服务器做DNS服务器的话，要怎样做呢？同样的，首先还要要去.com.下申请域名，申请域名完之后，进行代理商给提供的管理界面把DNS指向更改成自己公司的DNS即可,实际上在内网自己搭建DNS服务器的情况非常的少见，国内的公司也只有BAT有这样的实力，都要投入人力物力才能玩转内网的DNS。
2.2 刻意练习
2.2.1 配置
bind是DNS的实现软件工具，其程序包叫做bind，而其二进制的程序名是named
服务脚本：/etc/rc.d/init.d/named
脚本的配置文件：/etc/sysconfig/named
主配置文件：/etc/named.conf，为了避免主配置文件过长所以又有辅助配置文件/etc/named.rfc1912.zones ，/etc/rndc.key
解析库文件：/var/named/ZONE_NAME.ZONE，解析库文件默认没有，需要我们自行编写
日志文件: /var/named/data/named.run
/etc/named.rfc1912.zones请求注解文件，明确说明协议的工作过程和原理
rndc：remote name domain controller，远程管理控制器，默认与bind安装在同一主机，且只能通过127.0.0.1来连接named进程，为什么只能工作在本地呢？如果允许其工作在远端的话，谁都能连，会非常的不安全，所以需要认证密钥，而认证的密钥就是/etc/rndc.key，并且只能工作在本地提供辅助性的管理功能，使用tcp/953端口，这也是一个服务，/etc/rndc.key就是rndc连接named的一个预共享密钥
注意：
1. 一台物理服务器榀同时为多个区域提供解析
2. 必须要有根区域文件（使用rpm安装时，默认给装好了：/var/named）
3. 应该有两个（如果包括IPV6,应该更多）实现localhost和本地圆环地址的解析库（默认也装好了）
解释一下上面的配置文件，第一行就定义了TTL是一天，然后下面的资源记录都没有写，都是通常此变量继承的。
SOA记录的第一个@代表域名，第二个@代表负责此域的DNS服务器主机名，其实通过这两条我们可以判断出此主机的主机名和域名是一样的，那么@这个变量是从哪个文件继承过来的呢？
当我们打开主配置文件/etc/nemed.conf之后会发现里面三个段落：
option，代表是全局配置
logging代表的是日志的配置
zone，每一个zone段落都用来定义一个区域，本机能为哪些区域解析就要定义哪些zone，zone不仅仅在/etc/named.conf里面有，而且还在/etc/named.rfc1912.zones里面有有定义。zone关键字后面的双引号里面就是区域名，每一个区域都要有区域的类型，主DNS就叫主区域，从DNS就叫做从区域，而在/etc/named.conf里面最后一条：
zone "." IN { #双引号里面的点代表根区域
type hint; #类型是根，hint就是根提示的意思
file "named.ca"; #此域也就是根区域对应的解析库文件是/etc/var/named/named.ca，此相对是从option全局引用的
};
里这个区域就是根区域，每一个区域之下都应该有一个解析库文件，此根区域的解析库文件就是named.ca，这个区域的目的就要用来做转发，如果本地解析库没有的话，就通过根区域查找到全球的根服务器然后通过根服务器做迭代。新安装好的BIND默认就已经为用户提供了三个区域，一个是根区域（做迭代使用的），另一个是解析本机的正向区域，还有一个是解析本机的反向区域，也就说默认安装好启动之后就能够当缓存DNS使用（实际上是不行的）。说到这里你应该明白了，我们之前讲过，每一个区域都对应一个区域解析库，这里的区域其实和/var/named（BIND的工作目录里面的解析库是对应的）有几个区域就应该定义几个解析库。
最下面的两行意思是说本配置文件其实还包括/etc/named.rfc1912.zones，include "/etc/named.root.key这两个配置文件，也就是说本配置文件加上里面的这两个才是BIND全部的配置文件，配置文件当中的区域大部门都定义在etc/named.rfc1912.zones里面了，我们如果想添加区域就在这个配置文件里面添加即可，但是可不要忘了，在此配置文件里面添加了区域，还要在bind的工作目录手工创建解析库文件才行。
1.1.1 配置缓存DNS服务器
总结一下把BIND配置成缓存DNS服务器的步骤:
1. 侦听外部IP地址
2. 允许任意人使用
3. 注释掉与安全相关的行,共5行
以下是详情信息
我们在上面的/etc/named.conf看到了官方已经给我们配置好了根区域，这个根区域的作用就是帮客户端做递归使用的，根区域的解析库文件在/etc/named/named.na里面，我们要知道缓存DNS服务器工作时是依赖于根提示文件的，按理说我们只要启动bind之后就能当做DNS缓存服务器的，但实则不然。
如下图，当我们启动之后查看侦听的端口发现BIND服务器仅仅侦听了127.0.0.1，这样的话自己给自己可以解析，但是别人找它解析不成，这是因为配置文件里面定义的，我们只要在配置文件把服务器的对外的IP侦听上就好。
[root@zabbix ~]# vim /etc/named.conf #更改侦听的IP
options {
listen-on port 53 { 192.168.80.8; 127.0.0.1; };
[root@zabbix ~]# named-checkconf #检查是否有语错误
这样配置完成后就可以当做缓存器来使用了。
疑问:当配置完成DNS缓存服务器之后发现并不生效.
1.1.1 主DNS服务器
第一步：在/etc/named.rfc1912.zone添加区域
[root@zabbix ~]# vim /etc/named.rfc1912.zones
zone "magedu.com" IN {
type master; #类型为主DNS服务器，还有slave,hint（根）、forward
file "magedu.com.zone";
};
第二步：定义区域解析库
[root@zabbix ~]# cd /var/named
[root@zabbix named]# vim magedu.com.zone
$TTL 86400
@ IN SOA ns.magedu.com. zhanghe.qq.com. (
2018010101
1H
5M
7D
1D
)
IN NS ns1.magedu.com.
IN NS ns2.magedu.com.
IN MX 10 mx1.magedu.com.
IN MX 20 mx2.magedu.com.
ns1.magedu.com. IN A 192.168.31.8
ns2.magedu.com. IN A 172.16.100.12
mx1.magedu.com. IN A 172.16.100.13
mx2.magedu.com. IN A 172.16.100.14
www.magedu.com. IN A 192.168.31.8
www.magedu.com. IN A 192.168.31.9
ftp.magedu.com. IN CNAME www.magedu.com.
第三步检查：
[root@zabbix ~]# named-checkconf
[root@zabbix ~]# named-checkzone "magedu.com." /var/named/magedu.com.zone
zone magedu.com/IN: loaded serial 2018010101
OK
第四步设置文件权限
[root@zabbix ~]# ps aux | grep named
named 3545 0.0 0.3 237416 14048 ? Ssl 22:52 0:00 /usr/sbin/named -u named
root 6901 0.0 0.0 103328 848 pts/2 S+ 23:59 0:00 grep named
[root@zabbix ~]# ll /var/named/magedu.com.zone
-rw-r--r-- 1 root root 424 1月 10 23:52 /var/named/magedu.com.zone
[root@zabbix ~]# chmod 640 /var/named/magedu.com.zone
[root@zabbix ~]# chown :named /var/named/magedu.com.zone
第五步：重启服务并检查服务器的工作状态
第六步本地验证,使用dig命令验证,下一节讲解dig命令的使用
1.1.1 dig&host&nslookup
这几个命令都是用来测试DNS的,其中以dig最为常用.先介绍dig
dig的使用:
l 第一种用法
dig –t <资源记录类型> <主机名> @<请求让哪个DNS解析的IP>
比如:dig –t A www.magedu.com @192.168.31.8
这条命令的意思就是请求192.168.31.8这个DNS服务器,想要获得www.magedu.com的A
记录,这是获得A记录获得别的记录同样也可以.
l 第二种用法
dig –t <资源记录类型> <主机名> @<请求让哪个DNS解析的IP> +trace #trace的意思是跟踪解析过程
比如:dig –t A www.magedu.com @192.168.31.8 +trace
l 第三种用法
dig –t <资源记录类型> <主机名> @<请求让哪个DNS解析的IP> +recurse #递归查询,发一个请求必须得到答案
l 第四种用法：模拟区域传送
获取172.16.100.11的解析库,模拟全量传送，axfr是all transfer全量传送的意思，上图是正向的，我们还可以获得反向区域的解析库，如下图：
这样太危险，最好不允许全量传送，怎样禁止呢？
下面是一些小例子
[root@zabbix ~]# dig -t A www.magedu.com. @192.168.31.8
;; QUESTION SECTION: #question section问题部分,就是你问的问题是什么
;www.magedu.com. IN A #你的问题是查询www.magedu.com.的A记录
;; ANSWER SECTION: #answer section答案部分
www.magedu.com. 86400 IN A 192.168.31.9 #答案有两个
www.magedu.com. 86400 IN A 192.168.31.8
;; AUTHORITY SECTION: #authority #权威部分,就是谁给你回应的
magedu.com. 86400 IN NS ns1.magedu.com.
magedu.com. 86400 IN NS ns2.magedu.com.
;; ADDITIONAL SECTION:
ns1.magedu.com. 86400 IN A 192.168.31.8
ns2.magedu.com. 86400 IN A 172.16.100.12
[root@zabbix ~]# dig -t A www.magedu.com @192.168.31.8 #使用@后面的DNS服务器做解析，31.8是本机 -t是用来指定类型的，可省略，dig不会使用本机设置的DNS
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 2, ADDITIONAL: 2 #aa代表权威答案Authoritative answe
www.magedu.com. 86400 IN A 192.168.31.9 #会轮询
www.magedu.com. 86400 IN A 192.168.31.8
[root@zabbix ~]# dig -t NS magedu.com. @192.168.31.8
magedu.com. 86400 IN NS ns1.magedu.com. #会轮询
magedu.com. 86400 IN NS ns2.magedu.com.
[root@zabbix ~]# dig -t MX magedu.com. @192.168.31.8
magedu.com. 86400 IN NS ns2.magedu.com. #会轮询
magedu.com. 86400 IN NS ns1.magedu.com.
[root@zabbix ~]# dig -t SOA magedu.com. @192.168.31.8
[root@zabbix ~]# dig -t A www.baidu.com. @223.6.6.6 +trace #跟踪解析的过程
跟踪访问百度的过程我们会发现是先找到了根,然后交给了com,然后baidu.com交给了负责解析baidu.com的DNS,然后负责baidu.com解析的DNS发现www.baidu.com是shifen的一个别名,于是把shifen的IP地址返回给客户端.
根-----.com-----baidu.com-----别名------shifen
host:
host的使用方法与dig的第一种使用方法差不多,只不过是去年了@符号而已
nslookup:
此命令windows上也可以使用,可交互,也可不交互使用,如下面两种使用方法:
上面两种方法默认都是调用/etc/resolv.conf里面的DNS进行的解析,我们可以通过server关键字来指定让其通过哪个DNS服务器进行解析,还可以通过set q=<资源类型>如下图:
1.1.1 反向区域
注意的点:
配置反向区域的过程与配置正向区域的流程都是一样的,但是其中的一些细节要非常注意才可以. 下面先说一下要注意的点
第一点,所谓的反向区域的作用就是把IP地址解析成FQDN,所以PTR就可以代替A记录的存在,所以在反向区域当中是不会有A记录和AAAA记录的.
第二点,在正向区域的时候域名是主角,域名可以有别名,但是反向区域的主角是IP,IP是很严肃的,所以在反向区域里面也没有别名.
第二点就是PTR的写法,PTR的写法的很奇怪,name应该是主机的IP,此IP要反着写并且不家特定的后缀,还有网络部分可省略
第三点反向区域没有mx记录,因为发邮件都通过域名,没有通过IP地地址
流程:
第一步:先创建区域解析库
声明:为了让反向区域更好命名,我把正向区域里面所有的IP都改为了192.168.31.0/24网段的了.
在创建区域解析库的时候最好依据正向区域来创建,这样更不容易出错,我们可以通过vim –o一同打开;正向区域解析库的文件名的结构是域名+zone,下面区域的域名就是我们申请的,比如magedu.com,这一点比较好理解,在这里我们可以把域名理解成为不变的部分,无论是www.magedu.com还是home.magedu.com其中不变的部分magedu.com那么我们就是正向区域的解析库命名成为了magedu.com.zone,同埋,反向区域的主角是主机的IP地址,不再是域名了,我们只要把主机的IP地址的共同部分拿出来当做域名即可,比如192.168.31.8,192.168.31.9这些IP地址的共同部分就是它们的网络部分192.168.31,所以我们只要把此IP反过来写,然后加上特定的后缀之后就
可以当做解析库的名字使用了,反过写就是31.168.192.in-addr.arpa.zone
[root@zabbix ~]# vim -o /var/named/magedu.com.zone /var/named/31.168.192.in-addr.arpa.zone
通过上面两个例子我们发现在书写反向区域的PTR时候，只要仿照正向区域的PTR写就OK了。一个正向区域的A记录对应一个反向区域的PTR记录。
第二步:在配置文件当中创建区域记录
[root@zabbix ~]# vim /etc/named.rfc1912.zones
zone "31.168.192.in-addr.arpa." IN {
type master;
file "31.168.192.in-addr.arpa.zone"; #注意这里面的文件名一定要与解析库一样,不用非得按照这个格式写，只要对应起来并且存在就好。
};
检查：
[root@zabbix ~]# named-checkzone 31.168.192.in-addr.arpa. /var/named/31.168.192.in-addr.arpa.zone
/var/named/31.168.192.in-addr.arpa.zone:1: no TTL specified; using SOA MINTTL instead
zone 31.168.192.in-addr.arpa/IN: loaded serial 2018010101
OK
[root@zabbix ~]# named-checkconf
修改权限：
[root@zabbix named]# chmod 640 31.168.192.in-addr.arpa.zone
[root@zabbix named]# chown :named 31.168.192.in-addr.arpa.zone
测试：
[root@zabbix ~]# host -t PTR 192.168.31.9 192.168.31.8 #向31.8查询31.9
9.31.168.192.in-addr.arpa domain name pointer ns2.magedu.com. #查询结果当中31即是ns2也是www
9.31.168.192.in-addr.arpa domain name pointer www.magedu.com.
上图是向31.8查询31.10，结果显示31.10是mx主机。
有正向可以没有反向,但是有反向必须要有正向,通常是这样,反向在一定程度上依赖正向。
泛域名解析：
如同上文所讲，我们的主机仅仅有www和ftp两台主机，但是用户如果输入错误，输入成wwww，或者ffttp是访问不到我们的网站的，对此，我们可以在正向查找区域里面做一个模糊匹配，加一个模糊匹配的A记录，如下：
这样再查找时无论主机名输入成什么，只要域名是magedu.com都会查找到192.168.31.8，如下图：
[root@zabbix ~]# dig -t A pop3.magedu.com @192.168.31.8
;; ANSWER SECTION:
pop3.magedu.com. 86400 IN A 192.168.31.8
[root@zabbix ~]# dig -t A magedu.com @192.168.31.8 #仅写域名不带主机也可，百度也是这样的，不信你使用dig试一下。
;; QUESTION SECTION:
;magedu.com. IN A
;; ANSWER SECTION:
magedu.com. 86400 IN A 192.168.31.8
1.1.1 正向主从同步
假如我们下面需要一个从域名服务器，而且我们在前面写正向区域的时候都定义好了是192.168.31.9，那么我们应该怎么配置呢？
一个区域内只能有一个主，但可以有多个从。
配置步骤：
再找一台服务器，先安装bind，配置成缓存DNS服务器，因为从DNS服务器也是基于缓存DNS服务器的。
假如我们找到的DNS服务器的Ip是192.168.31.9的话
第一步就要在/etc/named.rfc1912.zones里面添加一个区域，从区域也是区域
zone "magedu.com." IN {
type slave; #类型必不可少
masters { 192.168.31.8; }; #这里定义主DNS服务器的IP地址
file "slaves/magedu.com.zone"; #为什么放到这个目录里面，下文有解释
};
为什么把magedu.comf.zone放到/var/named/slaves这个目录里面呢？因为named这个进程就是named用户启动的，但是/var/named的权限是这样的：
[root@zabbix ~]# ll -d /var/named/
drwxr-x--- 5 root named 4096 1月 11 21:29 /var/named/ #named用户并没有写的权限
[root@zabbix ~]# ll -d /var/named/slaves
drwxrwx--- 2 named named 4096 1月 22 2018 /var/named/slaves #默认已经准备好了salves文件，此文件对于nemad有写权限。
第二步：在从DNS服务器上启动
从区域要在主区域的NS记录当中要有，如果没有，当主发生变化时并不会通知从服务器。在此环境当中，主DNS区域的的解析库当中有两个NS记录，一个是自己（192.168.31.8），另一个是192.168.31.9（从DNS服务器的IP），只有这样，主DNS服务器才会允许把解析库同步走
在从DNS服务器配置好区域之后就可以启动了，启动之后就会主DNS服务器那里把解析库复制过来了，复制过来之后会放在named/slaves里面，我们可以通过日志看到复制的过程，
[root@LVS slaves]# cat /var/log/messages
请注意最后一条，当从DNS服务器复制完成之后又发送了信息，因为从DNS服务器还能有从，可线性存在。
当我们修改了主解析库，要手工加1，加1保存之后，然后重载配置文件，主DNS会自动通过从DNS服务器过来同步，这个小实验值得一做。
主从复制的总结：
l 从DNS应该为一台独立的服务器
l 主服务器的区域解析库文件必须有一条NS记录是指向从服务器
l 从服务器只需要定义区域，而无须提供解析库文件，解析库文件应该早已准备好的/var/named/slaves目录当中
l 主服务器得允许服务器做区域传送，默认允许，当然也可以做禁止
l 主服务器更新从服务器会通过NS记录的所有记录，任何时间都不要改从服务器的解析库。
l 主从服务器的时候最好能够同步，可以通过NTP（时间服务器）进行
l BIND的程序版本应该要保持一致，否则，应该从高，而主低，而高版本的适应低版本的。
1.1.1 反向主从同步
反向主从同步与正向主从的配置过程是一样的，也是先添加一个区域，然后重新载入配置文件就好了，前提条件是也是要有的，前提条件就是有主DNS服务器上也要有一个有关于NS指向本机的的PTR记录才可以。
第一步：
zone "31.168.192.in-addr.arpa." IN {
type slave;
masters { 192.168.31.8; };
file "slaves/31.168.192.in-addr.arpa.zone";
};
做完之后的效果就是在/var/named/slaves目录里面又多一个文件。
正向主从同步与反向主从同步的属性是一样的，当主DNS解析库发生变化了重载了之后，都可以立马通知从DNS服务器进行同步。每一次进行同步在日志里面都有记录。
1.1.2 rndc
域名远程管理工具，虽然叫做域名管理工具，但是我们都是用它来做本地的管理，因为远程管理太不安全，我们可以用rndc来重新载入配置文件。
做为一个远程管理工具它也是侦听在套接字上的，BIND启动之后除了会侦听53端口，还有侦听953端口，这个953端口就是rndc来侦听的，客户端进行管理DNS服务器的时候就可以使用此接口访问，太不安全。
介绍几个常用的命令 ：
rndc querylog #开启了之后每次域名查询都会有日志，而日志对IO的负担又太大了，所以如果不是特殊需要不要开启，此命令即是开启也是关闭
可以通过rndc status来查询有没有开启。
rndc
用于定位问题，正常的环境不应该开启，压力太大
l rndc reload重载主配置文件和区域解析库文件
l querylog开启或者关闭查询日志
1.1.3 子域授权
子域授权，是实现分布式的一种必要的手段。
最多可以有127级，字符可以几百个字符
子域授权是在正向区域的解析库当中配置，不要去反向区域的解析库当中配置。
www做A时是主机名，做NS时就是一个域名
儿子不知道老子在哪里，但老子知道自己有几个儿子在哪里。
子域授权
父域知道自己有多少个儿子和所在的位置，而子域不知道父域是谁。
如果父域内的主机访问子域里的主机，那么就不会去找根了，因为它自己知道这个子域是自己委派出去，自己的解析库当中有记录。
子域并不知道父域是谁，自己的解析库如果没有的话就会去找根。
1.1.1 转发服务器
全部转发：
当一个DNS服务器在自己的解析为没有给客户端查找到答案时通常都会去找根了，但是我们设想这样的一个情况，.com把baidu.com授权给A-DNS服务器负责了，百度公司在百度域名的下一级又创建一域叫ops.baidu.com并且把此域名授权给了B-DNS负责。当ops.baidu.com域内的客户端把DNS指向了负责B-DNS，当此客户端想要访问www.baidu.com这个主机时（此主机由A-DNS负责解析），B-DNS的本地解析库内是没有的，B-DNS虽然是A-DNS的下级，但是B-DNS不知道A-DNS是自己的上级，B-DNS只认根提示，于是去找根了，经过一番迭代最终把结果返还给客户端。明明B是A的下级，B不懂的直接请求A不就行了吗？干吗要去找根呢？这就是规则，好在此规则可以打破，默认B-DNS是不知道A-DNS在哪里，但是我们人工可以告诉B-DNS它的是谁，当B-DNS再解析不到时就不用去找根了，直接去找它上级，让上级去迭代，那么A服务器相对一B服务器来讲，A服务器此是就是转发服务器。A服务器需要为B做递归，否则，转发请求不予以回复。
区域转发：
B不负责解析的最转给A，如果请求的域名在A的解析库由A负责就不用通过根绕路了，但是请求的域名如果不在A的解析库不由A负责的话，那么A也要去找根了，这样的话B不如直接去找根呢，犯不上去麻烦A-DNS。基于此需求，我们可以把特定的域名交给转发服务器，余下的不由自己的负责的域名统统都找根，这样问题就解决了。
总结：
被转发的服务器需要能够为请求者递归，否则，转发请求不予以进行。
(1)全部转发：凡是对非本机所负责解析的区域，统统转发给指定的服务器。
options {
forward {first|only}
forwarders
}
(2)区域转发，仅转发对特定的区域的请求至某服务器
zone “zone_NAME” IN {
type forward
forward {first | only}
forwarders
}
那么first和only有什么区别呢？
就是一个积级，一个消极的作用，
first此区域我转发给你，你如果不理我，那我就自己找根
only此区域我转发给你，你如果不理我，我就放弃，我也不找根。
子域授权实验步骤:
1) 把一台DNS服务器配置成缓存DNS服务器，再配置成主DNS服务器
2) 把另一台DNS服务器先配置成缓存DNS服务器
3) 做子域授权，做子域授权时两台DNS都有戏份
4) 验证父与子的关系
第一步配置：反一台DNS服务器配置成缓存DNS服务器，再配置成主DNS服务器，效果截图如下：
options {
listen-on port 53 { 192.168.80.8; 127.0.0.1; };
// listen-on-v6 port 53 { ::1; };
allow-query { any; };
dnssec-enable no; #不要注释这一行，而是将yes改成no
dnssec-validation no; #同上。
// /* Path to ISC DLV key */
// bindkeys-file "/etc/named.iscdlv.key";
// managed-keys-directory "/var/named/dynamic";
第二步把另一台DNS服务器先配置成缓存DNS服务器，过程略过。
第三步，最关键的一步，做子域授权，两台DNS服务器都要有配置
在第一台DNS服务器配置的域为magedu.com，在此域名又生成了一个子域名为ops.magedu.com，这个子域名不想放在第一台DNS服务器做解析，其实第一台DNS服务器做解析是没有问题，但是我们做的是子域授权的实验，所以要将ops.magedu.com授权到第二台DNS服务器做解析，应该怎么配置呢？因为ops.magedu.com是magedu.com的子域，做授权的话要在magedu.com的解析库里面做授权，配置如下：
在magedu.com里面添加授权记录
ops.magedu.com. IN NS ns1.ops.magedu.com.
ops.magedu.com. IN NS ns2.ops.magedu.com.
ns1.ops.magedu.com. IN A 192.168.80.9
ns2.ops.magedu.com. IN A 192.168.80.10
在80.9这台DNS主机上创建域解析库
zone "ops.magedu.com." IN {
type master;
file "ops.magedu.com.zone"
};
做完后的效果就是在父域上能够解析子域的主机，但是子域并不能解析父域的主机，本来就应该是这样的效果，因为在DNS有世界里面，子域并不知道父域是谁，但是父域知道子域的位置。
下面就来配置转发服务器。
我们想实现这样一个效果，当子域查询父域的主机时原本是找不到的，找不到就会找根，这不是我们期望的，我们希望当子域访问父域内的主机时能够转发给父域，不要找根了，免得绕路。但是子域内的主机如果访问不是父域内的主机给父域也没什么用，所以当子域内的主机访问非本域和父域的主机时，直接 转发给根即可。
而父域访问子域本来是天生的，不用再做配置了，如果访问的非父域和子域内的主机，直接去找根就好了.
子域的配置步骤：
我们想实现的效果就是在当子域访问父域的主机时不要去找根了，直接去找父域就得，如果不找父域内的主机，就去找根即可。
zone "magedu.com" IN {
type forward;
forward only;
forwarders { 192.168.80.8; };
};
通过以上的配置就可以实现当子域访问父域的主机时不要去找根了，直接去找父域就得，如果不找父域内的主机，就去找根。假如我们的子域并不能上网，当访问非本域和父域的主机时去找根时根本找不到，这样不好，我们想实现这样一个效果，当子域访问非本域的主机都扔给父域，自己什么都不管了，这样其实也可以。
我们把刚才的配置删除，然后配置：
[root@LVS ~]# vim /etc/named.conf
forward first;
forwarders { 192.168.80.8; };
[root@LVS ~]# rndc flush #清空缓存
如果全局转发和区域转发同时存在的话，遵守精确匹配原则，先区域，匹配失败的话再全局。
Chapter1 安全配置
基础知识：
bind有四个内置的ACL
none：没有一个主机
any：任意主机
local：本机
localnet：本机所在的网段
ACL把一个或多个地址合并成为一个集合，并通过一个统一的名称调用。
注意，只能先定义，后使用，因此，其一般定义在配置文件的option前面。
让有限有主机可复制解析库：
首先明确，为什么需要安全配置，举个例子，当我们配置完一个主DNS服务器之后 ，默认任何都可以请求到我们的解析库，通过dig axfr请求到，这非常的不安全，别人通过你的解析库会把内网的拓扑画出来，这样不安全。
[root@zabbix ~]# vim /etc/named.conf
acl slaves{ #定义在option的前面，名字叫做slaves
192.168.80.8;
127.0.0.1;
};
[root@zabbix ~]# vim /etc/named.rfc1912.zones
zone "magedu.com" IN {
type master;
file "magedu.com.zone";
allow-transfer { slaves; }; #调用上面定义的slaves
允许有限的用户查询：
默认添加的域都是默认允许任何人查询的，这样不安全，所以：
[root@zabbix ~]# vim /etc/named.conf
acl query{
192.168.80.0/24; #网段
};
[root@zabbix ~]# vim /etc/named.rfc1912.zones
zone "magedu.com" IN {
type master;
file "magedu.com.zone";
allow-query { query; }; #仅允许192.168.80.0这个网段的主机能够查询，如不有此项，允许所有。
};
帮助哪些主机递归：
公司的花钱做的DNS服务器不应该帮助别的公司的主机做递归，只允许给自己公司网段的主要做递归，所以：
[root@zabbix ~]# vim /etc/named.conf
acl mynet {
192.168.80.0/24;
};
options {
// recursion yes; #比较特殊，要在全局里面设置，而不是到区域里面了。
allow-recursion { mynet; };
允许与DHCP服务器连动：
如果www服务器是自动获得IP地址的话，那么DNS服务器的里面的对应关系也要随时更改，这太麻烦了，所以DNS可以与DHCP一块联动，当www服务器的IP变化之后DNS里面的IP也要变化，这样看似很好，实则非常的危险，因为DHCP容易被×××，一×××就混乱，HDCP混乱引起DNS混乱就麻烦了，所以不要开启此选项。
[root@zabbix ~]# vim /etc/named.conf
zone "magedu.com" IN {
type master;
file "magedu.com.zone";
allow-update { none; } #none是内置的acl
Chapter2 bind view
2.1 理论
视图功能可以实现智能DNS解析，那么何为智能DNS解析？
中国的网络现状是大型网络电商在电信、联通、移动机房里面都有服务器，都放在一个运营商机房不行吗？是不行的，为什么？
三大运营商之间的带宽仅仅有100G,100G对于广大网民来讲还是太少,假如淘宝的服务器都放置在电信机房的话,那么联动和移动的用户访问都很慢,所以淘宝在每个运营商机房里都放置了服务器,让用户就近访问,因为网站的速度决定了网站的访问量,一个网站的用户体验越是好访问量越高.这种情况下用户是体验不出来的,无论是电脑,联动 ,移动的用户访问淘宝都是www.taobao.com,而且页面都是一样的,用户感觉不到是因为智能DNS做的定位,当电信的用户向DNS解析淘宝的IP时根据源IP来判断该客户是哪个运营商的,如果用户是电信的,就把在电信机房的那台淘宝服务器的IP回复, 如果用户是联动的,就把在联动机房的那台淘宝服务器的IP回复,这就是DNS的视图功能.
那么它是怎样实现的呢?
智能DNS其实就是把BIND原本的配置文件给拆分成不同的视图，我们可以理解成把原本的配置文件切割成不同的块，然后我们每个块里面可以定义多个区域，不同的块之间也一般也是有相同的域，每一个块的最前面都有一个匹配项目，如果客户端的源地址被某一个块给匹配上了，那么就把这个块里面客户端要查询的主机DNS回复给客户端。不同的用户访问同一个网站并且使用在同一个DNS服务器可能会得到不同的解析结果。
总结：一个BIND服务器可以定义多个视图，第个视图当中可定义一个或多个zone，每个视频都在匹配一组客户端，每个视图可能需要对同一个区域进行解析，但使用不同的区域解析库文件。
NOTE：
l 一旦启用了view，所有的zone都只能定义在视图当中
l 仅有必要在公司用户所在的视图中定义根区域
l 客户端请求到达时，是自上而下检查每个视图所服务的客户端列表。
仅有必要在公司用户所在的视图当中定义根区域。当BIND启用了视图了之后，所有的区域，包括默认的区域都要转移到视图下面，那么根区域需要转移到哪个区域呢？假设我们的服务器分成三个视图，第一个视图主要匹配来自电信的用户，第二个视图主要匹配来自联通的用户，第三个视图匹配来自公司内部的用户，当然要把根放置到第三个区域当中，第一个视图和第二个视图匹配到的用户都是到本服务器查询域名对应的IP的，第三个视图是公司内部的自己人的（通常是私网地址），但自己的用户向DNS请求时如果本地有就直接返回答案，如果没有就帮助客户端去递归。、
定义视图的格式：
view NAME {
match-client { 匹配条件 };
}
1.1 配置步骤
第一步：把根区域从/etc/named.conf移动到/etc/named.rfc1912.zone
第二步：在/etc/named.conf定义一个acl名为mynet匹配本地网络
acl mynet {
192.168.80.0/24;
127.0.0.1
};
第三步：把/etc/named.rfc1912.zone这个文档内的所有区域都一个区域里面，把这个区域取名为internal
view internal {
match-clients { mynet; };
allow-recursioin { mynet; }; #仅给nynnet，也就是内网用户递归
中间是/etc/named.rfc1912.zone所有的内容
}; #最后别忘了加括号
这样的话只有192.168.80.0这个网段的客户端可以可以使用80.8查询了，20网段的不行，测试一下才好。
第四步：再/etc/named.rfc1912.zone区域最下面再定义一个视图为externet（外网用户），并且这个视图里面加一上区域也叫做magedu.dom，此区域在internal视图里面也有定义。
view externel {
match-clients { any; }; #因为规则是从上到下的，上一个视图规则不上之后，才会交由下一个视图匹配，所以使用any也可
zone "magedu.com" IN { #maged.com这个区域在上一个视图也有定义
type master;
file "magedu.com.external"; #解析库文件为了和上一个视图的magedu.com区域区分开，换了一个
allow-update { none; };
};
[root@zabbix named]#cp magedu.com.zone magedu.com.external -a #保留属性
把magedu.com.external里面的关于magedu.com的A记录的IP改成外网IP
实验效果就是当我们使用80.0网段的主机和20.0网段的主机查询同一个主机名www.magedu.com会返会不同的结果.
淘宝是怎么做的，淘宝的DNS服务器应该就是223.6.6.6和223.5.5.5.5（可能不仅限于），阿里公司的DNS服务器由阿里公司自己维护的，这两个DNS在本地应该有阿里旗下各域名，而且阿里很无私把这两个DNS给开放给了网民，一个是无私，另一个是对自己实力的自信，而且淘宝应该把中国所有运营商的网段都获得了，通过IP网段来区别客户端是来自哪个运营商。
亚太地区的信息中心，请求全国的IP分配数据库
CDN内容分发网络缓存DNS服务器使用的
1.2 提高用户访问速度
1.2.1 方案一
淘宝在各地的服务器并不是网站本体真正所在的位置，而是缓存服务器，它拥有和本地一模一样的内容，这个内容是本体通过CDN内容分发网络实现的，这是国内大型网络最常用的一种解决方案。
CDN（content delivery network）通常是配合智能DNS实现的。
1.2.2 方案二
第二种方案国内使用的不多，不再需要智能DNS服务器，把客户端请求的域名IP都返回到一个负载均衡器上，负载均衡器并不提供网页，负载均衡为判断源IP（同智能DNS差不多）把距离用户最近的缓存服务器的IP返回经客户端。