内部DNS服务器配置后无法解析主机名？解决方案

凌晨三点，办公室只剩下显示器的冷光。我盯着终端里那行刺眼的报错，手里攥着已经凉透的咖啡——ping: unknown host node1.chain.internal。这已经是这周第三次了。

我们正在为一家交易所做节点监控系统的部署。内部DNS服务器是上周刚配好的，BIND 9跑在172.16.10.53上，正反解析区文件都写了，named-checkzone也过了。可每当Kubernetes集群里的Pod尝试通过主机名访问区块链节点时，解析就像撞上了一堵看不见的墙。

运维群里，负责链上数据同步的老王发来消息：“ETH全节点又掉线了，监控面板一片红。”我揉了揉太阳穴，心想：这DNS问题要是再搞不定，明天老板该找我聊“职业规划”了。

那台“看不见”的DNS服务器

事情要从一周前说起。公司新上了一套内部链上数据监控系统，需要实时抓取BTC、ETH、SOL等十几个节点的状态。为了不让节点IP硬编码在配置里，我们决定搭建内部DNS，域名后缀用.chain.internal——毕竟这年头，连DAO的提案投票都要讲究个“去中心化身份”，主机名当然也得有点区块链味道。

配置过程看似顺利。我在/etc/named.conf里加了正向区chain.internal和反向区10.16.172.in-addr.arpa，区文件里写满了A记录和PTR记录。systemctl restart named之后，用dig @localhost node1.chain.internal测试，返回了漂亮的172.16.10.11。

“成了。”我当时还发了条朋友圈，配图是终端里绿色的NOERROR。

可现实很快打了脸。当我把DNS服务器IP写进Kubernetes的dnsConfig，Pod里的/etc/resolv.conf也确认指向了172.16.10.53，但nslookup node1.chain.internal就是超时。更诡异的是，直接dig @172.16.10.53 node1.chain.internal在Pod里能通，但系统解析器（也就是getaddrinfo）却不行。

这就像你明明有交易所的API密钥，但每次下单都提示“签名错误”——问题不在密钥本身，而在调用链的某个隐秘角落。

当DNS遇上区块链节点：那些“非典型”故障

第一个坑：防火墙只开了UDP 53

我第一反应是防火墙。iptables -L -n一看，果然，只放行了UDP 53。但现代DNS解析在响应超过512字节时会自动切换到TCP 53——尤其是当区文件里塞满了各种区块链节点的SRV记录和TXT记录（我们甚至给每个节点加了_metrics._tcp的SRV记录，方便Prometheus发现）。

更关键的是，Kubernetes的CoreDNS在转发查询时，默认会使用TCP作为fallback。当UDP响应被截断（TC标志置位），它会重试TCP。而我们的防火墙把TCP 53拒了，导致解析在“几乎成功”的边缘反复横跳。

解决方案：放行TCP 53。一行命令的事，但排查花了半小时。

bash iptables -I INPUT -p tcp --dport 53 -j ACCEPT

第二个坑：/etc/nsswitch.conf里的“隐藏顺序”

防火墙修好后，Pod里nslookup通了，但ping node1.chain.internal依然报unknown host。这就奇怪了——nslookup直接用DNS协议，而ping走的是系统解析器（glibc的NSS）。

我钻进Pod里看/etc/nsswitch.conf：

hosts: files dns

看起来没问题。但等等——files在前，意味着先查/etc/hosts。而我们的/etc/hosts里有一行：

127.0.0.1 localhost 172.16.10.11 node1.chain.internal # 这是之前手动加的，忘了删

问题来了：这个IP是旧的！节点早就迁移到172.16.10.21了。但/etc/hosts优先级高于DNS，所以系统解析器永远返回那个过期的IP。而nslookup直接查DNS，所以返回了新IP。

这就像你钱包里同时有旧合约地址和新合约地址，但DApp默认读了旧的——资产明明在链上，你却以为丢了。

解决方案：清理/etc/hosts里的手动映射，或者调整nsswitch.conf为hosts: dns files。但后者有风险——如果DNS挂了，连localhost都解析不了。所以最佳实践是：保持files dns，但确保/etc/hosts里只有真正静态的映射。

第三个坑：resolv.conf里的search域和ndots

清理完/etc/hosts，ping终于通了。但新的问题来了：Kubernetes Pod里解析node1.chain.internal时，有时会变成node1.chain.internal.cluster.local——这是CoreDNS的search域在作祟。

默认情况下，Pod的/etc/resolv.conf长这样：

nameserver 172.16.10.53 search default.svc.cluster.local svc.cluster.local cluster.local options ndots:5

ndots:5意味着：如果查询的域名里“点”的数量少于5个，解析器会先尝试拼接search域。node1.chain.internal有3个点（node1、chain、internal），少于5，所以会先查node1.chain.internal.default.svc.cluster.local——当然不存在，然后才查原始域名。

这会导致每次解析都多出几次无效查询，延迟增加。更糟的是，如果CoreDNS的search域里恰好有个同名服务，就会解析到错误IP。

解决方案：在Pod的dnsConfig里设置ndots: 1，或者用FQDN（完全限定域名）——也就是在主机名末尾加个点：node1.chain.internal.。那个尾点告诉解析器：“别拼search域了，这就是完整域名。”

yaml dnsConfig: nameservers: - 172.16.10.53 options: - name: ndots value: "1"

第四个坑：BIND的allow-query和listen-on

Pod里搞定了，但物理机上的监控脚本还是解析失败。我登上那台跑Zabbix的机器，dig @172.16.10.53 node1.chain.internal直接超时。

检查BIND配置：

options { listen-on port 53 { 127.0.0.1; }; allow-query { localhost; }; };

好家伙，只监听了本地回环，只允许本地查询。那为什么Pod里能通？因为Pod的DNS查询走的是CoreDNS，而CoreDNS的转发目标写的是172.16.10.53——但CoreDNS自己跑在另一个节点上，它的查询源IP是Pod的IP，不在localhost范围内。等等，那Pod里怎么通的？

哦，因为CoreDNS的forward插件默认会使用TCP，而BIND的allow-query对TCP和UDP是分开的？不，其实是因为我在调试过程中改过配置，但忘了rndc reload。BIND有时候会缓存旧配置，尤其是当named进程没重启时。

解决方案：修改named.conf：

options { listen-on port 53 { any; }; allow-query { any; }; allow-transfer { none; }; recursion yes; };

然后rndc reload。但注意：allow-query any在生产环境有风险，最好限制为内网网段，比如172.16.0.0/16。

第五个坑：DNSSEC和区块链域名的“信任危机”

最后一个坑最隐蔽。某天，解析突然又挂了，但这次dig返回SERVFAIL。查日志：

error: validation failure: no valid signature found

原来，我们为了“安全”，在BIND里开了DNSSEC验证。但.chain.internal是我们自己编的域名，根本没有权威的DNSSEC链。BIND试图验证签名，当然失败，于是返回SERVFAIL。

这就像你试图用比特币的UTXO模型去验证以太坊的账户余额——模型不匹配，结果只能是“验证失败”。

解决方案：对于内部域名，要么关闭DNSSEC验证（dnssec-validation no;），要么自己签一个信任锚（trust anchor）。但后者太复杂，内部域名通常不需要。直接关掉：

options { dnssec-validation no; };

当一切就绪：从“未知主机”到“链上同步”

修完这五个坑，已经是凌晨五点。我重新跑了一遍监控脚本：

bash for node in node1 node2 node3; do ping -c 1 $node.chain.internal && echo "$node OK" done

终端里跳出三行OK。老王在群里发了个“稳了”的表情包。监控面板上，ETH节点的区块高度开始正常增长，BTC的mempool数据也源源不断。

我靠在椅背上，想起刚入行时前辈说的话：“DNS是互联网的基石，但它也是最容易被忽视的‘暗礁’。”尤其是在区块链的世界里，节点发现、P2P连接、甚至智能合约的Oracle调用，都依赖域名解析。一个配置失误，可能让整个链上监控系统“失联”。

而这次排查让我明白：DNS问题从来不是单一的。它像一条链，每一环——防火墙、NSS、resolv.conf、BIND配置、DNSSEC——都必须严丝合缝。任何一个环节的“小毛病”，都会在系统层面放大成“无法解析主机名”的致命故障。

现在，每当我看到unknown host，都会先问自己五个问题：UDP和TCP都通吗？/etc/hosts干净吗？ndots设对了吗？BIND监听范围够吗？DNSSEC是不是在“过度验证”？

这五个问题，就像区块链的五个确认——少一个，交易就不算最终敲定。而DNS解析，本质上也是一场“共识”：客户端、解析器、权威服务器，三方达成一致，主机名才能变成IP。

凌晨的办公室依然安静，但终端里跳动的区块高度，让我觉得这夜熬得值。毕竟，在这个虚拟币的世界里，时间就是区块，而DNS，就是那条连接区块的“隐形的链”。