9.18 BIND not iterated over all authoritative nameservers

[Lyle Giese]

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: d8ce8161641fbfdf01000000653bcf9ad1fff99d24914278 (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: b0ec30c4ddfeacd301000000653bcf9ff140c249344242e0 (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 at 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.martinell at itccoop.com
> www.itc-web.com
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20231027/392be374/attachment-0001.htm>