次域名服务器是什么意思？，次域名服务器怎么设置？

次域名服务器是主域名服务器的“备胎”，也叫辅助域名服务器，它定时从主服务器同步DNS记录，在主服务器宕机或无法响应时接管解析任务，确保网站不因DNS故障而无法访问。很多人第一次听到“次域名服务器”会想到“二级域名”，这完全是两码事，二级域名是域名体系的层级概念，而次域名服务器是DNS架构里的冗余机制，如果你正在运营一个对可用性要求较高的网站，或者刚买了一台服务器准备搭建NS环境，搞清楚它是什么、和主域名服务器的配合逻辑、以及怎么配置,是绕不开的基础课。

次域名服务器是什么，它和主域名服务器有什么区别？

先从一台DNS服务器的职责说起

任何一台DNS服务器，核心工作就是回答“这个域名对应哪个IP”，你可以把它理解成通讯录的查询台，当用户浏览器输入你的网址，系统会先问本地网络商（如电信、联通）的DNS，如果那里没有缓存，就会一路往上找，最终找到你域名的权威DNS服务器也就是你设置的那台。

主域名服务器（Primary/Master DNS Server）是域名记录的权威来源，所有DNS记录的增删改查都在它上面完成，它是“生产源数据”的地方。

次域名服务器（Secondary/Slave DNS Server）本身不直接编辑数据，它按照设定的时间间隔，从主服器上同步一份完整的区域数据副本，用户解析域名时，既可以问主服务器，也可以问次服务器，谁响应快、谁的线路好,就用谁的。

两者的核心区别，可以这样理解

• 数据来源不同：主服务器存的是“原始数据”，次服务器存的是“复制数据”。
• 操作权限不同：日常增删改查解析记录，只在主服务器上操作,次服务器只负责读取和同步。
• 故障表现不同：主服务器挂了，次服务器依然能提供解析服务；如果只有主服务器，主服务器一宕机,整个域名解析就瘫痪了。
• 同步机制不同：次服务器通过AXFR（全量传输）或IXFR（增量传输）协议从主服务器拉取数据，这个过程叫“区域传送”。

一个容易被忽略的细节：权威与非权威

虽然不是所有场合都需要区分，但如果你对DNS协议感兴趣，会注意到“权威应答”和“非权威应答”这两个概念，次域名服务器同步了完整数据后，在它自己看来，它也是这个区域的权威服务器，它发出的应答就是权威应答，它和主服务器一样,都处于域名树中的权威位置。

局域网内部搭建次域名服务器怎么操作？

除了公网上的域名解析，很多企业内部网络、开发测试环境也需要自己的DNS服务，这时候，“局域网次域名服务器搭建”就是一个很常见的需求，假设你在一家公司上班，内网里有一台Linux服务器装的是BIND，你想加一台备用DNS防意外,可以参考下面的思路。

准备阶段

• 两台Linux服务器，一台作主（例如IP为192.168.1.10），一台作从（例如IP为192.168.1.11）。
• 两台机器上都装上BIND9，Ubuntu或Debian系统用sudo apt install bind9安装，CentOS/RHEL系统用sudo yum install bind安装。
• 主服务器上已经配置好区域文件，例如内网域名internal.company.local。

主服务器端的配置

在主服务器的/etc/bind/named.conf.local中，找到你原来写的那个zone块,你要允许次服务器来拉取数据：

zone "internal.company.local" { type master; file "/etc/bind/db.internal.company.local"; allow-transfer { 192.168.1.11; }; # 只允许这台备用机传输区域数据 also-notify { 192.168.1.11; }; # 数据有变化时主动通知它 };

然后运行sudo named-checkconf检查配置文件，如果没问题，用sudo systemctl reload bind9重载配置。

从服务器端的配置

在次服务器的/etc/bind/named.conf.local里，添加一模一样的域名区域，但类型改成slave：

zone "internal.company.local" { type slave; file "/var/cache/bind/db.internal.company.local"; masters { 192.168.1.10; }; };

这里的file路径可以写在一个本地可写的目录，BIND会在这个文件里保存同步下来的数据副本，改完后同样检查语法，然后重启服务：sudo systemctl restart bind9。

验证同步结果

在次服务器上执行ls -l /var/cache/bind/，如果能看到一个列表文件出现，说明同步成功,再用命令行工具测试解析：

dig @192.168.1.11 internal.company.local

如果返回了正确的内网IP，说明这台次服务器已经开始正常值班了，以后即使主服务器重启，内网电脑只要把备用DNS指向192.168.1.11,域名解析就不会中断。

购买云解析服务时，次域名服务器有什么隐藏作用？

很多人用的是云厂商的DNS解析服务，比如简米云解析、西西云DNSPod，这些平台自带多节点冗余，不太需要用户自己去搭次域名服务器，但有一种情况需要你留意：你自建了DNS，或者你在域名注册商那里填写了自定义的NS记录。

当你注册域名时，注册商会要求你设置NS记录，也就是指定哪些服务器来权威解析你的域名,通常需要填两个NS，

ns1.yourdomain.com ns2.yourdomain.com

这里的ns1

和ns2分别指向你自建的主次DNS服务器，行业共识认为，至少配置两台位于不同物理位置的DNS服务器，是保障解析稳定的底线，如果两个NS指向的IP在同一个机房，甚至同一台物理机上，那么机房一断电，两个都挂了，“冗余”就形同虚设。

更深入的考虑：从节点分布角度

如果你对解析速度和容灾要求更高，可以把次服务器放在另一家云服务商的机房，这样即使一家云厂商出现大面积故障，另一家的节点还能继续工作，对于域名流量较大的业务来说,这种做法能有效减少因单点故障导致的用户流失。

关于主次域名服务器同步机制，你需要知道的关键细节

区域传送是怎么触发的？

次服务器同步主服务器的数据，依赖一个叫SOA记录（起始授权记录）的东西，SOA里有一个“序列号”字段，主服务器每次更新数据，序列号就要递增，次服务器每隔一段时间（刷新时间）来问一次主服务器的序列号，发现序号变了,就开始拉取最新数据。

你改了解析记录之后，一定要记得把SOA序列号加大，如果你用的是云解析平台，这个操作平台会自动处理；如果你是手动修改区域文件，就要自己留意,否则会出现改了不生效的情况。

同步失败会怎样？

如果次服务器连续多次无法联系上主服务器（重试时间耗尽），它会认为区域数据过期，但不会立即放弃，SOA里还有一个“过期时间”，在过期之前，次服务器依然会用它已有的缓存数据继续应答，过期时间到了之后，才会丢弃这些数据,停止对外的解析应答。

这个机制对实际运维的启示是：不要把过期时间设得太短，否则主服务器故障超过一天,你的备用DNS也会自动撂挑子。

DNSNOTIFY通知的作用

传统的轮询机制依赖次服务器主动来问，有延迟，后来发展出了NOTIFY消息机制：主服务器数据一旦变化，立即发一条通知给次服务器，让它们马上来同步，配置时只要在主服务器上加上also-notify,就会大大缩短数据传播的延迟。

内外网场景下，次域名服务器的作用有哪些重点差异？

公网域名解析对性能要求更苛刻，次服务器的部署位置要尽量贴近用户，内网环境则更看重与Active Directory（AD域）的配合，Windows Server的DNS服务器把主备同步做得比较透明,网管人员在图形界面里点几下就能完成。

次域名服务器配置后常见问题排查思路

为什么从服务器一直收不到数据？

先检查主服务器的allow-transfer是否写对了IP，再检查防火墙是不是放行了TCP和UDP的53端口，区域传送支持TCP协议,别只放UDP就草草收工。

为什么同步成功了，客户端解析还是走主服务器？

客户端的DNS配置写的是哪台，就查哪台，很多电脑的DNS服务器地址是自动获取的，不会自动切换到你的次服务器，想让次服务器真正发挥作用，你可以考虑在出口路由器或DHCP服务里，把DNS列表同时填上主、次服务器的IP。

主服务器挂了，次服务器解析正常吗？

正常情况下是正常的，但这里有一个坑：如果主服务器是在权威区设置里最后一个应答的NS，而次服务器的数据在规定时间内没来得及同步，那客户端可能问到了次服务器，却没有得到完整数据，务必将主次服务器的NS记录都添加到注册局的NS列表里,并且保持数据一致性。

次域名服务器相关常见问题解答

次域名服务器可以只买一台云服务器来同时跑主备吗？

不建议这样操作，如果两台DNS服务器跑在同一台物理机上，它们的故障域完全相同，当这台机器宕机或者被机房隔离时，所谓的“冗余”就失效了，真正的冗余必须体现在物理隔离上，比如不同的可用区（AZ）或者不同的云服务商。

使用国外注册商的免费DNS服务，还需要自建次服务器吗？

这取决于你的容灾需求，如果域名解析极其重要，对可用性要求接近100%，建议自建一台次服务器，用不同的域名注册商或托管商来托管，形成双活，如果只是普通个人站点或中低流量业务，使用注册商的DNS服务已经足够了，不必额外投入维护成本，域名解析数据本身很轻量，一台低配服务器就能承载大量域名记录,运维的精力成本才是主要开销。

修改主服务器TXT记录后，次服务器多久能同步到？

同步速度取决于SOA记录中的刷新间隔和NOTIFY机制，如果你在配置时启用了DNS NOTIFY，次服务器会在几秒到几十秒内收到通知并开始同步，如果未启用，就只能等待次服务器按刷新时间主动询问，这个时间可能是一小时或更长，手动加快同步的方式，是在次服务器上执行rndc retransfer internal.company.local（BIND环境）强制重新传输,或重启BIND服务触发同步逻辑。