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 <grib...@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 <ma...@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@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.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 >
-- 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
