1网卡设置配置文件里面DNS服务器地址设置，2.系统默认DNS服务器地址设置。3,hosts文件指定
生效顺序是：
1 hosts文件 ---- 2 网卡配置文件DNS服务地址 ---3 /etc/resolv.conf

查询方式
递归：客户端和本地DNS服务器的查询就属于递归查询，客户端发出查询请求后处于等待状态，本地DNS以客户端身份询问下一个DNS服务器，直到本地DNS服务器返回确定回复或否定答复
简记：我问你，你问他

迭代：根域名服务器提供顶级域名服务器ip ,loacalnmserver 继续向顶级域名查询，直到获取到真实应答。
他不知道，但是提供了知道的C，继续向c询问

主机向本地DNS发出的请求是递归查询
本地DNS向根域名服务器发出的查询通常是迭代查询，

请求流程：

Client -->hosts文件 → > /etc/reslov.conf ----->>DNS Service Local Cache --> DNS Server (recursion) --> Server Cache --> iteration(迭代) --> 根
--> 顶级域名DNS-->二级域名DNS…

服务器类型
主名称服务器(primary name server)
从名称服务器(secondary name server)
缓存名称服务器（caching-only serve）

主要配置
name.conf
acl　　定义ip地址的访问控制清单
control　　定义rndc使用的控制通道
include　　把其他的文件包含到配置文件中
key　　定义授权的安全密钥
logging　　定义日志内容和位置
options　　定义全局配置选项和默认值
server　　定义远程服务的特征
zone　　定义一个区

操作：
yum -y install bind*
rndc：remote name domain controller，默认与bind安装在同一主机，且只能通过127.0.0.1连接named进程提供辅助性的管理功能；953/tcp
用rndc reload也是可以通知从服务器过来同步信息的。
手动通知某一个区域过来同步信息 rndc notify magedu.com
配置文件 /etc/named.conf
解析数据库，即zone 文件存放位置 /var/named/ZONE_NAME.ZONE
复制系统已有文件并修改，注意属主属组权限
cp -p localhost.loopbask
在主配置文件中定义区域
vim /etc/named.conf
zone "example.com" IN {
type master ;
file "example.com.zone";
};

vim /var/named/example.com.zone

$TTL 1D
$ORIGIN example.com.
@ IN SOA ns1.example.com. admin.example.com (
# . . 完全写的时候需要带点，
20190419 （序列号【-----更改过文件后一定要在序列号上面加一否则从服务器是没办法同步！！！-----】）
1H ；刷新时间
5M ；重试时间
7D ；过期时间
1D) ；否定答案的TTL值
IN NS ns1
IN NS ns2
IN MX 10 mx1
IN MX 20 mx2
ns1 IN A 192.168.36.73
ns2 IN A 192.168.36.73
mx1 IN A 192.168.36.73
mx2 IN A 192.168.36.73
webser1 IN A 192.168.36.73
webser2 IN A 192.168.36.73
www IN CNAME websrv

资源记录的解释：
区域解析库：由众多RR组成：
资源记录：Resource Record, RR
记录类型：A, AAAA, PTR, SOA, NS, CNAME, MX
SOA：Start Of Authority，起始授权记录；一个区域解析库有且仅能有一个，必须位于解析库的第一条记录

A IPV4地址
AAAA v6地址
PTR IP ---→ FQDN
NS：Name Server，专用于标明当前区域的DNS服务器
CNAME ： Canonical Name，别名记录
MX：Mail eXchanger，邮件交换器
TXT：对域名进行标识和说明的一种方式，一般做验证记录时会使用此项，如：SPF（反垃圾邮件）记录，https验证等
示例：_dnsauth TXT 2012011200000051qgs69bwoh4h6nht4n1h0lr038x

 SOA记录       name: 当前区域的名字，例如“magedu.com.”    value: 有多部分组成    (1) 当前区域的主DNS服务器的FQDN，也可以使用当前区域的名字；    (2) 当前区域管理员的邮箱地址；但地址中不能使用@符号，一般用.替换例如：admin.magedu.com    (3) 主从服务区域传输相关定义以及否定的答案的统一的TTL

注意：

主配置文件语法检查：named-checkconf
解析库文件语法检查：named-checkzone "magedu.com" /var/named/magedu.com.zone
配置生效：rndc reload 或 service named reload

测试命令
dig [-t type] name [@SERVER] [query options]
dig只用于测试dns系统，不会查询hosts文件进行解析
查询选项：

+[no]trace：跟踪解析过程 : dig +trace magedu.com
+[no]recurse：进行递归解析测试

模拟区域传送：
dig -t axfr ZONE_NAME @SERVER
dig -t axfr magedu.com @10.10.10.11

dig -t NS . @114.114.114.114
dig -t NS . @a.root-servers.net

host [-t type] name [SERVER]

host 1.2.3.4

nslookup命令： nslookup [-option] [name | -] [server]

反向解析区域
区域名称：网络地址反写.in-addr.arpa.
172.16.100. --> 100.16.172.in-addr.arpa.

(1) 定义区域
zone "36.168.192.in-addr.arpa"{
type master ;
file "36.168.192.zone" ;
};

(2) 定义区域解析库文件注意：不需要MX,以PTR记录为主

区域示例
$TTL 1D
$ORIGIN 100.16.172.in-addr.arpa.
@ IN SOA ns1.magedu.com. admin.magedu.com. (
# ns1 如全名需要注意 .com.
2015042201
1H
5M
7D
1D )
IN NS ns1.magedu.com.
IN NS ns2.magedu.com.
11 IN PTR ns1.magedu.com.
11 IN PTR www.magedu.com.
12 IN PTR mx1.magedu.com.
12 IN PTR www.magedu.com.
13 IN PTR mx2.magedu.com.

缓存服务器

缓存服务器只需要根区域解析库文件，不包含任何其它区域解析库文件，这样的服务器就叫着缓存服务器。这样的服务器只有缓存搜寻结果的功能，也就是说它本身并没有主机名与IP正反解的配置文件，完全是由对外的查询来提供它的数据源。
配置

recursion选项
recursion选项决定服务器是否可以进行递归查询，如果只作为dns缓存服务器，这个选项必须是yes。
bind 安装后默认为缓存服务，来自客户端的的请求转发至根，
# vi /etc/named.conf
options {
listen-in port 53 { any; };
directory "/var/named";
allow-query { any; };
recursion yes;
};
指定转发域

  options{       //省略部分设置    forward only;       forwarders{           114.114.114.114;        8.8.8.8;            };   }

缓存服务器获取的请求直接向根域查询，获取结果后返回给客户端，并将结果储存一定时间

转发服务器
forwarding dns服务器连根区域解析库都不需要，而是将客户端的查询请求直接转发给上层DNS服务器去处理，也就是说原本要发往根服务器的查询请求直接丢给了上层DNS服务器去处理

DNS转发功能的实现主要是方便优先共享DNS数据库资源，节省查询时间，而不必每次一级一级的递归去询问根，这样节省带宽流量的时间。
first意思是如果请求不能得到响应，则DNS会向根一级级询问，而only如果不能响应就会报无法解析。
vi /etc/named.conf
options {
listen-on port 53 { any; };
directory "/var/named";
allow-query { any; };
recursion yes;
forward only;
forwarders { 8.8.8.8; 8.8.4.4; };
};
转发服务器，分为全局转发及目标区域转发，如有指定域的查询，将转发至指定的上层DNS
forward only:
表示这台服务器仅仅作为转发服务器，即使有根区域的设置也不会去找根，只会将查询交给上层DNS去处理。
forwarders 后面的IP表示其上层DNS服务器

从服务器
主从同步方式
推：主触发条件，我变化了通知你（以版本号作为更新触发条件）
拉：从触发条件，轮询以时间间隔询问（比对数据库版本号）
2015042201 版本号
1H 刷新时间（轮询时间）
5M 重试时间
7D 过期时间
1D ) 否定答案的TTL 值（不存在记录的时间值
DNS主从复制，就是将主DNS服务器的解析库复制传送至从DNS服务器，进而从服务器就可以进行正向、反向解析了
从服务器向主服务器查询更新数据，保证数据一致性，此为区域传送。
DNS区域传送，就是DNS主从复制的实现方法，DNS主从复制是DNS区域传送的表现形式。
DNS区域传送有两种方式

axfr：完全区域传送

ixfr：增量区域传送

当一个新的DNS服务器添加到区域中并配置为从DNS服务器时，它则会执行完全区域传送，在主DNS服务器上获取完整的资源记录副本；同时，为了保证数据同步，主域名服务器有更新时也会及时通知辅助域名服务器从而进行更新（增量区域传送）。

从服务器只需要定义区域，而无须提供解析库文件；解析库文件应该放置于/var/named/slaves/目录中
主服务器得允许从服务器作区域传送
主域zone需配置
容许进行域传送的 example.com 的辅域名服务器地址
allow-transfer {
192.168.4.14; 192.168.5.53;
};

主从服务器时间应该同步，可通过ntp进行；
bind程序的版本应该保持一致；否则，应该从高，主低
定义从区域的方法：

allow-transfer {none ;};

zone "ZONE_NAME" IN {
type slave;
masters { MASTER_IP; };
file "slaves/ZONE_NAME.zone";
};

全量区域传送配置：
1，主服务器named.conf 配置：添加 notify yes 通知从服务器

2编辑主服务器/etc/named.rfc.1912.zones添加区域定义信息
zone "example.com" IN {
type master;
file "example.named.zone" ;
};
zone "1.168.192.in-addr.arpa" IN {
type master ;
file "1.168.192.in.addr.zone" ;
}

3.在/var/named/下添加解析库文件并配置 在修改主服务器的正反解数据库文件时，添加了从域名服务器的NS记录和A记录，在数据库文件中要有记录声明本区域内DNS服务器的数量，否则无法查询到条目记录。 example.named.zone

1.168.192.in.addr.zone
4 ，从服务器修改
vim /etc/resolv.conf
nameserver 主服务器的IP
5，复制主服务器的配置文件至本地
#scp 主服务器IP:/etc/named.rfc1912.zones /etc/
　 #scp 主服务器ip:/etc/named.conf /etc/
修改复制过来的文件属主属组权限
修改配置文件类型
allow-trans
zone "example.com" IN {
type slave;
mastes {主服务器ip; };
file "slaves/example.named.zone" ;
};
zone "1.168.192.in-addr.arpa" IN {
type slave ;
mastes {主服务器ip; };
file "1.168.192.in.addr.zone" ;
}
6,重启服务
7.查看从服务器/var/named/slaves/目录下是否有传送成功的区域文件

增量区域传送 1，修改主服务正向解析文件，增加以下一条A记录（测试用） ，将序列号加1后保存退出

2，reload主DNS服务器，查看日志
#systemctl reload named
# tail /var/log/messages
3，再查看从服务器的日志，可查看到已经传送成功。
4，查看从服务器的正向解析文件，可看到已经同步了一条数据

子域授权

相当于是划片管理，是由上至下的授权。由根开始"."。

DNS中最重要的就是NS记录,其中每个NS里面的负责人就是SOA，在父域上定义一条NS记录和一条A记录就可以完成子域授权了

类似根域授权tld：
.com. IN NS ns1.com.
.com. IN NS ns2.com.
ns1.com. IN A 2.2.2.1
ns2.com. IN A 2.2.2.2

magedu.com. 在.com的名称服务器上，解析库中添加资源记录
magedu.com. IN NS ns1.magedu.com.
magedu.com. IN NS ns2.magedu.com.
magedu.com. IN NS ns3.magedu.com.
ns1.magedu.com. IN A 3.3.3.1
ns2.magedu.com. IN A 3.3.3.2
ns3.magedu.com. IN A 3.3.3.3

子域里添加从服务器时，外界无法使用，需要在授权服务器里添加NS 记录
tech.magedu.com. IN NS dns.tech.magedu.com.
dns.tech.magedu.com. IN A 172.16.17.1
tech.magedu.com.IN NS ns2.tech.magedu.com.
ns2.tech.magedu.com. IN A 172.16.17.2

远程的查询时没有主从之分的，主从服务器只是本地管理区域传送的时候有意义，
当用户查询的时候，服务器这里是轮循返回信息，这种方式实现负载均衡。

父域解析库文件配置

 vi /var/named/frank.com.zone $TTL 1D frank.com.  IN SOA  master.frank.com.    admin.frank.com. (         201802002   ;序列号         3H               ;刷新时间         10M             ;重试时间间隔         1W              ;过期时间         1D               ;无法解析时否定答案的TTLֵ         ) frank.com.           IN  NS  master.frank.com. mf.frank.com.        IN  NS  sub.mf.frank.com. master.frank.com.    IN  A   192.168.138.200 sub.mf.frank.com.    IN  A   192.168.138.201 frank.com.           IN  MX 10  mx1.frank.com.                      IN  MX 20  mx2.frank.com. mx1.frank.com.       IN  A   192.168.138.200 mx2.frank.com.       IN  A   192.168.138.200 www                  IN  A   192.168.138.200 master               IN  CNAME   www.frank.com. web                  IN  CNAME   www.frank.com.

子域配置（子服务器

子域区域配置
vi /etc/named.conf
...
zone "mf.frank.com" IN {
type master;
file "mf.frank.com.zone";

      如有父域请求则转发（此条删去）                  zone "frank.com" IN {            type    forward;             forward only;               forwarders { 192.168.138.200; };              };

子域区域解析文件

# vi /var/named/mf.frank.com.zone
$TTL 600
@ IN SOA sub.mf.frank.com. admin.sub.mf.frank.com. (
201802001
2H
15M
1W
1D )
@ IN NS sub.mf.frank.com.
sub IN A 192.168.138.201
www IN A 192.168.138.201
rndc reload

智能dns
创建视图，目标ip段的acl文件，如该ip符合acl范围，则根据区域配置文件进行查询。

https://www.centos.bz/2012/02/cnc-chinanet-bind-intelligent-dns-deploy/

  [ $( rpm -q bind ) ]   && echo  "bind  installed"||   echo "has not installed "   main () {     echo "-----------------------------"     # zone  configure      read -t 30  -p "name of main zone like xxxx.com :" zone      read -t 30  -p " ip  of main zone" ip     echo  "   U  should  modfy  it  after  excute  this  "     sed  -ri.bk   's/(listen-on port 53).*/\1 { any ; } ; / ;s@(allow-query ).*@\1 {  any ; };@ '   /etc/named.conf     cat  >> /etc/named.conf <<EOF zone "$zone"  IN { type  master ; file  "$zone.zone" ; } ; EOF cat  > /var/named/$zone.zone  <<EOF \$TTL  1D \$ORIGIN  $zone. @    IN   SOA    ns1.$zone  admin.$zone (            `date  +%Y%m%d`           1H           5M           7D           1D )          IN   NS  ns1 ns1      IN    A  $ip 73       IN    A  $ip www      IN  CNAME  73  EOF }       recuser() {       echo "should  modfiy   where  like  xxxxxx  "     cat  >> /etc/named.conf <<EOF zone "xxxxx.in-addr.arpa" { type   master ; file   "xxxxx.zone" ; }; EOF  cat  > /var/named/xxxx.zoncat  <<EOF $TTL  1D $ORIGIN   xxxxxx.in-addr.arpa. @  IN  SOA   ns1.xxxxxx.com.  admin.xxxxxx.com. (   20190419   1H   5M   7D   1D )     IN    NS    ns1.xxxxxx.com. xx  IN   PTR    xxxxxxx.com. xx  IN   PTR    xxxxxx.com. } EOF }   main

关于域名解析的授权

首先是两个相关的概念：
域名授权：指定谁是该域名的权威DNS，即由谁负责解析该域名（由NS记录操作完成）。
权威DNS: 特指对特定域名具有权威发布能力的DNS；互联网上域名（域名记录）解析结果的原出处。
目前域名解析授权状况：
目前在互联网上域名解析授权大体上是谁出售域名就把域名的权威DNS授权给谁并由其提供域名的权威DNS来完成域名解析工作，如购买了新网域名默认就是由新网的权威DNS（nsx.xinnetdns.com、nsx.xinnet.cn）负责所售域名解析:

[root@test root]#dig @a.gtld-servers.net xinnet.com ns
;; ANSWER SECTION:
xinnet.com. 172800 IN NS ns.xinnet.cn.
xinnet.com. 172800 IN NS ns.xinnetdns.com.
xinnet.com. 172800 IN NS ns2.xinnet.cn.
xinnet.com. 172800 IN NS ns2.xinnetdns.com.
域名解析授权是怎么实现的：
域名解析授权是个树状的，从上而下的分层体系，简图如下：
xxa.jpg

首先“.”DNS把COM/NET/CN/ORG/TV等等域名按后缀的不同分别授权给不同的DNS，以利于分别管理。如COM/NET域名被授权给了如下几个权威DNS。
这里不难想像要修改COM/NET的授权DNS要到“.”DNS上去操作才能完成。
[root@test root]#dig com. ns
;; ANSWER SECTION:
com. 96045 IN NS d.gtld-servers.net.
com. 96045 IN NS g.gtld-servers.net.
com. 96045 IN NS b.gtld-servers.net.
com. 96045 IN NS k.gtld-servers.net.
com. 96045 IN NS f.gtld-servers.net.
com. 96045 IN NS l.gtld-servers.net.
com. 96045 IN NS j.gtld-servers.net.
com. 96045 IN NS a.gtld-servers.net.
com. 96045 IN NS i.gtld-servers.net.
com. 96045 IN NS m.gtld-servers.net.
com. 96045 IN NS e.gtld-servers.net.
com. 96045 IN NS h.gtld-servers.net.
com. 96045 IN NS c.gtld-servers.net.
同理可知，要指定或修改ABC.COM的权威DNS要去顶级DNS上操作。通常来说一般的域名所有者是无权登录顶级DNS进行操作的。只能通过域名提供商（如新网，万网等）的专用接口（位于域名商的域名管理平台上）来间接操作顶级DNS上的记录。
以ABC.COM为例简要说明怎么指定自己的权威DNS，假设ABC.COM是在新网购买，那么默认该域名的权威DNS就是nsx.xinnetdns.com、nsx.xinnet.cn。这时候要修改默认权威DNS。首先登录新网的域名管理后台，找到修改域名DNS页面即可完成操作（详细过程这里有：http://www.2cto.com/net/201210/161851.html）。操作完成后要验证一下是否修改成功：
[root@test root]#dig @a.gtld-servers.net abc.com ns
;; ANSWER SECTION:
abc.com. 172800 IN NS ns1.ai-dns.com.
abc.com. 172800 IN NS ns2.ai-dns.com.
abc.com. 172800 IN NS ns3.ai-dns.com.
这里我们把ABC.COM授权给了nsx.ai-dns.com了。
关于域名权威DNS的再授权：
以ABC.COM为例，再授权是指在nsx.ai-dns.com上面再次指定该域名的权威DNS，再授权的意义有这么几个：

扩展现有的权威DNS数量，如现有ns1,ns2,ns3.ai-dns.com共三台DNS，现在要增加到4台，则可以在原3台DNS上abc.com的ZONE文件内增加
ns4这个NS记录。
原来的ZONE内容：
$TTL 2d
$ORIGIN abc.com.
@ 3600 IN SOA ns1.ai-dns.com. root.ai-dns.com.(
2288091841 1h 600 1w 900 )
@ 2d IN NS ns1.ai-dns.com.
@ 2d IN NS ns2.ai-dns.com.
@ 2d IN NS ns3.ai-dns.com.
增加ns4这个NS记录后为：
$TTL 2d
$ORIGIN abc.com.
@ 3600 IN SOA ns1.ai-dns.com. root.ai-dns.com.(
2288091841 1h 600 1w 900 )
@ 2d IN NS ns1.ai-dns.com.
@ 2d IN NS ns2.ai-dns.com.
@ 2d IN NS ns3.ai-dns.com.
@ 2d IN NS ns4.ai-dns.com.
当然增加NS4的操作也可以在顶级DNS上完成，不再赘述。
把权威DNS重新授权给其他DNS，如把原来的权威DNS（nsx.ai-dns.com）重新授权给别人（nsx.ddd.com）。操作过程同上，不再赘述。
再授权可能存在的潜在问题：
再授权无疑使得域名解析授权变得更灵活，但是存在以下潜在的隐患。当原授权的权威DNS（即在顶级DNS定义的权威DNS）故障时，这时再授权的D
NS将无法工作，导致域名无法解析（这是由域名解析过程是自上而下的这个特性决定的）。同时也增加了安全隐患。
附加部分1：慎用WHOIS来查看域名权威DNS。
对于域名的Whois数据库是由域名销售商控制的，即每个域名销售商都有自己的WHOIS服务器，这些服务器用来存储自身出售的域名信息，如域名所有人，联系方法，到期时间等内容。WHOIS信息中显示的域名当前权威DNS信息很可能没有及时与域名实际的权威DNS信息同步而导致错误的判断。
附加部分2：“.”根DNS是怎么被授权的？
由于“.”根DNS所处域名解析体系的顶端，无法按照常规方法对其授权。到目前为止其授权方法是把所有“.”DNS列表存放在一个文本文件内（自己授权给自己），名字通常为root.hint内容如下（部分节选）：
. 3600000 IN NS A.ROOT-SERVERS.NET.
A.ROOT-SERVERS.NET. 3600000 A 198.41.0.4
. 3600000 NS B.ROOT-SERVERS.NET.
B.ROOT-SERVERS.NET. 3600000 A 192.228.79.201

1.权威DNS：
权威DNS是经过上一级授权对域名进行解析的服务器，同时它可以把解析授权转授给其他人，如COM顶级服务器可以授权ABC.COM的权威服务器为NS.ABC.COM，同时NS.ABC.COM还可以把授权转授给NS.DDD.COM，这样NS.DDD.COM就成了ABC.COM实际上的权威服务器了。平时我们解析域名的结果都源自权威DNS

2.递归DNS:
负责接受用户对任意域名查询，并返回结果给用户。递归DNS的工作过程参见本文第二节。递归DNS可以缓存结果以避免重复向上查询。我们平时使用最多的就是这类DNS，他对公众开放服务，一般由网络运营商提供，大家都自己可以架递归DNS提供服务。递归DNS一定要有可靠的互联网连接方可使用
3.转发DNS:
负责接受用户查询，并返回结果给用户。但这个结果不是按标准的域名解析过程得到的，而是直接把递归DNS的结果转发给用户。它也具备缓存功能。他主要使用在没有直接的互联网连接，但可以连接到一个递归DNS那里，这时使用转发DNS就比较合适。其缺陷是：直接受递归DNS的影响，服务品质较差。

互联网上域名解析授权大体上是谁出售域名就把域名的权威DNS授权给谁并由其提供域名的权威DNS来完成域名解析工作

域名解析授权是个树状的，从上而下的分层体系，简图如

指定或修改ABC.COM的权威DNS要去顶级DNS上操作。通常来说一般的域名所有者是无权登录顶级DNS进行操作的。只能通过域名提供商（如新网，万网等）的专用接口（位于域名商的域名管理平台上）来间接操作顶级DNS上的记录

dig @a.gtld-servers.net abc.com ns
域名权威DNS的再授权
在zone区域再次添加NS记录，此操作在顶级DNS上执行
把权威DNS重新授权给其他DNS，如把原来的权威DNS（nsx.ai-dns.com）重新授权给别人（nsx.ddd.com），即修改顶级域名服务器该域配置文件的SOA记录。（在网络域名服务提供商处修改授权dns,前提是在另一个网络服务提供商处已添加了必须的记录，）

智能dns

网通用户向本地DNS请求解析WWW.ABC.COM。
本地DNS向ABC.COM的权威DNS（这里的权威DNS一定是智能DNS）。
智能DNS根据请求者（这里是本地DNS）的IP地址在自己的ACL里面进行匹配，然后把匹配的结果返回给本地DNS。
本地DNS把结果告诉用户，并把结果缓存起来。
用户访问网通线路上的网站服务器

特别关注；

智能DNS判断用户来源的依据是“本地DNS”而非是用户自身的IP地址。
由上延伸，如果电信用户使用了网通DNS，通过智能DNS将会匹配到网通的解析结果。
本地DNS一般情况下不会亲自向智能DNS请求解析，这是由本地DNS的网络拓扑决定的

域名迁移

域名迁移就是修改域名的权威DNS，即将域名ABC.COM的原权威DNS由A迁移到B。实际工作中最常见的形式是将域名转到另一家DNS服务商来解析

正确流程：

首先到B把你的域名添加上去，包括SOA、NS、A、CNAME、MX记录等。然后用dig/nslookup等工具验证一下是否刚才添加的记录是否生效，如验证A记录WWW.ABC.COM： dig @B WWW.ABC.COM A
到原域名注册商处修改域名权威DNS为B，即修改域名的NS记录为B。注意，位于域名原权威DNS上的其他各种记录要保留一段时间不要马上删除。然后在该域名的顶级域DNS上验证一下刚才的修改是否生效。如验证ABC.COM现在的权威DNS：dig @a.gtld-servers.net ABC.COM NS
三、域名迁移的过渡期：
域名权威DNS由A转移到B的过程中域名解析权发生变化，世界各地的递归DNS要知道这个变化需要一段时间，因为各地DNS都缓存了该域名以前的状态，更新到最新的状态需要时间

过渡期时长的确定：
我们对域名进行trace查询以便了解该域名NS记录的TTL值。如查询CN类域名。

dig xxx.cn ns +trace

xxx.cn. 21600 IN NS ns.xxx.cn.
xxx.cn. 21600 IN NS ns.xxx.com.
;; Received 83 bytes from 203.119.25.1#53(A.DNS.cn) in 46 ms
xxx.cn. 21600 IN NS ns.xxx.cn.
xxx.cn. 21600 IN NS ns.xxx.com.
;; Received 83 bytes from 129.44.79.4#53(ns.xxx.cn) in 78 ms
上面权威DNS与顶级域DNS上NS记录的TTL值相同，则过渡期为21600秒

特殊情况，如果该域名的原权威DNS上定义的该域名NS记录的TTL值与顶级域DNS上定义的值不同。则这个时候原权威DNS上的TTL为有效值。如163.cn:

dig 163.cn ns +trace

163.cn. 21600 IN NS ns1.newfavor.net.

163.cn. 21600 IN NS ns2.newfavor.net.

;; Received 72 bytes from 203.119.28.1#53(D.DNS.cn) in 62 ms

163.cn. 10800 IN NS dns1.amway.com.

163.cn. 10800 IN NS ns2.newfavor.net.

163.cn. 10800 IN NS ns1.newfavor.net.

;; Received 174 bytes from 61.145.126.88#53(ns1.newfavor.net) in 93 ms

可以看到该域名在顶级域上NS记录的TTL为21600，而在权威DNS上有重新定义为10800，则这个时候原权威DNS上的TTL为有效值。

在实际工作中稳妥起见我们取两者中较大的为最后的参考值。
下面列出几种域名NS记录的TTL值：
COM. TTL = 172800 (48Сʱ)
NET. TTL = 172800 (48Сʱ)
ORG. TTL = 86400 (24Сʱ)
CN. TTL = 21600 (6Сʱ)

zone区域，该文件保存在权威DNS上
@ 3600 IN SOA ns1.ddd.com. root.ddd.com.

为该域名的SOA记录部分，这里的@代表域名本身。ns1.ddd.com表示该域名的主权威DNS。root.ddd.com表示该主权威DN

named 启动报错排查

named -gc /var/named/etc/named.conf

配置操作及执行的日志

named.conf配置log:  logging {  channel warning  { file "log/named.log" versions 3 size 2048k;  severity warning;  print-category yes;  print-severity yes;  print-time yes;  };  channel query  { file "log/query.log" versions 3 size 2048k;  severity info;  print-category yes;  print-severity yes;  print-time yes;  };  category default { warning; };  category queries { query; };  };