Re: 9.18 BIND not iterated over all authoritative nameservers

> Am 30.10.2023 um 16:59 schrieb Michael Martinell via bind-users > : > > Thanks to all who responded. Putting qname-minimization disabled; in > named.conf resolves the issue in my testing. > > I did try specifying relaxed (which appears to be the default), but that > didn’t work either. >

RE: 9.18 BIND not iterated over all authoritative nameservers

over all authoritative nameservers I wasn't On Sat, Oct 28, 2023, 5:23 PM Ondřej Surý mailto:ond...@isc.org>> wrote: Please don’t use Postel’s Law as excuse for implementations that break standards: https://datatracker.ietf.org/doc/html/rfc9413<https://datatracker.ietf.org/doc/htm

Re: 9.18 BIND not iterated over all authoritative nameservers

I wasn't On Sat, Oct 28, 2023, 5:23 PM Ondřej Surý wrote: > Please don’t use Postel’s Law as excuse for implementations that break > standards: https://datatracker.ietf.org/doc/html/rfc9413 > -- > Ondřej Surý — ISC (He/Him) > > My working hours and your working hours may be different. Please do

Re: 9.18 BIND not iterated over all authoritative nameservers

Please don’t use Postel’s Law as excuse for implementations that break standards: https://datatracker.ietf.org/doc/html/rfc9413--Ondřej Surý — ISC (He/Him)My working hours and your working hours may be different. Please do not feel obligated to reply outside your normal working hours.On 28. 10.

Re: 9.18 BIND not iterated over all authoritative nameservers

As a previous ISP admin I too have come across similar situations and frustrations. I can only say that Google and Cloudflare seem to follow Postel's Law moreso than BIND. I agree this perpetuates bad practices but end users aren't interested in technical reasoning, especially when "it works

Re: 9.18 BIND not iterated over all authoritative nameservers

As Mark mentions, the NS records gtm.bankeasy.com need to be corrected and failure is not due to lack of iterating through all auth nameservers (all of the auth nameservers have the bad NS record anyway). Not sure how many other domains you are running into similar

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:

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 ; <<>>

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