CentOS BIND DNS 故障排除？

Question 1

一些建议：

从您的中删除两个 google 名称服务器resolv.conf。您的名称服务器出现故障，但您没有获得太多有用的信息，因为 nslookup 正在转到下一个名称服务器。

改用digif nslookup。 dig 的状态响应有助于排除故障。

dig @192.168.100.10 mac1.max.app. a
dig @192.168.100.10 max.app. ns

请务必检查您的日志以查看您的区域是否正在加载。

检查 netstat 以确保 named 正在监听相应接口的端口 53。

Answer

一些建议：

从您的中删除两个 google 名称服务器resolv.conf。您的名称服务器出现故障，但您没有获得太多有用的信息，因为 nslookup 正在转到下一个名称服务器。

改用digif nslookup。 dig 的状态响应有助于排除故障。

dig @192.168.100.10 mac1.max.app. a
dig @192.168.100.10 max.app. ns

请务必检查您的日志以查看您的区域是否正在加载。

检查 netstat 以确保 named 正在监听相应接口的端口 53。

Question 2

您的named配置为监听127.0.0.1，::1但您的主机resolve.conf说要询问，192.168.100.10请尝试将您的listen-on指令更改为

listen-on {
    127.0.0.1;
    192.168.100.10;
    };

/etc/sysconfig/iptables还要检查你的防火墙是否允许端口 53 上的连接。我的命令如下：

-A RH-Firewall-1-INPUT -p udp -m udp --dport 53 -j ACCEPT
-A RH-Firewall-1-INPUT -p tcp -m tcp --dport 53 -j ACCEPT

Answer

您的named配置为监听127.0.0.1，::1但您的主机resolve.conf说要询问，192.168.100.10请尝试将您的listen-on指令更改为

listen-on {
    127.0.0.1;
    192.168.100.10;
    };

/etc/sysconfig/iptables还要检查你的防火墙是否允许端口 53 上的连接。我的命令如下：

-A RH-Firewall-1-INPUT -p udp -m udp --dport 53 -j ACCEPT
-A RH-Firewall-1-INPUT -p tcp -m tcp --dport 53 -j ACCEPT

Question 3

即使战斗结束后很久，我对此类问题的解决方法仍然非常简单：

用于named-checkzone仔细检查区域文件的有效性
用于named-checkconf仔细检查绑定配置文件的有效性
增加其中的日志记录
dig使用+标志进行查询@以将流量精确地引导到服务器，并评估答复以及日志文件中发生的情况。

但简而言之，主要的事情不要做（因此在尝试解决问题之前就停止这样做）：

劫持任何现有或随机的名称/TLD，并假装它永远不会产生冲突；这是看待问题的错误方式
使用相同的绑定作为权威和递归

就这个特定情况而言，dig最后给出的结果完全正常，并且完全符合预期。

该请求是“mac1.max.app ns”（请注意，要求的记录类型是“ns”），针对的是应该在区域上具有权威性的名称服务器max.app。

由于该名称mac1.max.app没有NS记录，只有一条A记录，因此名称服务器必须回答：

NOERROR由于名称存在，返回代码为
部分中没有内容ANSWER，因为确实没有NS记录mac1.max.app
但由于它对具有权威性max.app，因此它在 AUTHORITATIVE部分中给出了SOA该记录所在区域的记录，而该记录确实是max.app。

使用任何给定的名称来重现同样的事情是很容易的，让我们尝试一下www.nic.app（显示使用任何任意名称的危险，如上评论所述，因为该名称.app被授予了 Google，因此现在是一个完全有效和公开的 TLD），它当然应该有A记录，而其他的则没有NS记录（如果名称有CNAME记录，情况就会有所不同）

权威名称服务器nic.app：

$ dig NS nic.app +short
ns2.google.com.
ns4.google.com.
ns3.google.com.
ns1.google.com.

向他们中的任何一个人询问我们的问题：

$ dig NS www.nic.app @ns3.google.com.

; <<>> DiG 9.18.4 <<>> NS www.nic.app @ns3.google.com.
;; global options: +cmd
;; Sending:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 355
;; flags: rd ad; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
; COOKIE: 198fd01a7c794358
;; QUESTION SECTION:
;www.nic.app.       IN NS

;; QUERY SIZE: 52

;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 355
;; flags: qr aa rd; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1
;; WARNING: recursion requested but not available

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;www.nic.app.       IN NS

;; AUTHORITY SECTION:
nic.app.        1m IN SOA ns1.google.com. dns-admin.google.com. (
                463794447  ; serial
                900        ; refresh (15 minutes)
                900        ; retry (15 minutes)
                1800       ; expire (30 minutes)
                60         ; minimum (1 minute)
                )

;; Query time: 54 msec
;; SERVER: 216.239.36.10#53(ns3.google.com.) (UDP)
;; WHEN: Fri Jul 29 17:32:06 EST 2022
;; MSG SIZE  rcvd: 100

正如预期的那样，根据 DNS 协议的设计：

NOERROR返回代码，因为名称存在，但不存在该类型
因此该部分中没有内容ANSWER，因为没有NS该名称的记录
但SOA记录AUTHORITY部分显示我们查询的记录所在的区域的“开始”（最高级别/最接近根）

因此，这个问题实际上没有什么需要解决的，即使没有达到预期，事情也按设计进行，但要回答这个问题，需要更多关于预期的细节。或者只是尝试查询记录类型，A而不是NS单个记录类型。

Answer