按照named.options.conf下的“forwarders”的指定,不要转发到secondary DNS服务器

我有bind9安装程序将dns查询转发到通过192.168.1 / 24networking连接本地机器。

我转发查询的IP也是我的互联网网关。 有时,其中一个网关将失去其互联网连接。 绑定将由于某种原因不转发查询到第二个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. # ie 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; }; }; 

这里是我的机器上的端口53上的所有内容的tcpdump(简单地说就是“cli”中的“tcpdump -A”)。 它显示,当我从192.168.7.16删除广域网电缆的情况下,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].......)........ 

这是在“hostname.com”失败的查询中使用“nrtpd trace 9”检索到的命名跟踪。 任何build议如何强制查询转移到辅助服务器在这种情况下,将不胜感激!

 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 

如果DNS服务器响应,那么bind通常是开心的。 NXDOMAIN是NXDOMAIN,这是一个答案绑定是内容使用。 我没有在日志中看到究竟是什么反应bind回来,但从症状似乎是这样的情况。

如果失去WAN连接,您可能需要在网关上设置脚本操作来closures其DNS服务。 这样, bind在查询服务器时就不会认为所有的东西都是疯狂的。

Hyppy是正确的,你的数据包捕获显示远程服务器响应。 无论是NXDOMAIN还是SERVFAIL ,BIND都不需要继续。 只有在全部通讯失败的情况下才会尝试重试。

老实说,如果你担心你的一个上游连接丢在你身上,我只是完全删除转发语句,让BIND执行自己的recursion。 只要端口53双向被允许在该服务器和互联网之间,BIND将会完全满意那个configuration。