我已经设置 bind9 将 dns 查询转发到通过 192.168.1/24 网络本地连接的机器。
我将查询转发到的 IP 也是我的互联网网关。有时其中一个网关会丢失其互联网连接。出于某种原因，bind 不会将查询转发到第二个 dns 服务器。
这是我的 named.options.conf
options {
directory "/var/cache/bind";
forwarders {
192.168.7.17;192.168.7.16;
};
recursion yes;
allow-recursion {any;};
auth-nxdomain no; # conform to RFC1035
listen-on-v6 { any; };
listen-on port 53 {any;};
allow-query {any;};
dnssec-validation no;
# Expire negative answer ASAP.
# i.e. Do not cache DNS query failure.
max-ncache-ttl 3; # 3 seconds
# Disable non-relevant operations
allow-transfer { none; };
allow-update-forwarding { none; };
allow-notify { none; };
};
以下是我机器上 port53 上所有内容的 tcpdump（在 cli 中只需“tcpdump -A”）。它显示，当我从 192.168.7.16 移除 WAN 电缆时，dns 查询仅发送到 192.168.7.16，而不是 192.168.7.17：
16:26:29.238717 IP 192.168.7.1.34503 > 192.168.7.16.domain: 57293+% [1au] A? hostname.com. (41)
E..E....@.<Y...........5.1[..............hostname.com.......)........
16:26:29.240172 IP 192.168.7.16.domain > 192.168.7.1.34503: 57293 0/0/0 (41)
E..E..@[email protected].......)........
以下是使用“nrtpd trace 9”对“hostname.com”的失败查询检索到的命名跟踪。如果能提供任何建议，说明如何在这种情况下强制查询转移到辅助服务器，我们将不胜感激！
04-Dec-2014 16:23:25.417 client 127.0.0.1#36476: UDP request
04-Dec-2014 16:23:25.417 client 127.0.0.1#36476: using view '_default'
04-Dec-2014 16:23:25.417 client 127.0.0.1#36476: request is not signed
04-Dec-2014 16:23:25.417 client 127.0.0.1#36476: recursion available
04-Dec-2014 16:23:25.417 client 127.0.0.1#36476: query
04-Dec-2014 16:23:25.417 client 127.0.0.1#36476: query (cache) '107.103.225.122.in-addr.arpa/PTR/IN' approved
04-Dec-2014 16:23:25.417 client 127.0.0.1#36476: replace
04-Dec-2014 16:23:25.417 clientmgr @0xb75871e0: createclients
04-Dec-2014 16:23:25.417 clientmgr @0xb75871e0: recycle
04-Dec-2014 16:23:25.417 client @0xb4bee008: udprecv
04-Dec-2014 16:23:25.417 createfetch: 107.103.225.122.in-addr.arpa PTR
04-Dec-2014 16:23:25.417 fctx 0xb4df6008(107.103.225.122.in-addr.arpa/PTR'): create
04-Dec-2014 16:23:25.417 fctx 0xb4df6008(107.103.225.122.in-addr.arpa/PTR'): join
04-Dec-2014 16:23:25.417 fetch 0xb7568150 (fctx 0xb4df6008(107.103.225.122.in-addr.arpa/PTR)): created
04-Dec-2014 16:23:25.417 fctx 0xb4df6008(107.103.225.122.in-addr.arpa/PTR'): start
04-Dec-2014 16:23:25.417 fctx 0xb4df6008(107.103.225.122.in-addr.arpa/PTR'): try
04-Dec-2014 16:23:25.417 fctx 0xb4df6008(107.103.225.122.in-addr.arpa/PTR'): cancelqueries
04-Dec-2014 16:23:25.418 fctx 0xb4df6008(107.103.225.122.in-addr.arpa/PTR'): getaddresses
04-Dec-2014 16:23:25.418 fctx 0xb4df6008(107.103.225.122.in-addr.arpa/PTR'): query
04-Dec-2014 16:23:25.418 resquery 0xb4dfc008 (fctx 0xb4df6008(107.103.225.122.in-addr.arpa/PTR)): send
04-Dec-2014 16:23:25.418 resquery 0xb4dfc008 (fctx 0xb4df6008(107.103.225.122.in-addr.arpa/PTR)): sent
04-Dec-2014 16:23:25.418 resquery 0xb4dfc008 (fctx 0xb4df6008(107.103.225.122.in-addr.arpa/PTR)): udpconnected
04-Dec-2014 16:23:25.418 resquery 0xb4dfc008 (fctx 0xb4df6008(107.103.225.122.in-addr.arpa/PTR)): senddone
04-Dec-2014 16:23:25.420 resquery 0xb4dfc008 (fctx 0xb4df6008(107.103.225.122.in-addr.arpa/PTR)): response
04-Dec-2014 16:23:25.420 message has 11 byte(s) of trailing garbage
04-Dec-2014 16:23:25.420 fctx 0xb4df6008(107.103.225.122.in-addr.arpa/PTR'): noanswer_response
04-Dec-2014 16:23:25.420 fctx 0xb4df6008(107.103.225.122.in-addr.arpa/PTR'): ncache_message
04-Dec-2014 16:23:25.420 fctx 0xb4df6008(107.103.225.122.in-addr.arpa/PTR'): clone_results
04-Dec-2014 16:23:25.420 fctx 0xb4df6008(107.103.225.122.in-addr.arpa/PTR'): cancelquery
04-Dec-2014 16:23:25.420 fctx 0xb4df6008(107.103.225.122.in-addr.arpa/PTR'): done
04-Dec-2014 16:23:25.420 fctx 0xb4df6008(107.103.225.122.in-addr.arpa/PTR'): stopeverything
04-Dec-2014 16:23:25.420 fctx 0xb4df6008(107.103.225.122.in-addr.arpa/PTR'): cancelqueries
04-Dec-2014 16:23:25.420 dns_adb_destroyfind on find 0xb4f7fcc8
04-Dec-2014 16:23:25.420 dns_adb_destroyfind on find 0xb4f84008
04-Dec-2014 16:23:25.420 dns_adb_destroyfind on find 0xb4f7f2b0
04-Dec-2014 16:23:25.420 dns_adb_destroyfind on find 0xb4f7fdd8
04-Dec-2014 16:23:25.420 dns_adb_destroyfind on find 0xb4f7f008
04-Dec-2014 16:23:25.420 dns_adb_destroyfind on find 0xb4f84090
04-Dec-2014 16:23:25.420 dns_adb_destroyfind on find 0xb4f7fee8
04-Dec-2014 16:23:25.420 dns_adb_destroyfind on find 0xb4f7f448
04-Dec-2014 16:23:25.420 dns_adb_destroyfind on find 0xb4f7f1a0
04-Dec-2014 16:23:25.420 dns_adb_destroyfind on find 0xb4f7fbb8
04-Dec-2014 16:23:25.420 dns_adb_destroyfind on find 0xb4f7f4d0
04-Dec-2014 16:23:25.420 dns_adb_destroyfind on find 0xb4f7f338
04-Dec-2014 16:23:25.420 dns_adb_destroyfind on find 0xb4f7f118
04-Dec-2014 16:23:25.421 fctx 0xb4df6008(107.103.225.122.in-addr.arpa/PTR'): sendevents
04-Dec-2014 16:23:25.421 client 127.0.0.1#36476: send
04-Dec-2014 16:23:25.421 client 127.0.0.1#36476: sendto
04-Dec-2014 16:23:25.421 client 127.0.0.1#36476: senddone
04-Dec-2014 16:23:25.421 client 127.0.0.1#36476: next
04-Dec-2014 16:23:25.421 client 127.0.0.1#36476: endrequest
04-Dec-2014 16:23:25.421 fetch completed at resolver.c:6859 for 107.103.225.122.in-addr.arpa/PTR in 0.003287: success/success [domain:.,referral:0,restart:1,qrysent:1,timeout:0,lame:0,neterr:0,badresp:0,adberr:0,findfail:0,valfail:0]
04-Dec-2014 16:23:25.421 fetch 0xb7568150 (fctx 0xb4df6008(107.103.225.122.in-addr.arpa/PTR)): destroyfetch
04-Dec-2014 16:23:25.421 fctx 0xb4df6008(107.103.225.122.in-addr.arpa/PTR'): shutdown
04-Dec-2014 16:23:25.421 fctx 0xb4df6008(107.103.225.122.in-addr.arpa/PTR'): doshutdown
04-Dec-2014 16:23:25.421 fctx 0xb4df6008(107.103.225.122.in-addr.arpa/PTR'): stopeverything
04-Dec-2014 16:23:25.421 fctx 0xb4df6008(107.103.225.122.in-addr.arpa/PTR'): cancelqueries
04-Dec-2014 16:23:25.421 fctx 0xb4df6008(107.103.225.122.in-addr.arpa/PTR'): destroy
04-Dec-2014 16:23:25.534 client 127.0.0.1#58196: UDP request
04-Dec-2014 16:23:25.535 client 127.0.0.1#58196: using view '_default'
04-Dec-2014 16:23:25.535 client 127.0.0.1#58196: request is not signed
04-Dec-2014 16:23:25.535 client 127.0.0.1#58196: recursion available
04-Dec-2014 16:23:25.535 client 127.0.0.1#58196: query
04-Dec-2014 16:23:25.535 client 127.0.0.1#58196: query (cache) 'hostname.com/A/IN' approved
04-Dec-2014 16:23:25.535 client 127.0.0.1#58196: replace
04-Dec-2014 16:23:25.535 clientmgr @0xb75871e0: createclients
04-Dec-2014 16:23:25.535 clientmgr @0xb75871e0: recycle
04-Dec-2014 16:23:25.535 client @0xb544f008: udprecv
04-Dec-2014 16:23:25.535 createfetch: hostname.com A
04-Dec-2014 16:23:25.535 fctx 0xb49e5008(hostname.com/A'): create
04-Dec-2014 16:23:25.536 fctx 0xb49e5008(hostname.com/A'): join
04-Dec-2014 16:23:25.536 fetch 0xb7568150 (fctx 0xb49e5008(hostname.com/A)): created
04-Dec-2014 16:23:25.536 fctx 0xb49e5008(hostname.com/A'): start
04-Dec-2014 16:23:25.536 fctx 0xb49e5008(hostname.com/A'): try
04-Dec-2014 16:23:25.536 fctx 0xb49e5008(hostname.com/A'): cancelqueries
04-Dec-2014 16:23:25.536 fctx 0xb49e5008(hostname.com/A'): getaddresses
04-Dec-2014 16:23:25.536 fctx 0xb49e5008(hostname.com/A'): query
04-Dec-2014 16:23:25.536 resquery 0xb49eb008 (fctx 0xb49e5008(hostname.com/A)): send
04-Dec-2014 16:23:25.537 resquery 0xb49eb008 (fctx 0xb49e5008(hostname.com/A)): sent
04-Dec-2014 16:23:25.537 resquery 0xb49eb008 (fctx 0xb49e5008(hostname.com/A)): udpconnected
04-Dec-2014 16:23:25.537 resquery 0xb49eb008 (fctx 0xb49e5008(hostname.com/A)): senddone
04-Dec-2014 16:23:25.538 resquery 0xb49eb008 (fctx 0xb49e5008(hostname.com/A)): response
04-Dec-2014 16:23:25.538 message has 11 byte(s) of trailing garbage
04-Dec-2014 16:23:25.538 fctx 0xb49e5008(hostname.com/A'): noanswer_response
04-Dec-2014 16:23:25.538 fctx 0xb49e5008(hostname.com/A'): ncache_message
04-Dec-2014 16:23:25.538 fctx 0xb49e5008(hostname.com/A'): clone_results
04-Dec-2014 16:23:25.538 fctx 0xb49e5008(hostname.com/A'): cancelquery
04-Dec-2014 16:23:25.538 fctx 0xb49e5008(hostname.com/A'): done
04-Dec-2014 16:23:25.539 fctx 0xb49e5008(hostname.com/A'): stopeverything
04-Dec-2014 16:23:25.539 fctx 0xb49e5008(hostname.com/A'): cancelqueries
04-Dec-2014 16:23:25.539 dns_adb_destroyfind on find 0xb4f7f338
04-Dec-2014 16:23:25.539 dns_adb_destroyfind on find 0xb4f84090
04-Dec-2014 16:23:25.539 dns_adb_destroyfind on find 0xb4f7f008
04-Dec-2014 16:23:25.539 dns_adb_destroyfind on find 0xb4f7f4d0
04-Dec-2014 16:23:25.539 dns_adb_destroyfind on find 0xb4f7fee8
04-Dec-2014 16:23:25.539 dns_adb_destroyfind on find 0xb4f7f2b0
04-Dec-2014 16:23:25.539 dns_adb_destroyfind on find 0xb4f7f118
04-Dec-2014 16:23:25.539 dns_adb_destroyfind on find 0xb4f7fdd8
04-Dec-2014 16:23:25.539 dns_adb_destroyfind on find 0xb4f7f1a0
04-Dec-2014 16:23:25.539 dns_adb_destroyfind on find 0xb4f7f448
04-Dec-2014 16:23:25.539 dns_adb_destroyfind on find 0xb4f7fbb8
04-Dec-2014 16:23:25.539 dns_adb_destroyfind on find 0xb4f84008
04-Dec-2014 16:23:25.539 dns_adb_destroyfind on find 0xb4f7fcc8
04-Dec-2014 16:23:25.539 fctx 0xb49e5008(hostname.com/A'): sendevents
04-Dec-2014 16:23:25.539 client 127.0.0.1#58196: send
04-Dec-2014 16:23:25.539 client 127.0.0.1#58196: sendto
04-Dec-2014 16:23:25.539 client 127.0.0.1#58196: senddone
04-Dec-2014 16:23:25.539 client 127.0.0.1#58196: next
04-Dec-2014 16:23:25.539 client 127.0.0.1#58196: endrequest
04-Dec-2014 16:23:25.540 fetch completed at resolver.c:6859 for hostname.com/A in 0.003534: success/success [domain:.,referral:0,restart:1,qrysent:1,timeout:0,lame:0,neterr:0,badresp:0,adberr:0,findfail:0,valfail:0]
04-Dec-2014 16:23:25.540 fetch 0xb7568150 (fctx 0xb49e5008(hostname.com/A)): destroyfetch
04-Dec-2014 16:23:25.540 fctx 0xb49e5008(hostname.com/A'): shutdown
04-Dec-2014 16:23:25.540 fctx 0xb49e5008(hostname.com/A'): doshutdown
04-Dec-2014 16:23:25.540 fctx 0xb49e5008(hostname.com/A'): stopeverything
04-Dec-2014 16:23:25.540 fctx 0xb49e5008(hostname.com/A'): cancelqueries
04-Dec-2014 16:23:25.540 fctx 0xb49e5008(hostname.com/A'): destroy
答案1
如果 DNS 服务器响应，通常bind就很好了。NXDOMAIN 就是 NXDOMAIN，这就是绑定要使用的答案。我没有在日志中看到确切的响应bind是什么，但从症状来看，情况似乎就是这样。
您可能希望在网关上设置一个脚本操作，以便在网关失去 WAN 连接时关闭其 DNS 服务。这样，bind当它查询该服务器时就不会认为一切都很顺利。
答案2
Hyppy 是正确的，您的数据包捕获显示远程服务器已做出响应。无论该响应是NXDOMAIN还是SERVFAIL，BIND 都无需继续。只有在通信完全失败的情况下才会尝试重试。
老实说，如果您担心某个上游连接会中断，我建议您完全删除转发器语句，让 BIND 自行执行递归。只要允许该服务器和互联网之间双向使用端口 53，BIND 就会完全接受该配置。