辅助 DNS 没有响应 dig

辅助 DNS 没有响应 dig

我们是 DNS 新手。我们正在尝试使用 Bind 和 CentOS 为现有主服务器(例如:142.250.192.110)配置辅助 DNS 服务器。

我们的辅助服务器配置如下:

    listen-on port 53 { 127.0.0.1; any; };
        listen-on-v6 port 53 { ::1; any; };
        directory       "/var/named";
        dump-file       "/var/named/data/cache_dump.db";
        statistics-file "/var/named/data/named_stats.txt";
        memstatistics-file "/var/named/data/named_mem_stats.txt";
        recursing-file  "/var/named/data/named.recursing";
        secroots-file   "/var/named/data/named.secroots";
        allow-query     { any; };

    
zone "example.com" IN {
        type slave;
        masters {  142.250.192.110; };
        file "slaves/example.forward";
};
zone "192.250.142.in-addr.arpa" IN {
        type slave;
        masters {  142.250.192.110; };
        file "slaves/example.reverse";
};

当我们执行时,dig @127.0.0.1 host1.example.com我们会得到正确的答复。当我们使用本地 IP(辅助服务器)执行时,dig @192.168.1.10 host1.example.com我们会得到正确的答复。

但是,当我们使用辅助服务器的公共 IP / 主机名执行命令时,例如:dig @dns2.example.com host1.example.com我们收到类似的错误;; connection timed out; no servers could be reached

请提出一些建议来解决这个问题。提前感谢您的宝贵时间和帮助。

一些信息和故障排除细节(IP 和主机名不是原始的):

主 DNS:142.250.192.110(dns1.example.com)

辅助 DNS:192.168.1.10(本地 IP)、142.250.192.220(dns2.example.com)

nslookup dns2.example.com

Server:     8.8.8.8
Address:    8.8.8.8#53

Non-authoritative answer:
Name:   dns2.example.com
Address: 142.250.192.220

dig @127.0.0.1 host1.example.com- 成功

dig @192.168.1.10 host1.example.com- 成功

dig @142.250.192.220 host1.example.com- 失败的。

dig @dns2.example.com host1.example.com- 失败的。

tcpdump显示数据包传输,带有dig @127.0.0.1dig @192.168.1.10。但显示无数据包传输,与dig @142.250.192.220dig @dns2.example.com

为了检查防火墙是否阻止了端口 53,我们使用 tcpdump 测试了该端口,tcpdump 显示了何时进行数据包传输telnet 142.250.192.220 53

笔记:我们有一个防火墙,可以将本地 IP 与公共 IP 进行 NAT。我们正在等待网络团队的回复,看看防火墙是否阻止了此挖掘请求。

答案1

始终检查两台服务器上的日志。验证从服务器是否能够获取区域。一个步骤是使用dig @192.168.1.10 axfr example.com从服务器手动进行传输,其中@192.168.1.10主服务器位于从服务器配置中。

allow-transfer { };主服务器上可能需要允许从服务器获取区域。同样,所有这些都在日志中。

总是先检查本地访问。使用 netstat -anp 检查服务器是否正确监听,然后再次检查日志。作为最后的手段,尝试 tcpdump 来查看哪些数据包发往何处以及是否有任何回复。

相关内容