1. DNS解析到底在解决什么问题1.1 为什么服务器IP和域名是两回事DNS是那本分布式通讯录我在刚接触网络服务那会儿也一直以为DNS就是“把域名变成IP”这么简单后来真正把它拆开才意识到这件事的本质其实是“人能用语言找到机器”。你回想一下任何人访问一个网站能记住的往往是www.example.com这种域名而不是一串192.0.2.10这样的IPv4或者一长串IPv6地址。原因很简单人类擅长记语义化的词不擅长记数字。但网络底层的路由、握手、转发又全都依赖IP地址。这两者之间的翻译工作就叫“域名解析”。假如没有DNS大家就只能在手机里手动保存一份“域名和IP对应表”改一次IP就得通知全天下这种模式在互联网规模下根本活不下去。所以DNS本质上就是一本分布式的、被拆散在成千上万台机器上的超大型通讯录每个节点只负责一小部分区域的“姓名为IP”对应关系但又通过一套协议互相串联让任何人查任意一条记录都能得到一个权威且高效的答案。这也是为什么我在给别人讲“DNS域名解析服务”的时候一定会先纠正一个错觉DNS并不单单是一个软件或者一台服务器。你部署的那个服务只是通讯录里的一个节点可能是负责查询的角色也可能是负责回答的角色甚至两者兼有。搞清楚自己的服务在整个体系里扮演什么后面配置时才不会一百个问号。1.2 域名那棵倒挂的树以及一次查询的全过程要读懂DNS解析必须先接受一个事实域名是一个树状结构根在最上面而不是最前面。一个完整域名例如blog.example.com按从右往左的读法来理解最右边的com是顶级域名往左的example是二级域名再往左的blog是主机记录。每到一个层级就对应一组不同的DNS服务器在负责回答。这也是“分布式”的核心来源——没有任何一台服务器需要知道全世界所有域名它只需要知道自己负责的那一小片并且知道“我不知道的话该去找谁”。一次完整的解析流程大概是这样的客户端先查自身的本地缓存和本地hosts文件如果里面有直接就返回了连网络包都不用发。本地没有就发请求给配置好的递归解析服务器这通常是你路由器、运营商或者内部环境指定的那台。递归解析器先从根服务器问起拿到com顶级域的服务器地址。往com顶级域服务器问example.com应该找谁拿到权威服务器的地址。最后向example.com的权威服务器问blog这条记录得到IP。递归解析器把结果返回给客户端并且在自己缓存里留一份。整个过程看起来复杂但实测在几毫秒到几十毫秒内就能完成。这背后靠的是各级缓存你不必每次都从根逐步问到底。我说这些是想提醒你如果要去搭建或调优DNS域名解析服务不懂全链路就很容易踩坑。比如有的人只看权威端配置觉得改了记录就能立刻全球生效却忘了上游递归器和客户端缓存还存在旧的TTL也有人只配置递归转发却搞不清上游该填谁最终产生一堆超时日志。这些都是后话先把树状模型和解析流水线记在脑子里后面每一步都会顺很多。2. 解析服务常见的三种形态别一上来就选权威2.1 权威解析、递归缓存、转发代理三者的分工差异很多初学者在搭建DNS域名解析服务时第一反应是“我要建一个权威DNS”但实际工作环境里绝大多数时间你需要的并不是纯权威。我习惯把解析服务分成三种形态它们的核心职责完全不同配置思路也截然不同。形态核心职责典型场景能否回答外部域名权威解析只负责回答自己管理的域名对外官网、业务域的最终答案提供方不能它只认自己的区递归解析代替客户端从根逐级查询最终拿到任意域名地址运营商DNS、公司内网用户级DNS能查询全量域转发/缓存把请求转给上游解析器自己做缓存和策略控制局域网内DNS、跨网加速场景能但依赖上游形象一点说权威解析就像“户籍档案室”只提供本辖区居民的档案递归解析就像“帮你跑腿打听路的问路员”不管问哪里都帮你查转发模式则像是“中间二房东”自己不做户籍登记但知道找谁最容易问到答案同时会把热门答案抄录一份放在自己手里。在公司内部做DNS域名解析服务最常见的组合是内部域名用权威解析的模式维护记录外部域名用转发模式交给上游。这两种角色绑在同一个服务里是完全可以的而且这也是最贴近真实需求的形态。2.2 选型背后的考量性能、成本、运维复杂度我见过不少人在选型时一上来就挑重型的区域传输方案或者为了一个几十人的测试网上了好几层集群。其实做选型之前可以先做三个小学数学题。第一 算QPS预期。把峰值并发量乘以每个客户端平均每秒发起的DNS请求数再算上重试的多余系数比如100个客户端每个平均0.5 QPS峰值可能是两倍那就是100条每秒。这个量级下随便一个开源DNS服务都能轻松扛住没必要上集群。第二 算记录规模。内部域名几百条记录这属于“小字典”单机配置完全没问题。但如果你的场景是Top级域名托管有几十万条记录那才需要考虑分区、同步和主从设计。第三 算可用性要求。DNS服务挂掉的后果是“虽然线上机器还在但用户找不到地址”这比Web服务挂掉更难排查。所以即便量很小我也建议至少做成两台一台主一台从用区域传输同步数据从机负责兜底。我的个人经验是DNS域名解析服务里“稳定”排在“性能”前面。解析慢50毫秒用户基本没感觉但解析失败一次用户就是白屏和连接超时。所以选型时优先选择有成熟缓存、支持主从同步和具备日志审计能力的产品形态而不是追求极限吞吐。3. 从零搭建一套能跑起来的内网DNS解析服务3.1 我先说清楚目标环境后面所有配置都是围绕它展开的为了让你能直接照着抄我以一套典型的公司内部环境为例。假设某公司内部有一个测试网络网段是192.168.50.0/24里面有办公系统、代码仓库、生产演示环境几台服务器。没有独立DNS所有人配置的都是路由器分发的地址导致内部主机只能通过IP访问难记且每次变更都要群发通知。我们要做的事是把这台DNS服务的IP定为192.168.50.10让它负责三件事解析内部域名internal.example到对应的内网IP作为递归转发器把不在内部域名范围内的请求转发给公共上游DNS给办公网内的所有终端提供统一的解析出口顺便做缓存加速。这个方案对应到配置里就是“权威区 转发”混合模式这也是我认为最贴近真实生产环境、又不至于一上来就大动干戈的配置。3.2 安装与最小化配置先把服务拉起来再谈优化我用的是当前社区里非常常见的一款开源DNS服务配置文件长得像下面这样。关键是把监听地址、上游地址和区域文件三处先填对。服务监听部分我指定监听192.168.50.10的53端口同时回环地址也允许访问方便本机调试。53端口是DNS的固定端口。请求外部域名的部分我指定了几个公共上游DNS服务器并且开启domain-needed和bogus-priv两个选项。前者是为了避免内网机器把不带点的主机名也当成完整域名往外送后者是防止上游把私网IP段返回给我们这两个设置对内部环境特别有用。内部域名解析部分我声明了一个internal.example的权威区域并指定区域文件路径。这个配置不会很复杂但它决定整个解析服务的基础形态务必确认文件路径和权限是正确的否则服务启动时直接报错起不来。3.3 正向解析记录A、AAAA、CNAME、MX分别怎么用区域文件是DNS权威解析的核心内部用户能不能用域名访问服务全看这几行记录写没写对。我用下面的示例做一个解释。第一条A记录把git.internal.example指向192.168.50.21第二条A记录把wiki.internal.example指向192.168.50.22第三条CNAME把docs.internal.example当作wiki.internal.example的别名第四条MX把邮件交换记录指向mx.internal.example对应地址是192.168.50.25。有人说这几行看起来平平无奇我讲几个容易犯的细节错误。第一 不要在同一区域里混写没有点结尾和有点结尾的写法。在区域文件里git会被自动拼接成git.internal.example但你写git.internal.example后面不加点系统有可能把它当子域再拼一遍结果变成git.internal.example.internal.example。规范做法是完整域名结尾加一个点比如git.internal.example.这样最安全。第二 CNAME不能和别的记录共存于同一名称。docs.internal.example如果既想当别名又想有A记录大部分DNS服务会直接拒绝加载区域。你要是真需要某个名字同时对应两种结果就用A记录指向实际IP或者把服务设计成同一个域名下多主机而不是依赖CNAME叠加。第三 MX记录后面的优先级数字要合理。如果只有一个邮件服务器填10就行不要多个MX都填同一个数字否则会造成主备不分。内部测试环境更常见的情况是根本没有邮件服务那就干脆不写MX写了一个指向不存在的地址反而会让邮件系统出现投递超时。3.4 TTL、反向解析以及缓存参数的计算思路好多人在配置DNS域名解析服务时最不重视的就是TTL但实际上它和用户体验、故障恢复速度直接挂钩。TTL全称是生存时间单位是秒它告诉所有下游的缓存服务“这条记录可以在缓存里存活多久”。我见过一个典型案例内部服务切换IP结果运维在旧IP上已经停服了但新IP迟迟不生效因为之前的TTL设成了86400也就是24小时。所有客户端和递归器都在旧缓存里转圈。这里有一个基本的设定逻辑预计多久会变更一次记录就让TTL比这个变更周期短一个数量级。内部服务如果每个月都可能调整IPTTL设成300秒到600秒比较稳妥。对外部域名如果你希望减少递归器压力可以设大一些比如3600秒到7200秒。接着是反向解析也就是PTR记录。正向是把域名解析成IP反向是把IP解析回域名。内部环境里不少人会跳过反向区配置但我在实际审计日志时发现很多服务会做反向验证比如邮件服务器、日志分析平台、部分堡垒机它们想确认“这个IP是不是对应那个域名”。没有PTR记录这些系统偶尔会出现奇怪的警告或拒绝连接。配置反向区时要按“反向子网”来命名区域。比如192.168.50.0/24这个网段对应的反向区是50.168.192.in-addr.arpa注意是倒着写的IP网段。然后在里面给每台主机补充对应的PTR记录。FTP或者内部监控系统查IP来源时靠的就是这层反解数据。当时我还踩过一个坑只给部分主机写了PTR结果日志分析平台在解析时大量超时直接拖慢了整个报表查询。从那以后我在内部配置清单里就加了这么一条凡是核心业务机全部补上PTR记录。4. 安全与稳定性DNS服务的另一半功课4.1 缓存投毒、随机端口和DNSSEC先搞懂敌方手法如果你只是把DNS当“翻译工具”觉得能解析就行那早晚要交学费。因为DNS在协议设计上其实是非常开放的用户查询哪个域名它都接而且用的是UDP无状态传输包很容易被伪造和篡改。我先说一种常见攻击——缓存投毒。攻击者伪造一个应答包冒充上游权威服务器说“xxx返回的这个IP是攻击者IP”如果目标递归服务器采信并缓存下来之后所有查询这个域名的用户都会被引导到恶意网站。这属于“你问路有人路上堵住你给你指了个坏方向”。怎么防呢现代递归服务器默认发出去的查询用的是随机源端口攻击者要伪造应答不仅要把ID号猜对还要把端口号猜对两个组合起来穷举难度会大幅提高。这是第一层防护。第二层防护是DNSSEC通过签名来验证应答真实性。它的原理相当于给每条记录盖了一个数字章解析器拿到记录先验章验不过就丢弃。虽然DNSSEC的部署需要域名的权威端先做签名过程有额外成本但只要是面向公网且体感明显的域名我都建议开启。内部私网域签名部署反而简单因为主机数量完全可控。需要特别提醒的是不要把自己内网的递归服务直接暴露到公网上。网上开放递归解析器经常被人利用做放大攻击别人拿你服务器的资源去打别人的目标。结果就是你的带宽被耗尽、IP被封、内部用户莫名断网。这个坑我见过太多人踩过解决办法也很简单监听地址只绑内网IP防火墙只放行来自可信网段的53端口访问。4.2 稳定运行的正确姿势上游多选、超时策略和流量限速内部DNS域名解析服务要稳定首先不是求“更快”而是求“别挂”。我在实际运维里总结了几条原则。上游一定要多配合。只配一个上游地址是一个巨大的单点。那台公共DNS硬件出故障或者网络路由抖动你的用户就会出现大面积解析失败。我的习惯是至少配两个不同运营商或不同网络的上游并且在服务里开启故障自动切换请求出现超时后就换下一个。超时时间和重试次数要有上限。有的服务默认超时比较长如果上游一个包迟迟不回内部的客户端也跟着卡死。我一般会把上游请求超时控制在1秒到2秒之间重试次数控制在2次以内。宁可快速失败也不要让客户端无限等待。还有一个容易被忽略的是限速。某些服务面对突发的大量查询时可能直接“被搞挂”攻击者也可能在某个瞬间发起成吨的查询。我一般会给DNS服务设置一个“每秒最大查询数”的阈值超过阈值的新请求直接丢弃或返回拒绝。这样既能护住自己的资源也能让正常请求不受恶意流量挤兑。最后日志一定要开。DNS日志在平时看起来只是流水账但一旦出现解析异常、被缓存投毒、被异常请求骚扰日志就是你唯一能拿出来的断案证据。不要长期开全量日志那会丢出巨量文件建议按天轮转保留近30天即可。5. 排查黄金三件套与三条真实故障实录5.1 dig、host、nslookup怎么用输出到底怎么读排查DNS问题离不开命令行工具我个人最常用的是dig。一个典型的查询命令是这样的dig git.internal.example 192.168.50.10这个命令表示直接向192.168.50.10这台DNS服务器查询git.internal.example的A记录。加很重要它可以绕开你本机默认配置的DNS让排查目标更明确。输出里我最关注的是ANSWER SECTION那一段它列出了真正的解析结果。比如下面这样git.internal.example. 300 IN A 192.168.50.21这里300是这条记录的剩余TTLIN是网络类型A是记录类型最后是答案。如果ANSWER SECTION是空的而AUTHORITY SECTION里有SOA记录说明这个域名存在但没有对应的A记录需要检查区域文件。host命令适合快速看一眼结果nslookup则在Windows和多数系统上都能用。如果你要验证递归链路可以加trace参数dig internal.example trace它会从根开始一级一级打印让你看见每个层级到底是哪个服务器回答的。这对于判断“是权威端没生效还是递归器缓存问题”非常有效。5.2 故障一记录改了半天怎么就是不生效有一次内部服务要换IP运维改了区域文件重启了服务自己也用dig查到了新IP但办公区的电脑还是访问旧IP。我过去看的时候直接问了一句你查的时候带了吗他没带默认走的是那台DNS服务器的缓存客户端。由于旧记录TTL设得长递归器和客户端都缓存了旧的解析结果新的权威区域文件虽然已经生效但旧缓存没到期用户自然拿到旧IP。这里要再次强调改DNS记录之前先评估TTL。一个有计划的变更流程应该是这样提前把TTL从86400改成300让旧缓存在5分钟内自然过期。等待一两个TTL周期确认旧记录在各级缓存里基本消失。修改域名指向IP的记录。生效后视需要把TTL调回正常值。这个流程我在多个项目里都用了亲测能避免“为什么改了不生效”的绝大多数争吵。5.3 故障二解析请求慢得像卡死另一回遇到的情况是客户端访问内网服务超时严重偶尔能通偶尔完全打不开。我第一时间打算测一下解析耗时就用dig加time参数统计了一下dig git.internal.example 192.168.50.10 time2结果显示解析耗时超过1.5秒这在内网环境里极不正常。然后我排查到这台DNS服务器的上游请求总是在超时它需要跨网络访问上游地址那段路由抖动严重。解决方案和4.2节说的一样给这台服务多加一个在同一网络内、链路稳定的上游地址同时把服务和上游之间的连通性纳入日常监控。那之后我就学到一个经验DNS解析服务的主机最好和上游解析服务器在同一个网络区域或者至少网络链路要稳定。跨地域跨运营商的递归查询真的随时可能超时。5.4 故障三内网域名被公网“污染”了还遇到过更隐蔽的故障内部某个域名并没有在内部DNS中配置有效记录但用户竟然能解析出一个IP而且这个IP根本不属于内网。我把这事拆开看发现是这个域名在公网上有同名记录同时内部某些终端没有正确指向内部DNS绕道去了公共解析器于是拿到了公网的解析结果。这个在技术层面不叫污染但实际效果就是“内部流量被导到公网再绕回来”既慢又不安全。解决办法有两层。第一层凡是内部使用的主机DHCP分发的DNS服务器必须是指向内部解析器的禁止下发公共DNS作为首选。第二层内部域名的权威端必须包含所有内部需要的主机记录包括一些你暂时没用的名字防止它去外部查找。从那次以后我养成一个习惯内部域名坚持使用明确的内部保留域名后缀并部署双服务器。我再也没遇到过内部记录和公网同名记录互相打架的破事。6. 一些实操中的个人心得讲了这么多最后说几条我个人做DNS域名解析服务时沉淀下来的经验。第一 把TTL当成一个业务参数而不是一个技术参数来管。每个域名、每条记录都应该清楚为什么要用这个TTL。核心系统、负载均衡入口、故障演练环境它们需要的TTL完全不一样。第二 变更记录前先看日志确认旧缓存从哪来。不要只看权威端的状态缓存端的状态往往才是你实际看到的现象。如果你连缓存都看不到用dig trace至少能定位是哪一层出的答案。第三 日常就演练一遍“主从切换”。很多人配置了主从同步但从没模拟过主服务器宕机真出了事故才发现从服务器根本没同步成功或者同步密钥过期了。DNS这种基础设施平时做得越多出问题时越不慌。第四 所有内网主机尽可能把DNS指向统一内部解析器。这样既能在日志里看到全貌也能减少客户端各自访问公共解析器的行为为日后的流量审计和故障排查打基础。DNS域名解析服务做扎实之后你会有一种“整个网络尽在掌握”的感觉。前期多花一小时设计记录和缓存后期就能少熬几宿排查问题。这也是我希望这篇文章帮你解决的问题。