9.18 BIND not iterated over all authoritative nameservers

[Paul Stead]

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 everywhere else, you must be
broken"

Paul


On Sat, Oct 28, 2023, 3:56 PM Rick Frey <gribnut at gmail.com> wrote:

> 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 problem, but
> you could disable qname-minimization in 9.18 to mimic previous behavior of
> 9.16 if that number is large.  I believe qname-minimization is a global
> directive so it would remove privacy benefits of QNAME minimization for all
> recursive queries from your nameserver.
>
> As DNS admin of another ISP, I sympathize dealing with failures caused by
> non-compliant authoritative nameservers.  These non-compliant auth
> nameservers can have little motivation to fix, especially when other large
> ISPs or public resolvers (looking at you Google and Cloudflare) don’t
> enforce DNS standards.   Many non-compliant nameservers/records would be
> cleaned up if public/centralized DNS providers such as Google/Cloudflare
> would enforce since it would inflict those failures on a much larger user
> base.
>
>  - Rick
>
>
>
> On Oct 27, 2023, at 6:31 PM, Mark Andrews <marka at isc.org> wrote:
>
>
>
> 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 <
> bind-users at lists.isc.org> 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
>
>
>
> 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
>
>
>
> --
> 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 at lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20231028/61d51f6a/attachment.htm>