Re: Bind 9.11 serving up false answers for a single domain.
Run ‘dig +trace +all internet-dns1.state.ma.us’ which will show you the glue records then try ‘dig +dnssec +norec internet-dns1.state.ma.us @’ for all the addresses in the glue records. e.g. dig +dnssec +norec internet-dns1.state.ma.us @146.243.122.17 Mark > On 10 Feb 2021, at 14:50, sami's strat wrote: > > Thanks Mark. > > However, the traceroute to the hostnamed failed for the same reason. Please > note: > > [root@myhost data]# dig internet-dns1.state.ma.us > > ; <<>> DiG 9.11.4-P2-RedHat-9.11.4-9.P2.el7 <<>> internet-dns1.state.ma.us > ;; global options: +cmd > ;; Got answer: > ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 61641 > ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1 > > ;; OPT PSEUDOSECTION: > ; EDNS: version: 0, flags:; udp: 4096 > ;; QUESTION SECTION: > ;internet-dns1.state.ma.us. IN A > > ;; Query time: 1263 msec > ;; SERVER: 192.168.33.12#53(192.168.33.12) > ;; WHEN: Tue Feb 09 22:34:15 EST 2021 > ;; MSG SIZE rcvd: 54 > > [root@myhost data]# dig internet-dns1.state.ma.us +trace > > ; <<>> DiG 9.11.4-P2-RedHat-9.11.4-9.P2.el7 <<>> internet-dns1.state.ma.us > +trace > ;; global options: +cmd > . 516485 IN NS c.root-servers.net. > . 516485 IN NS e.root-servers.net. > . 516485 IN NS f.root-servers.net. > . 516485 IN NS l.root-servers.net. > . 516485 IN NS m.root-servers.net. > . 516485 IN NS d.root-servers.net. > . 516485 IN NS g.root-servers.net. > . 516485 IN NS k.root-servers.net. > . 516485 IN NS b.root-servers.net. > . 516485 IN NS h.root-servers.net. > . 516485 IN NS a.root-servers.net. > . 516485 IN NS i.root-servers.net. > . 516485 IN NS j.root-servers.net. > . 516485 IN RRSIG NS 8 0 518400 202103 > 2021020922 42351 . > QCzDH8eHlHVbx4SxIIwk8xnk6ky/q+zRh8KAUfI98lqHcIP4NLxzCe6f > mC2sNX1VcthEy6Lwnobm8OyJCRpNEHedYrS01aMhAVzUfM+/PJ9MWn0w > SkmXxyZMJZXF/kl4GDNX0x/GW3+DkeTeZI9+B540Yvj47qJv2bD9nIQG > NtE7bDze7bgMJkIuBlEzPfwp7YW5ud8qdC6HdUoEMqygwZcWAiQu8gpb > q21z8W5hcdci1OouDFytNWrXAvfSsuR635+GzSj+RZjYo+447uP7lKsK > N5aeVQ/BPh5jM32xVO+zwyp7v9Nky1vSP/BchMQ/3cqg3Ee7zobl8OQd CSd/SA== > ;; Received 1097 bytes from 192.168.33.12#53(192.168.33.12) in 0 ms > > us. 172800 IN NS a.cctld.us. > us. 172800 IN NS b.cctld.us. > us. 172800 IN NS c.cctld.us. > us. 172800 IN NS e.cctld.us. > us. 172800 IN NS f.cctld.us. > us. 172800 IN NS k.cctld.us. > us. 86400 IN DS 21364 8 1 > 260D0461242BCF8F05473A08B05ED01E6FA59B9C > us. 86400 IN DS 21364 8 2 > B499CFA7B54D25FDE1E6FE93076FB013DAA664DA1F26585324740A1E 6EBDAB26 > us. 86400 IN RRSIG DS 8 1 86400 202103 > 2021020922 42351 . > rujvGB0s2bsqzBuzRliH6QK9vH84ETZV7gZMEhJyzMFofWhj9ZZaNWE/ > VvdA9rC16IOEocvARv2rOqk7G3KTzdkHHZcwcZSQyVqsOIaIywGFuEgd > viSXF6+M5MocUgEMp5dtt6SBLHG+lE/FV/3HylKSHsxdO/F6PeWKgcBZ > D4lZQ6w5asmlbdKJKMhlWPp6UaxBE7ACaxndBQixoNqXQuPrXpXi1Fnj > ntFtTfn57hMyrdTojIJ8X7/HKjCrbm3CL/WJ+VZR051OGCdZVjpUaDXR > x7G9lDhu3K5clar9PGYyUJM7+RBKzrQJep7HrjL2nZdoTyfY4i33S+EZ sTlTOA== > ;; Received 707 bytes from 199.7.91.13#53(d.root-servers.net) in 4 ms > > state.ma.us.7200IN NS internet-dns3.state.ma.us. > state.ma.us.7200IN NS internet-dns1.state.ma.us. > state.ma.us.7200IN NS internet-dns2.state.ma.us. > state.ma.us.3600IN DS 47628 7 2 > 5379F9F747214E5A63416775396BCFF98FA4867AE66E09BCBEBE0DCC 1682C369 > state.ma.us.3600IN DS 41388 7 1 > 36D899932AF794EADD671161515E48FE829BB7FE > state.ma.us.3600IN DS 41388 7 2 > BBAB433D3853571F42516E70659AF1F85FA4FBA0FDFCEAD4D092592A 00C78769 > state.ma.us.3600IN DS 47628 7 1 > 485E0EE2F7C08FCE51D1E284321242930274833A > state.ma.us.3600IN RRSIG DS 8 3 3600 20210307200856 > 20210205191212 53985 us. > O8KqBHzlZsDqrZi0NQO4JEiN0b8j04/Lb8W2uVz5PyrAat1VgZKQ3Ws6 > 6PNtbZDMv6YX6QA8fWFLxNmeJ1/4L3wLu8EKYXaThA9Zxll7mKFj1iPf > nqiVq5hOo8Ul3inmfM/tjCQ21IHc/v0JZygZNd/h0SxXWlQXi+W3G9LN > +4z/qxtl9dGD1ka54Ln3MAVxB1Tp4pt0ri4qPLmfGKf/HA== > couldn't get address for 'internet-dns3.state.ma.us': not found > couldn't get address for 'internet-dns1.state.ma.us': not found > couldn't get address for
Re: Bind 9.11 serving up false answers for a single domain.
Do you know about mxtoolbox.com? It (and other similar sites) does a good job of diagnosing DNS-related problems. I use it now and then to check out my own sites, as it gives a "second opinion". In particular its "DNS Lookup' function reported the following for "internet-dns1.state.ma.us" Type Domain Name IP Address TTL A internet-dns1.state.ma.us 170.63.70.3615 min ... Reported by internet-dns3.state.ma.us on 2/9/2021 at 10:44:08 PM (UTC -6), just for you. But its "DNS Check" function them reported dns:internet-dns1.state.ma.us No Results Found ... Reported by internet-dns2.state.ma.us on 2/9/2021 at 10:51:04 PM (UTC -6) and later ... Reported by internet-dns3.state.ma.us on 2/9/2021 at 10:54:13 PM (UTC -6) Strange indeed: sounds like they have problems. On Tue, 9 Feb 2021 22:50:19 -0500 "sami's strat" wrote: > Thanks Mark. > > However, the traceroute to the hostnamed failed for the same reason. > Please note: > > [root@myhost data]# dig internet-dns1.state.ma.us > > > > ; <<>> DiG 9.11.4-P2-RedHat-9.11.4-9.P2.el7 <<>> internet-dns1.state.ma.us > > ;; global options: +cmd > > ;; Got answer: > > ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 61641 > > ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1 > > > > ;; OPT PSEUDOSECTION: > > ; EDNS: version: 0, flags:; udp: 4096 > > ;; QUESTION SECTION: > > ;internet-dns1.state.ma.us. IN A > > > > ;; Query time: 1263 msec > > ;; SERVER: 192.168.33.12#53(192.168.33.12) > > ;; WHEN: Tue Feb 09 22:34:15 EST 2021 > > ;; MSG SIZE rcvd: 54 > > > > [root@myhost data]# dig internet-dns1.state.ma.us +trace > > > > ; <<>> DiG 9.11.4-P2-RedHat-9.11.4-9.P2.el7 <<>> internet-dns1.state.ma.us > +trace > > ;; global options: +cmd > > . 516485 IN NS c.root-servers.net. > > . 516485 IN NS e.root-servers.net. > > . 516485 IN NS f.root-servers.net. > > . 516485 IN NS l.root-servers.net. > > . 516485 IN NS m.root-servers.net. > > . 516485 IN NS d.root-servers.net. > > . 516485 IN NS g.root-servers.net. > > . 516485 IN NS k.root-servers.net. > > . 516485 IN NS b.root-servers.net. > > . 516485 IN NS h.root-servers.net. > > . 516485 IN NS a.root-servers.net. > > . 516485 IN NS i.root-servers.net. > > . 516485 IN NS j.root-servers.net. > > . 516485 IN RRSIG NS 8 0 518400 > 202103 2021020922 42351 . > QCzDH8eHlHVbx4SxIIwk8xnk6ky/q+zRh8KAUfI98lqHcIP4NLxzCe6f > mC2sNX1VcthEy6Lwnobm8OyJCRpNEHedYrS01aMhAVzUfM+/PJ9MWn0w > SkmXxyZMJZXF/kl4GDNX0x/GW3+DkeTeZI9+B540Yvj47qJv2bD9nIQG > NtE7bDze7bgMJkIuBlEzPfwp7YW5ud8qdC6HdUoEMqygwZcWAiQu8gpb > q21z8W5hcdci1OouDFytNWrXAvfSsuR635+GzSj+RZjYo+447uP7lKsK > N5aeVQ/BPh5jM32xVO+zwyp7v9Nky1vSP/BchMQ/3cqg3Ee7zobl8OQd CSd/SA== > > ;; Received 1097 bytes from 192.168.33.12#53(192.168.33.12) in 0 ms > > > > us. 172800 IN NS a.cctld.us. > > us. 172800 IN NS b.cctld.us. > > us. 172800 IN NS c.cctld.us. > > us. 172800 IN NS e.cctld.us. > > us. 172800 IN NS f.cctld.us. > > us. 172800 IN NS k.cctld.us. > > us. 86400 IN DS 21364 8 1 > 260D0461242BCF8F05473A08B05ED01E6FA59B9C > > us. 86400 IN DS 21364 8 2 > B499CFA7B54D25FDE1E6FE93076FB013DAA664DA1F26585324740A1E 6EBDAB26 > > us. 86400 IN RRSIG DS 8 1 86400 202103 > 2021020922 42351 . > rujvGB0s2bsqzBuzRliH6QK9vH84ETZV7gZMEhJyzMFofWhj9ZZaNWE/ > VvdA9rC16IOEocvARv2rOqk7G3KTzdkHHZcwcZSQyVqsOIaIywGFuEgd > viSXF6+M5MocUgEMp5dtt6SBLHG+lE/FV/3HylKSHsxdO/F6PeWKgcBZ > D4lZQ6w5asmlbdKJKMhlWPp6UaxBE7ACaxndBQixoNqXQuPrXpXi1Fnj > ntFtTfn57hMyrdTojIJ8X7/HKjCrbm3CL/WJ+VZR051OGCdZVjpUaDXR > x7G9lDhu3K5clar9PGYyUJM7+RBKzrQJep7HrjL2nZdoTyfY4i33S+EZ sTlTOA== > > ;; Received 707 bytes from 199.7.91.13#53(d.root-servers.net) in 4 ms > > > > state.ma.us.7200IN NS internet-dns3.state.ma.us. > > state.ma.us.7200IN NS internet-dns1.state.ma.us. > > state.ma.us.7200IN NS internet-dns2.state.ma.us. > > state.ma.us.3600IN DS 47628 7 2 > 5379F9F747214E5A63416775396BCFF98FA4867AE66E09BCBEBE0DCC 1682C369 > > state.ma.us.3600IN DS 41388 7 1 > 36D899932AF794EADD671161515E48FE829BB7FE > > state.ma.us.
Re: Bind 9.11 serving up false answers for a single domain.
Thanks Mark. However, the traceroute to the hostnamed failed for the same reason. Please note: [root@myhost data]# dig internet-dns1.state.ma.us ; <<>> DiG 9.11.4-P2-RedHat-9.11.4-9.P2.el7 <<>> internet-dns1.state.ma.us ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 61641 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ;internet-dns1.state.ma.us. IN A ;; Query time: 1263 msec ;; SERVER: 192.168.33.12#53(192.168.33.12) ;; WHEN: Tue Feb 09 22:34:15 EST 2021 ;; MSG SIZE rcvd: 54 [root@myhost data]# dig internet-dns1.state.ma.us +trace ; <<>> DiG 9.11.4-P2-RedHat-9.11.4-9.P2.el7 <<>> internet-dns1.state.ma.us +trace ;; global options: +cmd . 516485 IN NS c.root-servers.net. . 516485 IN NS e.root-servers.net. . 516485 IN NS f.root-servers.net. . 516485 IN NS l.root-servers.net. . 516485 IN NS m.root-servers.net. . 516485 IN NS d.root-servers.net. . 516485 IN NS g.root-servers.net. . 516485 IN NS k.root-servers.net. . 516485 IN NS b.root-servers.net. . 516485 IN NS h.root-servers.net. . 516485 IN NS a.root-servers.net. . 516485 IN NS i.root-servers.net. . 516485 IN NS j.root-servers.net. . 516485 IN RRSIG NS 8 0 518400 202103 2021020922 42351 . QCzDH8eHlHVbx4SxIIwk8xnk6ky/q+zRh8KAUfI98lqHcIP4NLxzCe6f mC2sNX1VcthEy6Lwnobm8OyJCRpNEHedYrS01aMhAVzUfM+/PJ9MWn0w SkmXxyZMJZXF/kl4GDNX0x/GW3+DkeTeZI9+B540Yvj47qJv2bD9nIQG NtE7bDze7bgMJkIuBlEzPfwp7YW5ud8qdC6HdUoEMqygwZcWAiQu8gpb q21z8W5hcdci1OouDFytNWrXAvfSsuR635+GzSj+RZjYo+447uP7lKsK N5aeVQ/BPh5jM32xVO+zwyp7v9Nky1vSP/BchMQ/3cqg3Ee7zobl8OQd CSd/SA== ;; Received 1097 bytes from 192.168.33.12#53(192.168.33.12) in 0 ms us. 172800 IN NS a.cctld.us. us. 172800 IN NS b.cctld.us. us. 172800 IN NS c.cctld.us. us. 172800 IN NS e.cctld.us. us. 172800 IN NS f.cctld.us. us. 172800 IN NS k.cctld.us. us. 86400 IN DS 21364 8 1 260D0461242BCF8F05473A08B05ED01E6FA59B9C us. 86400 IN DS 21364 8 2 B499CFA7B54D25FDE1E6FE93076FB013DAA664DA1F26585324740A1E 6EBDAB26 us. 86400 IN RRSIG DS 8 1 86400 202103 2021020922 42351 . rujvGB0s2bsqzBuzRliH6QK9vH84ETZV7gZMEhJyzMFofWhj9ZZaNWE/ VvdA9rC16IOEocvARv2rOqk7G3KTzdkHHZcwcZSQyVqsOIaIywGFuEgd viSXF6+M5MocUgEMp5dtt6SBLHG+lE/FV/3HylKSHsxdO/F6PeWKgcBZ D4lZQ6w5asmlbdKJKMhlWPp6UaxBE7ACaxndBQixoNqXQuPrXpXi1Fnj ntFtTfn57hMyrdTojIJ8X7/HKjCrbm3CL/WJ+VZR051OGCdZVjpUaDXR x7G9lDhu3K5clar9PGYyUJM7+RBKzrQJep7HrjL2nZdoTyfY4i33S+EZ sTlTOA== ;; Received 707 bytes from 199.7.91.13#53(d.root-servers.net) in 4 ms state.ma.us.7200IN NS internet-dns3.state.ma.us. state.ma.us.7200IN NS internet-dns1.state.ma.us. state.ma.us.7200IN NS internet-dns2.state.ma.us. state.ma.us.3600IN DS 47628 7 2 5379F9F747214E5A63416775396BCFF98FA4867AE66E09BCBEBE0DCC 1682C369 state.ma.us.3600IN DS 41388 7 1 36D899932AF794EADD671161515E48FE829BB7FE state.ma.us.3600IN DS 41388 7 2 BBAB433D3853571F42516E70659AF1F85FA4FBA0FDFCEAD4D092592A 00C78769 state.ma.us.3600IN DS 47628 7 1 485E0EE2F7C08FCE51D1E284321242930274833A state.ma.us.3600IN RRSIG DS 8 3 3600 20210307200856 20210205191212 53985 us. O8KqBHzlZsDqrZi0NQO4JEiN0b8j04/Lb8W2uVz5PyrAat1VgZKQ3Ws6 6PNtbZDMv6YX6QA8fWFLxNmeJ1/4L3wLu8EKYXaThA9Zxll7mKFj1iPf nqiVq5hOo8Ul3inmfM/tjCQ21IHc/v0JZygZNd/h0SxXWlQXi+W3G9LN +4z/qxtl9dGD1ka54Ln3MAVxB1Tp4pt0ri4qPLmfGKf/HA== couldn't get address for 'internet-dns3.state.ma.us': not found couldn't get address for 'internet-dns1.state.ma.us': not found couldn't get address for 'internet-dns2.state.ma.us': not found dig: couldn't get address for 'internet-dns3.state.ma.us': no more [root@myhost data]# On Tue, Feb 9, 2021 at 10:10 PM Mark Andrews wrote: > Well you could try tracing the addresses of the nameservers for which > there where errors reported. It could be as simple as a routing issue > between you and these servers. > > > On 10 Feb 2021, at 13:25, sami's strat wrote: > > > > couldn't get address for 'internet-dns1.state.ma.us': not
Re: Bind 9.11 serving up false answers for a single domain.
Well you could try tracing the addresses of the nameservers for which there where errors reported. It could be as simple as a routing issue between you and these servers. > On 10 Feb 2021, at 13:25, sami's strat wrote: > > couldn't get address for 'internet-dns1.state.ma.us': not found > couldn't get address for 'internet-dns3.state.ma.us': not found > couldn't get address for 'internet-dns2.state.ma.us': not found > dig: couldn't get address for 'internet-dns1.state.ma.us': no more -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Bind 9.11 serving up false answers for a single domain.
I'm running BIND 9.11 on a CentOS 7 VM/ BIND is giving me the wrong answer for a single domain. I've cleared cache, restarted BIND, restarted the server, and ensured that I don't have the referenced domain anywhere in my configuration hardcoded. Please note the following query: [root@myhost ~]# dig dor.state.ma.us mx ; <<>> DiG 9.11.4-P2-RedHat-9.11.4-9.P2.el7 <<>> dor.state.ma.us mx ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 41519 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ;dor.state.ma.us. IN MX ;; Query time: 17 msec ;; SERVER: 192.168.33.12#53(192.168.33.12) ;; WHEN: Tue Feb 09 21:01:28 EST 2021 ;; MSG SIZE rcvd: 44 [root@myhost ~]# dig dor.state.ma.us mx +trace ; <<>> DiG 9.11.4-P2-RedHat-9.11.4-9.P2.el7 <<>> dor.state.ma.us mx +trace ;; global options: +cmd . 517726 IN NS d.root-servers.net. . 517726 IN NS i.root-servers.net. . 517726 IN NS l.root-servers.net. . 517726 IN NS g.root-servers.net. . 517726 IN NS h.root-servers.net. . 517726 IN NS e.root-servers.net. . 517726 IN NS b.root-servers.net. . 517726 IN NS a.root-servers.net. . 517726 IN NS j.root-servers.net. . 517726 IN NS m.root-servers.net. . 517726 IN NS c.root-servers.net. . 517726 IN NS f.root-servers.net. . 517726 IN NS k.root-servers.net. . 517726 IN RRSIG NS 8 0 518400 202103 2021020922 42351 . QCzDH8eHlHVbx4SxIIwk8xnk6ky/q+zRh8KAUfI98lqHcIP4NLxzCe6f mC2sNX1VcthEy6Lwnobm8OyJCRpNEHedYrS01aMhAVzUfM+/PJ9MWn0w SkmXxyZMJZXF/kl4GDNX0x/GW3+DkeTeZI9+B540Yvj47qJv2bD9nIQG NtE7bDze7bgMJkIuBlEzPfwp7YW5ud8qdC6HdUoEMqygwZcWAiQu8gpb q21z8W5hcdci1OouDFytNWrXAvfSsuR635+GzSj+RZjYo+447uP7lKsK N5aeVQ/BPh5jM32xVO+zwyp7v9Nky1vSP/BchMQ/3cqg3Ee7zobl8OQd CSd/SA== ;; Received 1097 bytes from 192.168.33.12#53(192.168.33.12) in 0 ms us. 172800 IN NS a.cctld.us. us. 172800 IN NS b.cctld.us. us. 172800 IN NS c.cctld.us. us. 172800 IN NS e.cctld.us. us. 172800 IN NS f.cctld.us. us. 172800 IN NS k.cctld.us. us. 86400 IN DS 21364 8 1 260D0461242BCF8F05473A08B05ED01E6FA59B9C us. 86400 IN DS 21364 8 2 B499CFA7B54D25FDE1E6FE93076FB013DAA664DA1F26585324740A1E 6EBDAB26 us. 86400 IN RRSIG DS 8 1 86400 202103 2021020922 42351 . rujvGB0s2bsqzBuzRliH6QK9vH84ETZV7gZMEhJyzMFofWhj9ZZaNWE/ VvdA9rC16IOEocvARv2rOqk7G3KTzdkHHZcwcZSQyVqsOIaIywGFuEgd viSXF6+M5MocUgEMp5dtt6SBLHG+lE/FV/3HylKSHsxdO/F6PeWKgcBZ D4lZQ6w5asmlbdKJKMhlWPp6UaxBE7ACaxndBQixoNqXQuPrXpXi1Fnj ntFtTfn57hMyrdTojIJ8X7/HKjCrbm3CL/WJ+VZR051OGCdZVjpUaDXR x7G9lDhu3K5clar9PGYyUJM7+RBKzrQJep7HrjL2nZdoTyfY4i33S+EZ sTlTOA== ;; Received 697 bytes from 199.9.14.201#53(b.root-servers.net) in 3 ms state.ma.us.7200IN NS internet-dns1.state.ma.us. state.ma.us.7200IN NS internet-dns3.state.ma.us. state.ma.us.7200IN NS internet-dns2.state.ma.us. state.ma.us.3600IN DS 41388 7 1 36D899932AF794EADD671161515E48FE829BB7FE state.ma.us.3600IN DS 41388 7 2 BBAB433D3853571F42516E70659AF1F85FA4FBA0FDFCEAD4D092592A 00C78769 state.ma.us.3600IN DS 47628 7 1 485E0EE2F7C08FCE51D1E284321242930274833A state.ma.us.3600IN DS 47628 7 2 5379F9F747214E5A63416775396BCFF98FA4867AE66E09BCBEBE0DCC 1682C369 state.ma.us.3600IN RRSIG DS 8 3 3600 20210307200856 20210205191212 53985 us. O8KqBHzlZsDqrZi0NQO4JEiN0b8j04/Lb8W2uVz5PyrAat1VgZKQ3Ws6 6PNtbZDMv6YX6QA8fWFLxNmeJ1/4L3wLu8EKYXaThA9Zxll7mKFj1iPf nqiVq5hOo8Ul3inmfM/tjCQ21IHc/v0JZygZNd/h0SxXWlQXi+W3G9LN +4z/qxtl9dGD1ka54Ln3MAVxB1Tp4pt0ri4qPLmfGKf/HA== couldn't get address for 'internet-dns1.state.ma.us': not found couldn't get address for 'internet-dns3.state.ma.us': not found couldn't get address for 'internet-dns2.state.ma.us': not found dig: couldn't get address for 'internet-dns1.state.ma.us': no more It fails on my production DNS system, yet if I run that query on another host, it works fine, with no issues. Any idea why BIND would do this? TIA ___ Please visit
Re: DNSSEC and NSEC missing ZSK?
On 09 Feb 2021, at 16:19, Mal via bind-users wrote: > On 09/02/2021 10:47 pm, @ wrote: >> Well, I have finally ogttenteh test zone to the point where dnssec-verify is >> happy and everything that I can check also seems happy except dnsviz which >> is very very VERY angry and basically says the zone is entirely garabge. I >> am hoping this is a propagation issue, but I kind of doubt it since it >> should be quarrying the authoritative DNS for the DNSKEY and RRSIG and such, >> I'd think. > The easiest way to get help is to post your named.conf and zone file. Not doing that for domains that are not actually owned by me, which includes the domain I was using to test this setup. > DNSVIZ displays your current state very well. If its showing you > errors, then it requires you to act. Seems not to be the case as after 10 hours or so, dnsviz has stopped complaining. -- Heisenberg's only uncertainty was what pub to vomit in next and Jung fancied Freud's mother too. -- Jared Earle ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: DNSSEC and NSEC missing ZSK?
On 09/02/2021 10:47 pm, @ wrote: > Well, I have finally ogttenteh test zone to the point where dnssec-verify is > happy and everything that I can check also seems happy except dnsviz which is > very very VERY angry and basically says the zone is entirely garabge. I am > hoping this is a propagation issue, but I kind of doubt it since it should be > quarrying the authoritative DNS for the DNSKEY and RRSIG and such, I'd think. The easiest way to get help is to post your named.conf and zone file. Obfuscating the configuration works against you, especially when you have a limited understanding of DNSSEC. DNSVIZ displays your current state very well. If its showing you errors, then it requires you to act. The query IPs DNSVIZ typically uses are: 64.191.0.132 64.191.0.138 2620:ff:c000::132 2620:ff:c000::138 So you can easily reconcile the DNSVIZ query, in real time, that produced your data set. The DS record propagation, at the registry level, should never take days (no more than 15-30 minutes is my experience). You need to make sure you have configured (or instructed the registry, per manual intervention) the correct Algorithm (13) and the digest type (SHA256) when you provide your Hash. ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Forward zone does not work when allow recursive is restrictive
“forward” does not mean “proxy". Additionally servers out on the internet make
iterative queries. They are non-recursive *AND* follow delegations. Making a
proxy work is more that just relaying the request and the response.
BIND does not support proxying other servers.
> On 10 Feb 2021, at 08:44, Sebastian Neumann wrote:
>
> Hey there,
>
> I am having an issue forwarding DNS queries and was hoping, that one of you
> might be able to help me:
>
> I have the following setup:
>
> DNS-Server reachable from the internet, is authoritative for zone foo.com
> DNS-Server reachable only locally, should be authoritative for zone
> test.lab.foo.com
> What I try to achieve:
>
> When a DNS query from the outside world reaches the first DNS server for a
> record belonging to the zone test.lab.foo.com, I want it to make a recursive
> request to the second DNS server and then forward the records.
>
> I explicitly don't want to do zone transfers or make the second DNS server
> reachable from the internet.
>
> my configuration looks like this: (I only copied the [what I think] important
> parts to here, as all the Config would be a few hundret lines (because of
> split view and many zones)
>
> On the first DNS-Server
>
> options {
> allow-recursion {
> localnets;
> localhost;
> internal;
> my-datacenter;
> mc-office;
> };
> };
>
> zone "test.lab.foo.com" {
> forward only;
> forwarders {
> ;
> };
> type forward;
> };
>
> zone "foo.com" {
> file "/etc/bind/zones/foo.com.zone";
> type master;
> };
> My issue:
>
> When I am in a local network, that is whitelisted in the allow-recursion
> block, then it works as expected. When I try the DNS lookup from the
> internet, then i get a NOERROR with an empty response back.
>
> During debugging, I adjusted the allow-recursion list and added any to it.
> Then it was working. But I don't want my DNS server to allow any kind of
> recursion. I actually only want "outside" lookups for this one specific zones
> to be recursive.
>
> How can I set something like allow-recursion for just one zone?
>
> Thanks a lot already
> ___
> Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
> from this list
>
> ISC funds the development of this software with paid support subscriptions.
> Contact us at https://www.isc.org/contact/ for more information.
>
>
> bind-users mailing list
> bind-users@lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list
ISC funds the development of this software with paid support subscriptions.
Contact us at https://www.isc.org/contact/ for more information.
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Forward zone does not work when allow recursive is restrictive
Hey there,
I am having an issue forwarding DNS queries and was hoping, that one of you
might be able to help me:
I have the following setup:
DNS-Server reachable from the internet, is authoritative for zone foo.com
DNS-Server reachable only locally, should be authoritative for zone
test.lab.foo.com
What I try to achieve:
When a DNS query from the outside world reaches the first DNS server for a
record belonging to the zone test.lab.foo.com, I want it to make a recursive
request to the second DNS server and then forward the records.
I explicitly don't want to do zone transfers or make the second DNS server
reachable from the internet.
my configuration looks like this: (I only copied the [what I think] important
parts to here, as all the Config would be a few hundret lines (because of split
view and many zones)
On the first DNS-Server
options {
allow-recursion {
localnets;
localhost;
internal;
my-datacenter;
mc-office;
};
};
zone "test.lab.foo.com" {
forward only;
forwarders {
;
};
type forward;
};
zone "foo.com" {
file "/etc/bind/zones/foo.com.zone";
type master;
};
My issue:
When I am in a local network, that is whitelisted in the allow-recursion block,
then it works as expected. When I try the DNS lookup from the internet, then i
get a NOERROR with an empty response back.
During debugging, I adjusted the allow-recursion list and added any to it. Then
it was working. But I don't want my DNS server to allow any kind of recursion.
I actually only want "outside" lookups for this one specific zones to be
recursive.
How can I set something like allow-recursion for just one zone?
Thanks a lot already
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list
ISC funds the development of this software with paid support subscriptions.
Contact us at https://www.isc.org/contact/ for more information.
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: Trying again on SERVFAIL
> is there a way to know that a query has already been tried a few > minutes ago, and failed? >From whose perspective? A well-behaved application could remember it asked the same query a short while ago, of course, but that's up to the application. Or is the perspective that of a recursive resolver? As far as I remember, BIND used as a recursive resolver will "cache" this knowledge, but I'm not entirely certain for how long, since it can't use the method from an NXDOMAIN reply which includes the SOA record (and uses the re-purposed "minimum" field for the TTL for the negative cache entry). > It happens seldomly, but sometimes the DKIM mail filter gets a > SERVFAIL when it tries to authenticate an incoming message. > SERVFAIL occurs when DNSSEC check fails. ...or when none of the name servers for the containing zone responds with an answer. I.e. it's not *just* DNSSEC failure which can trigger SERVFAIL. > Trying again is useless, it has to be treated as a permanent > error. Well, now... Basically nothing in the DNS is permanent, because it is not completely static; hence most information in the DNS has a TTL attached to it. So the question then becomes how an application, say a mail server should treat SERVFAIL. It may very well be that the "maximum retry time" of the mail server is far longer than any of the TTLs for the pieces of DNS data that you could not look up, so it may be appropriate to treat SERVFAIL as a signal to "re-queue the message and try again in 30 minutes", so in essence converting SERVFAIL into a "temporary failure" in the context of the mail server. SERVFAIL doesn't mean that the domain name you tried to look up currently doesn't exist in the DNS, you just can't know one way or the other. > Any idea about how to tell a really temporary error? You again have to specify the context. Regards, - Håvard ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: DNSSEC and NSEC missing ZSK?
On 08 Feb 2021, at 11:10, @lbutlr wrote: > That recreates the .signed.jnl and not the .signed file. No errors are > reported. Well, I have finally ogttenteh test zone to the point where dnssec-verify is happy and everything that I can check also seems happy except dnsviz which is very very VERY angry and basically says the zone is entirely garabge. I am hoping this is a propagation issue, but I kind of doubt it since it should be quarrying the authoritative DNS for the DNSKEY and RRSIG and such, I'd think. I'll give it a couple of days and see where I am there before I try to move any domains that are actually used. Thanks everyone for prods and hints along this path. -- When and where does this "real world" occur?! ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Trying again on SERVFAIL
Hi, is there a way to know that a query has already been tried a few minutes ago, and failed? It happens seldomly, but sometimes the DKIM mail filter gets a SERVFAIL when it tries to authenticate an incoming message. SERVFAIL occurs when DNSSEC check fails. Trying again is useless, it has to be treated as a permanent error. Any idea about how to tell a really temporary error? Best Ale -- ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
