1. 从一个真实运维场景说起为什么单台DNS服务器迟早会出事很多团队在项目初期为了图省事往往只部署一台DNS服务器所有内网域名解析、外部域名转发都压在这一台机器上。刚开始几十台机器的时候确实没什么问题查询量小、配置简单、改一条记录重启一下服务就完事。但只要业务规模稍微往上走一点问题就会集中爆发某天这台机器磁盘满了、服务进程莫名挂掉、或者机房网络抖了一下整个内网瞬间失联——不是网络断了而是所有依赖域名访问的服务全部解析失败监控告警一片红业务方电话直接打爆。我在实际项目里就遇到过类似的情况。当时一套内部系统依赖十几个域名做服务发现DNS服务器一挂所有微服务之间的调用全部超时排查了半天才发现根因在DNS上。从那以后但凡涉及到DNS的项目我都会坚持两件事主从复制保证高可用分离解析保证内外网各取所需。这两个机制几乎是中大型网络环境里DNS部署的标配也是很多面试和实际排障中绕不开的核心考点。这篇内容就围绕主从复制和分离解析这两个核心能力展开把原理、配置、验证、踩坑经验完整地讲一遍。不管你是刚接触DNS运维的新手还是想把这套方案落地到生产环境的工程师都能从中拿到可以直接复用的配置思路和排查方法。文中涉及的具体域名、IP、主机名均为演示用的虚构示例实际部署时替换成你自己的环境即可。2. 主从复制到底复制了什么区域传输的底层逻辑2.1 主从架构解决的核心问题主从复制的本质是把一台DNS服务器主服务器Master上的区域数据同步到一台或多台备用服务器从服务器Slave上。这样做的直接收益有三个第一主服务器故障时从服务器可以顶上继续提供解析业务不中断第二多台服务器可以分摊查询压力尤其是查询量大的场景第三主从之间可以做负载均衡客户端配置多个DNS地址时能分散请求。这里要先厘清一个容易混淆的概念主从复制同步的是区域数据不是整个配置文件。也就是说主服务器上named.conf这类主配置文件并不会自动同步到从服务器从服务器需要自己配置好监听、访问控制、区域声明等基础配置只有区域文件zone file里的记录才会通过区域传输Zone Transfer机制同步过来。这一点是很多新手第一次配主从时最容易搞错的地方——他们以为从服务器什么都不用配结果服务根本起不来。2.2 区域传输的两种模式全量AXFR与增量IXFR区域传输分两种AXFRFull Zone Transfer全量传输和IXFRIncremental Zone Transfer增量传输。AXFR会把整个区域文件从头到尾传一遍简单粗暴但开销大IXFR只传输自上次同步以来发生变化的记录效率高但需要服务器支持并正确维护序列号Serial。从服务器判断是否需要同步靠的是区域文件里的SOA记录中的Serial字段。从服务器会定期向主服务器查询SOA如果发现主服务器的Serial比自己大就发起区域传输。所以每次修改区域文件后必须手动递增Serial值否则从服务器根本不知道数据变了。Serial的常见写法是YYYYMMDDnn格式比如2024011501表示2024年1月15日的第1次修改。我见过太多人改完记录忘了改Serial然后纳闷为什么从服务器一直不同步——这个坑几乎每个DNS运维都踩过。2.3 主从配置的关键参数逐条拆解下面用BIND最主流的DNS服务软件为例把主从配置里几个关键参数讲清楚。主服务器的区域声明大致是这样zone example.internal IN { type master; file /var/named/example.internal.zone; allow-transfer { 192.168.10.12; }; # 只允许指定从服务器拉取 also-notify { 192.168.10.12; }; # 记录变更时主动通知从服务器 };从服务器的区域声明则是zone example.internal IN { type slave; file slaves/example.internal.zone; masters { 192.168.10.11; }; # 指定主服务器地址 };这里有几个细节值得展开。allow-transfer是安全关键项绝对不能写成any否则任何人都能把你的完整区域数据拉走等于把内网拓扑图拱手送人。also-notify的作用是主服务器记录变更后主动推送通知让从服务器立刻同步而不是干等刷新周期到期能显著缩短数据不一致的时间窗口。从服务器的file路径通常放在slaves目录下这个目录需要给named进程写权限否则同步会失败但日志里不一定报得明显。2.4 序列号、刷新周期与过期时间的配合关系SOA记录里除了Serial还有几个时间参数需要理解它们之间的配合Refresh刷新间隔、Retry重试间隔、Expire过期时间、Minimum最小TTL。它们的关系可以这样理解从服务器每隔Refresh时间检查一次主服务器的Serial如果检查失败每隔Retry时间重试一次如果一直联系不上主服务器超过Expire时间后从服务器就认为自己的数据过期停止对外提供该区域的解析服务。这几个值的设置是有讲究的。Refresh设太短会增加主服务器负担设太长会导致数据同步延迟Expire设太短主服务器稍微抖一下从服务器就停止服务了设太长又可能导致从服务器长时间提供过期数据。一般内网环境Refresh设1到4小时、Retry设15到30分钟、Expire设1到2周是比较稳妥的区间。这些不是死规定要根据你实际的变更频率和网络稳定性来调。3. 分离解析的实现思路让内外网看到不同的答案3.1 分离解析要解决的现实矛盾分离解析Split DNS / Split Horizon解决的是一个很现实的矛盾同一个域名内网用户和外网用户应该解析到不同的地址。最典型的场景是公司内部有一个服务app.example.com内网用户访问时应该走内网地址比如192.168.10.50以获得更快的速度和更低的成本而外网用户访问时应该走公网地址比如某个公网IP。如果只有一套解析要么内网用户绕到公网再绕回来要么外网用户拿到一个根本访问不到的内网地址。另一个常见场景是安全隔离内部系统的主机名不应该暴露给外部外部查询这些域名时应该返回一个无意义的结果或者直接拒绝。分离解析让同一台DNS服务器或同一组服务器针对不同来源的查询返回不同的视图View从而同时满足内网优化和外部安全两个目标。3.2 基于View的视图隔离机制BIND实现分离解析的核心是View视图。你可以定义多个View每个View匹配特定的客户端来源用match-clients指定网段然后在每个View里声明各自的区域。查询请求进来后BIND会按顺序匹配View第一个匹配上的View生效后续View不再参与。一个典型的双View配置结构如下view internal { match-clients { 192.168.10.0/24; 10.0.0.0/8; }; recursion yes; zone example.com IN { type master; file /var/named/example.com.internal; }; }; view external { match-clients { any; }; recursion no; zone example.com IN { type master; file /var/named/example.com.external; }; };这里有几个关键点必须注意。View的匹配顺序至关重要internal必须放在external前面因为external用了any会匹配所有来源如果它排在前面内网请求也会被它截走分离解析就失效了。另外每个View里都要完整声明该View需要服务的所有区域包括根区域、本地回环区域等不能只声明业务区域否则该View下的其他解析会出问题。还有一点recursion递归在内网View里通常开启在外网View里建议关闭避免被利用做DNS放大攻击。3.3 内外网区域文件的差异化设计两个View对应两份区域文件内容差异要精心设计。内网区域文件里可以放大量内部主机记录、内部服务别名甚至一些只在内部使用的CNAME外网区域文件里只保留必须对外公开的记录内部主机名一律不放或者放一个指向无效地址的占位记录。举个具体的对比假设内网有db.example.com指向192.168.10.60这个数据库服务器绝对不应该对外暴露。那么内网区域文件里正常写这条A记录外网区域文件里要么完全不写这个域名外部查询返回NXDOMAIN要么写一条指向127.0.0.1的记录做误导。我个人的习惯是外网区域只放真正需要对外服务的记录其余一律不出现这样最干净也最安全。3.4 主从与分离解析的叠加部署实际生产环境里主从复制和分离解析往往是叠加使用的主服务器和从服务器上都要配置相同的View结构每个View下的区域各自做主从同步。这就带来一个配置上的要求——主从两边的View定义必须一致包括View名称、匹配顺序、区域列表否则同步会出问题。具体来说主服务器的internalView里的区域同步到从服务器时也要落在从服务器的internalView里。如果从服务器缺少对应的View或者View顺序不一致区域传输就会失败。我在一次部署中就因为从服务器漏配了一个View导致那个View下的区域死活同步不过来日志里报的是no matching view排查了好一阵才定位到。所以配置主从加分离解析时建议先把View框架在两边都搭好再逐个区域去配主从关系这样不容易漏。4. 手把手落地从零搭一套主从加分离解析环境4.1 环境规划与角色分配先明确演示环境。假设我们有两台服务器主服务器ns1192.168.10.11从服务器ns2192.168.10.12。内网网段是192.168.10.0/24业务域名用example.internal纯内网和example.com内外网分离。操作系统以常见的Linux发行版为例BIND版本用9.x系列。规划的时候有个经验主从服务器的系统时间一定要同步因为SOA的Serial、日志时间戳、区域传输的超时判断都和系统时间相关。时间不同步可能导致一些诡异的问题比如从服务器认为主服务器的数据来自未来而拒绝同步。部署前先用时间同步服务把两台机器的时间对齐能省掉后面很多麻烦。4.2 主服务器的完整配置主服务器的named.conf核心部分如下先定义全局选项再定义Viewoptions { listen-on port 53 { 127.0.0.1; 192.168.10.11; }; directory /var/named; allow-query { localhost; 192.168.10.0/24; }; allow-transfer { 192.168.10.12; }; recursion yes; }; view internal { match-clients { 192.168.10.0/24; }; recursion yes; zone example.internal IN { type master; file example.internal.zone; allow-transfer { 192.168.10.12; }; also-notify { 192.168.10.12; }; }; zone example.com IN { type master; file example.com.internal; allow-transfer { 192.168.10.12; }; also-notify { 192.168.10.12; }; }; }; view external { match-clients { any; }; recursion no; zone example.com IN { type master; file example.com.external; allow-transfer { 192.168.10.12; }; also-notify { 192.168.10.12; }; }; };注意allow-transfer在全局和区域级别都写了区域级别的会覆盖全局的这样更精细。also-notify只在主服务器上写从服务器不需要。4.3 区域文件的编写要点内网区域文件example.internal.zone示例$TTL 3600 IN SOA ns1.example.internal. admin.example.internal. ( 2024011501 ; Serial 3600 ; Refresh 900 ; Retry 1209600 ; Expire 3600 ) ; Minimum TTL IN NS ns1.example.internal. IN NS ns2.example.internal. ns1 IN A 192.168.10.11 ns2 IN A 192.168.10.12 app IN A 192.168.10.50 db IN A 192.168.10.60这里Serial用了2024011501每次改记录都要递增。NS记录里同时写了主从两台这样解析器知道这个区域有两台权威服务器。example.com的内网和外网区域文件结构类似区别在于记录内容——内网版可以包含app指向内网地址外网版则指向公网地址且不含db这类内部记录。4.4 从服务器的配置与同步验证从服务器的named.conf里View结构要和主服务器保持一致只是区域类型改成slave并指定mastersview internal { match-clients { 192.168.10.0/24; }; recursion yes; zone example.internal IN { type slave; file slaves/example.internal.zone; masters { 192.168.10.11; }; }; zone example.com IN { type slave; file slaves/example.com.internal; masters { 192.168.10.11; }; }; }; view external { match-clients { any; }; recursion no; zone example.com IN { type slave; file slaves/example.com.external; masters { 192.168.10.11; }; }; };配置完成后重启服务然后验证同步是否成功。最直接的方法是看从服务器的slaves目录下有没有生成区域文件以及日志里有没有transfer completed之类的记录。也可以用dig命令指定从服务器查询看返回结果是否和主服务器一致。如果没同步成功先检查主服务器的allow-transfer是否放行了从服务器IP再检查两边的View是否匹配最后看Serial是否递增了。5. 验证与排错那些日志不会直接告诉你的坑5.1 主从同步失败的常见原因排查链路主从同步失败是最高频的问题排查要按链路走不要东一榔头西一棒子。我的排查顺序是这样的第一步确认网络连通性。从服务器能不能访问主服务器的53端口用telnet或nc测一下。很多同步失败其实是防火墙把53端口挡了尤其是TCP 53区域传输走TCP普通查询走UDP只放行UDP是不够的。第二步确认allow-transfer配置。主服务器的allow-transfer必须包含从服务器IP写错了或者写成none都会导致传输被拒。日志里通常会报transfer of xxx from xxx failed: permission denied。第三步确认Serial是否递增。如果Serial没变从服务器根本不会发起传输这种情况日志里什么都不会报最容易被忽略。第四步确认View匹配。主从两边View名称、顺序、区域列表不一致时传输会失败日志报no matching view或类似信息。第五步确认文件权限。从服务器的slaves目录要可写区域文件生成后属主应该是named进程用户权限不对会导致写入失败。5.2 分离解析不生效的典型表现分离解析不生效的表现很直观内网用户查询app.example.com拿到的却是外网地址。原因通常有几个。最常见的是View顺序写反了external用了any却排在internal前面导致所有请求都被外网View截走。其次是match-clients网段写错比如内网是192.168.10.0/24却写成了192.168.1.0/24内网请求匹配不上内网View自然落到外网View。还有一种情况是客户端来源经过了NATDNS服务器看到的源地址是NAT后的地址不在预期的内网网段里导致匹配失败。排查时可以用dig从不同来源测试或者临时在View里加日志看请求落到了哪个View。BIND的querylog开启后能看到每个查询匹配的View定位起来很快。5.3 序列号忘记递增引发的连锁反应前面反复强调Serial这里再展开说一下它的连锁反应。假设你改了内网区域文件加了一条新记录但忘了改Serial。主服务器自己查询是正常的因为它直接读文件但从服务器因为Serial没变不会同步于是从服务器返回的还是旧数据。如果客户端配置了主从两个DNS地址就会出现有时能解析、有时不能的诡异现象——查询落到主服务器就正常落到从服务器就失败。这种间歇性故障最难排查因为单看任何一台服务器都没问题。我的习惯是把Serial递增作为修改区域文件的固定动作改完记录立刻改Serial形成肌肉记忆。有些团队会用脚本自动生成Serial比如基于时间戳也能避免人为遗漏。5.4 日志分析的关键字段BIND的日志里和主从、分离解析相关的关键信息集中在几个地方。区域传输成功会记录transfer of zone from master succeeded失败会记录具体原因比如permission deniedallow-transfer问题、connection refused网络或服务问题、no matching viewView配置问题。查询日志里能看到每个查询的客户端地址、查询域名、匹配的View、返回结果。建议把日志级别调到info以上区域传输和View匹配的信息才会详细记录。生产环境如果日志量太大可以针对特定类别单独配置日志通道避免日志把磁盘写满。6. 生产环境里的加固与优化经验6.1 访问控制与安全加固DNS服务暴露在网络上安全加固不能省。除了前面说的allow-transfer限制还要注意allow-query和allow-recursion。allow-query控制谁能查询你的服务器内网服务器建议只放行内网网段allow-recursion控制谁能使用你的递归功能外网View一定要关闭递归否则你的服务器会变成开放解析器被利用做放大攻击。另外BIND的版本要及时更新历史上出过不少可被远程利用的漏洞。如果条件允许把DNS服务跑在受限的账户下用chroot隔离进一步降低被攻破后的影响范围。这些加固措施看起来繁琐但一旦出事代价远比配置成本高。6.2 性能调优的几个方向查询量大的场景下DNS性能调优有几个方向。一是开启缓存递归查询的结果缓存起来减少向上游的查询次数二是调整TTL内网记录TTL可以设短一点方便变更外网记录TTL设长一点减少查询压力三是多从服务器分摊一台主服务器配多台从服务器客户端配置多个DNS地址做负载四是监控查询量和响应时间及时发现异常。我一般会关注几个指标每秒查询数QPS、缓存命中率、区域传输耗时、失败查询比例。这些指标异常时往往能提前发现潜在问题比如某个域名被疯狂查询可能是配置错误导致的查询风暴。6.3 变更管理与灰度发布DNS变更的影响面很大一条记录改错可能导致大面积服务不可用。所以变更管理很重要。我的做法是先在从服务器上验证变更确认无误后再推到主服务器变更前备份区域文件出问题能快速回滚变更后立即验证用dig从多个来源测试解析结果Serial递增和变更记录同步进行方便追溯。如果变更影响范围特别大可以考虑灰度——先让一部分客户端用新解析观察一段时间没问题再全量。DNS本身没有灰度机制但可以通过调整TTL、分批改记录来模拟。6.4 监控告警该盯哪些点DNS的监控告警要盯住几个关键点服务进程存活进程挂了要立刻告警、端口可达性53端口不通说明服务异常、主从同步状态Serial是否一致、同步是否及时、查询响应时间突然变慢可能是攻击或配置问题、查询失败率失败率飙升说明有问题。这些指标用常见的监控工具都能采集配置好阈值告警能在问题扩大前介入。我个人特别看重主从同步状态的监控因为同步失败往往是静默的——服务还在跑查询还能返回只是数据是旧的。等业务方发现数据不对时可能已经过了很久。所以定期比对主从的Serial不一致就告警是很有必要的。7. 几个容易被忽略的细节与个人体会7.1 关于View与递归的取舍分离解析里内网View开递归、外网View关递归是常规做法但有些场景需要更细的考量。比如你的DNS服务器同时要给内网用户做递归解析又要作为某些域名的权威服务器对外服务这时候View的划分就要更谨慎。我的经验是把权威和递归的职责尽量分开权威服务器专注回答自己负责的区域递归服务器专注帮内网用户查外部域名两者不要混在一台机器上这样配置清晰、安全边界也清楚。7.2 关于区域文件的可维护性区域文件是纯文本记录多了以后可维护性会变差。建议做好注释按功能分组比如把所有Web服务记录放一起、所有数据库记录放一起。有条件的话用配置管理工具生成区域文件避免手工编辑出错。Serial的生成也可以自动化减少人为遗漏。7.3 关于测试环境的必要性DNS变更的风险前面说了很多所以一定要有测试环境。测试环境不用和生产的规模一样但主从结构、View结构要和生产一致这样验证过的配置才能放心推到生产。我见过不少团队直接在生产的从服务器上试配置试出问题影响面就大了。测试环境加上完善的回滚预案是DNS运维的安全底线。7.4 一个真实踩坑的复盘最后分享一个我印象比较深的坑。有一次给一个项目配分离解析内网View和外网View都配好了测试也通过了。上线后过了一段时间有用户反馈内网访问某个服务时快时慢。排查发现部分内网客户端的请求没有匹配到内网View落到了外网View拿到了公网地址绕了一圈才回来。根因是这些客户端所在的网段不在match-clients里——那个网段是后来新增的配置的时候漏了。这件事让我养成了一个习惯每次网络规划有变动都要回头检查DNS的View匹配网段是否需要更新。DNS配置不是配完就一劳永逸的它需要跟着网络环境一起演进。这套主从加分离解析的方案我在多个项目里落地过稳定性经得起考验。核心就是把区域传输的机制吃透、把View的匹配逻辑理清、把变更和监控的流程建好。剩下的就是根据自己环境的实际情况去调整参数和结构多测、多验证、多复盘慢慢就形成适合自己团队的DNS运维体系了。
