更新：已解决，在问题末尾回答
我可以知道我做错了什么吗？或者在过去的 3 到 4 年中，关于 dns 记录传播的做法是否发生了变化？我设置的子域的 NS 记录似乎没有传播到任何公共 DNS 服务器
我已经设置了一个新的子域，我计划将其 DNS 委托给特定的服务器。
这是通过在 whois.com 上为子域设置 NS 记录来完成的
SOA 和 NS 记录都指向 whois.com
dig @8.8.8.8 SOA mydomain.com
;; ANSWER SECTION:
mydomain.com. 7200 IN SOA ns1.whois.com. someemail.someemail.com.
dig @8.8.8.8 NS mydomain.com
;; ANSWER SECTION:
mydomain.com. 21600 IN NS ns2.whois.com.
mydomain.com. 21600 IN NS ns4.whois.com.
mydomain.com. 21600 IN NS ns3.whois.com.
mydomain.com. 21600 IN NS ns1.whois.com.
我已经为我想使用的名称服务器设置了子域记录
dig @8.8.8.8 ns.mydomain.com.
;; ANSWER SECTION:
ns.mydomain.com. 28800 IN A 88.22.66.11
为子域设置 NS 记录后，在 whois.com 服务器上，它如下所示
dig @whois.com SOA subdomain.mydomain.com #both query came back the same
dig @whois.com NS subdomain.mydomain.com
;; QUESTION SECTION:
;subdomain.mydomain.com. IN SOA
;; AUTHORITY SECTION:
subdomain.mydomain.com. 38400 IN NS ns.mydomain.com.
;; ADDITIONAL SECTION:
ns.mydomain.com. 28800 IN A 88.22.66.11
所以我认为设置已经正确了。
但是我已经等了 2 天多了，但似乎没有其他公共 DNS 服务器接收到它，我也尝试了其他服务器，例如 1.1.1.1 和 cisco 名称服务器
dig @8.8.8.8 NS subdomain.mydomain.com
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 38946
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
;; QUESTION SECTION:
;subdomain.mydomain.com. IN NS
记得我在 3 到 4 年前为另一个子域做了相同的设置，但是 ns 服务器后来退役了，我没有更改任何 DNS 记录，我尝试检查另一个域
dig @8.8.8.8 NS oldsubdomain.mydomain.com
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
;; QUESTION SECTION:
;oldsubdomain.mydomain.com. IN NS
dig @whois.com NS oldsubdomain.mydomain.com
;; QUESTION SECTION:
;oldsubdomain.mydomain.com. IN SOA
;; AUTHORITY SECTION:
oldsubdomain.mydomain.com. 38400 IN NS ns2.mydomain.com.
;; ADDITIONAL SECTION:
ns2.mydomain.com. 28800 IN A 88.22.66.112
奇怪的是，该记录似乎也从其他公共 DNS 服务器中消失了，除了 whois.com 名称服务器。
回答
结果 named 没有在实际网络接口上监听 ipv4 上的端口 53
[]# netstat -tulpn
Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name
tcp 0 0 127.0.0.1:53 0.0.0.0:* LISTEN 29722/named
tcp 0 0 127.0.0.1:953 0.0.0.0:* LISTEN 29722/named
tcp6 0 0 :::80 :::* LISTEN 29722/named
tcp6 0 0 ::1:953 :::* LISTEN 29722/named
udp 0 0 127.0.0.1:53 0.0.0.0:* 29722/named
udp 0 0 0.0.0.0:5353 0.0.0.0:* 9134/avahi-daemon:
udp6 0 0 ::1:53 :::* 29722/named
dig @127.0.0.1 subdomain.mydomain.com
;;have answer
#assume 123.123.123.123 is public IP of server
dig @123.123.123.123 subdomain.mydomain.com
;;time-out no answer
我通过将公共 IP 添加到 named.conf 来修复
listen-on port 53 { 127.0.0.1; 123.123.123.123; };
所以以前因为 ns.mydomain.com 服务器没有回答任何 dns 查询，这是主要问题。
我的困惑是我把ns记录和soa记录搞混了，我以为通过设置子域名的NS记录，SOA已经到位了，实际上需要来自NS服务器。由于 SOA 查询失败，我的 NS 服务器无法在绑定上使用 nsupdate，这在我自己的调查中导致了一些循环逻辑。
SOA 记录和 NS 记录是不同类型的记录。
来自上游的 NS 记录委托（一个）其他名称服务器来回答子域的 dns 查询。
SOA 实际上告诉了特定域的权限开始是什么。
在我的例子中，我还应该通过设置 named 的区域文件来设置 named 来回答 SOA 查询，我就是这样做的。区域文件具有 SOA 和 subdomain.mydomain.com 的 A 记录。
我错误地认为我应该使用 nsupdate 进行故障排除，因为当 nsupdate 从服务器的默认 DNS（即 8.8.8.8）中找不到 SOA 记录时会阻塞。整个事情对我来说变得很循环。
实际问题是没有服务器能够从我设置的名称服务器 ns.mydomain.com 查询 SOA。
这是通过在 ns.mydomain.com 服务器本身上运行以下 dig 和 netstat 命令发现的
在仔细检查 netstat 输出后，它显示端口 53 仅在所有 ipv6 接口和 127.0.0.1 ipv4 本地环回上被监听，而不是任何其他 ipv4 接口。
要更改此行为的配置，请修改 named.conf 中的以下行
在 public 中添加 so named 也可以正确地监听来自 ipv4 接口的请求