Re: 9.18 BIND not iterated over all authoritative nameservers
Well if the bank is stupid enough to use NS records that point to nameservers that do not exist on the internet then lookups FAIL. % dig ns gtm.bankeasy.com ;; BADCOOKIE, retrying. ; <<>> DiG 9.19.18-dev <<>> ns gtm.bankeasy.com ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 48050 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 1232 ; COOKIE: dbef45feadd7b3850100653c2cefd1f381fbb389e388 (good) ;; QUESTION SECTION: ;gtm.bankeasy.com. IN NS ;; ANSWER SECTION: gtm.bankeasy.com. 0 IN NS bkx-bigip1-out.ffc.local. ;; Query time: 992 msec ;; SERVER: ::1#53(::1) (UDP) ;; WHEN: Sat Oct 28 08:34:39 AEDT 2023 ;; MSG SIZE rcvd: 111 % Named now uses NS lookups to perform QNAME minimisation. If one puts garbage in the NS records then they should expect lookups to fail. The NS records on both sides of a zone cut are supposed to be IDENTICAL. This is not a new requirement. It has been this way since the very beginning. The bank needs to fix what they publish. Mark > On 28 Oct 2023, at 02:36, Michael Martinell via bind-users > wrote: > > Hello, > At this point I am hoping that somebody might have a workaround so that we > can exclude domains from this behavior if they are broken on the far end. > Does anybody have a workaround for this? > We are a small ISP and run BIND compiled from source. We currently run 9.16.x > Every time we try to move forward with 9.18 customers start to complain that > they are unable to reach certain websites. This includes banks, > universities, and other organizations. > I understand the goal is to get all DNS to RFC 6891, but from a practical > standpoint, this isn’t working for customers, so we are prevented from > upgrading either. > Related website: > https://gitlab.isc.org/isc-projects/bind9/-/issues/3152 > Our source code compile options: > ./configure --with-gnu-ld --with-libxml2 --with-json-c > --with-openssl=/usr/local/openssl && make && make install && ldconfig > When I do a dig against a server running 9.18 I get the following: > dig @dns1.itctel.com view.bankeasy.com > ; <<>> DiG 9.16.42 <<>> @dns1.itctel.com view.bankeasy.com > ; (2 servers found) > ;; global options: +cmd > ;; Got answer: > ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 46906 > ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1 > ;; OPT PSEUDOSECTION: > ; EDNS: version: 0, flags:; udp: 1232 > ; COOKIE: d8ce8161641fbfdf0100653bcf9ad1fff99d24914278 (good) > ;; QUESTION SECTION: > ;view.bankeasy.com. IN A > ;; Query time: 8 msec > ;; SERVER: > 2607:d600:1000:330:75:102:161:227#53(2607:d600:1000:330:75:102:161:227) > ;; WHEN: Fri Oct 27 09:56:26 CDT 2023 > ;; MSG SIZE rcvd: 74 > The same command resolves just fine when I run it against 9.16 > dig @dns2.itctel.com view.bankeasy.com > ; <<>> DiG 9.16.42 <<>> @dns2.itctel.com view.bankeasy.com > ; (2 servers found) > ;; global options: +cmd > ;; Got answer: > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 30969 > ;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1 > ;; OPT PSEUDOSECTION: > ; EDNS: version: 0, flags:; udp: 1232 > ; COOKIE: b0ec30c4ddfeacd30100653bcf9ff140c249344242e0 (good) > ;; QUESTION SECTION: > ;view.bankeasy.com. IN A > ;; ANSWER SECTION: > view.bankeasy.com. 3133 IN CNAME view.gtm.bankeasy.com. > view.gtm.bankeasy.com. 300 IN A 96.2.250.200 > ;; Query time: 11 msec > ;; SERVER: > 2607:d600:9000:330:75:102:160:227#53(2607:d600:9000:330:75:102:160:227) > ;; WHEN: Fri Oct 27 09:56:31 CDT 2023 > ;; MSG SIZE rcvd: 125 > [root@brkr-dns2 bind-9.18.12]# > Michael Martinell > Network/Broadband Technician > > Interstate Telecommunications Coop., Inc. > 312 4th Street West • Clear Lake, SD 57226 > Phone: (605) 874-8313 > michael.martin...@itccoop.com > www.itc-web.com > -- > 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 -- 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: 9.18 BIND not iterated over all authoritative nameservers
Doing some checking on this locally trying to understand what may be happening. I stumbled across this: view.bankeasy.com is a cname to view.gtm.bankeasy.com However if I try to dig for gtm.bankeasy.com that is where the oddities show up: dig @ns1.dakotanames.com gtm.bankeasy.com ; <<>> DiG 9.18.18 <<>> @ns1.dakotanames.com gtm.bankeasy.com ; (1 server found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 5025 ;; flags: qr aa rd; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1 ;; WARNING: recursion requested but not available ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ;gtm.bankeasy.com. IN A ;; AUTHORITY SECTION: gtm.bankeasy.com. 60 IN SOA bkx-bigip1-out.ffc.local. hos tmaster.bkx-bigip1-out.ffc.local. 2023102501 10800 3600 604800 60 ;; Query time: 52 msec ;; SERVER: 96.2.250.214#53(ns1.dakotanames.com) (UDP) ;; WHEN: Fri Oct 27 18:03:58 CDT 2023 ;; MSG SIZE rcvd: 116 Not sure how this effects things, but the SOA record shows bad info '.local.' I wonder if this is where the issue is. The authoritive nameserver and responsible party records are not resolvable. Maybe someone with more knowledge of DNS and the use of .local. domain name can shed some light on this. Lyle Giese On 10/27/23 10:36, Michael Martinell via bind-users wrote: Hello, At this point I am hoping that somebody might have a workaround so that we can exclude domains from this behavior if they are broken on the far end. Does anybody have a workaround for this? We are a small ISP and run BIND compiled from source. We currently run 9.16.x Every time we try to move forward with 9.18 customers start to complain that they are unable to reach certain websites. This includes banks, universities, and other organizations. I understand the goal is to get all DNS to RFC 6891, but from a practical standpoint, this isn’t working for customers, so we are prevented from upgrading either. Related website: https://gitlab.isc.org/isc-projects/bind9/-/issues/3152 Our source code compile options: ./configure --with-gnu-ld --with-libxml2 --with-json-c --with-openssl=/usr/local/openssl && make && make install && ldconfig When I do a dig against a server running 9.18 I get the following: dig @dns1.itctel.com view.bankeasy.com ; <<>> DiG 9.16.42 <<>> @dns1.itctel.com view.bankeasy.com ; (2 servers found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 46906 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 1232 ; COOKIE: d8ce8161641fbfdf0100653bcf9ad1fff99d24914278 (good) ;; QUESTION SECTION: ;view.bankeasy.com. IN A ;; Query time: 8 msec ;; SERVER: 2607:d600:1000:330:75:102:161:227#53(2607:d600:1000:330:75:102:161:227) ;; WHEN: Fri Oct 27 09:56:26 CDT 2023 ;; MSG SIZE rcvd: 74 The same command resolves just fine when I run it against 9.16 dig @dns2.itctel.com view.bankeasy.com ; <<>> DiG 9.16.42 <<>> @dns2.itctel.com view.bankeasy.com ; (2 servers found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 30969 ;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 1232 ; COOKIE: b0ec30c4ddfeacd30100653bcf9ff140c249344242e0 (good) ;; QUESTION SECTION: ;view.bankeasy.com. IN A ;; ANSWER SECTION: view.bankeasy.com. 3133 IN CNAME view.gtm.bankeasy.com. view.gtm.bankeasy.com. 300 IN A 96.2.250.200 ;; Query time: 11 msec ;; SERVER: 2607:d600:9000:330:75:102:160:227#53(2607:d600:9000:330:75:102:160:227) ;; WHEN: Fri Oct 27 09:56:31 CDT 2023 ;; MSG SIZE rcvd: 125 [root@brkr-dns2 bind-9.18.12]# *Michael Martinell* Network/Broadband Technician *Interstate Telecommunications Coop., Inc. *312 4th Street West • Clear Lake, SD 57226 Phone: (605) 874-8313 michael.martin...@itccoop.com www.itc-web.com -- 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
9.18 BIND not iterated over all authoritative nameservers
Hello, At this point I am hoping that somebody might have a workaround so that we can exclude domains from this behavior if they are broken on the far end. Does anybody have a workaround for this? We are a small ISP and run BIND compiled from source. We currently run 9.16.x Every time we try to move forward with 9.18 customers start to complain that they are unable to reach certain websites. This includes banks, universities, and other organizations. I understand the goal is to get all DNS to RFC 6891, but from a practical standpoint, this isn't working for customers, so we are prevented from upgrading either. Related website: https://gitlab.isc.org/isc-projects/bind9/-/issues/3152 Our source code compile options: ./configure --with-gnu-ld --with-libxml2 --with-json-c --with-openssl=/usr/local/openssl && make && make install && ldconfig When I do a dig against a server running 9.18 I get the following: dig @dns1.itctel.com view.bankeasy.com ; <<>> DiG 9.16.42 <<>> @dns1.itctel.com view.bankeasy.com ; (2 servers found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 46906 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 1232 ; COOKIE: d8ce8161641fbfdf0100653bcf9ad1fff99d24914278 (good) ;; QUESTION SECTION: ;view.bankeasy.com. IN A ;; Query time: 8 msec ;; SERVER: 2607:d600:1000:330:75:102:161:227#53(2607:d600:1000:330:75:102:161:227) ;; WHEN: Fri Oct 27 09:56:26 CDT 2023 ;; MSG SIZE rcvd: 74 The same command resolves just fine when I run it against 9.16 dig @dns2.itctel.com view.bankeasy.com ; <<>> DiG 9.16.42 <<>> @dns2.itctel.com view.bankeasy.com ; (2 servers found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 30969 ;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 1232 ; COOKIE: b0ec30c4ddfeacd30100653bcf9ff140c249344242e0 (good) ;; QUESTION SECTION: ;view.bankeasy.com. IN A ;; ANSWER SECTION: view.bankeasy.com. 3133 IN CNAME view.gtm.bankeasy.com. view.gtm.bankeasy.com. 300 IN A 96.2.250.200 ;; Query time: 11 msec ;; SERVER: 2607:d600:9000:330:75:102:160:227#53(2607:d600:9000:330:75:102:160:227) ;; WHEN: Fri Oct 27 09:56:31 CDT 2023 ;; MSG SIZE rcvd: 125 [root@brkr-dns2 bind-9.18.12]# Michael Martinell Network/Broadband Technician Interstate Telecommunications Coop., Inc. 312 4th Street West * Clear Lake, SD 57226 Phone: (605) 874-8313 michael.martin...@itccoop.com www.itc-web.com -- 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
