Re: 9.18 BIND not iterated over all authoritative nameservers

2023-10-28 Thread Rick Frey 
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  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 
>>  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

Re: 9.18 BIND not iterated over all authoritative nameservers

2023-10-28 Thread 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  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  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

Re: 9.18 BIND not iterated over all authoritative nameservers

2023-10-28 Thread Ondřej Surý 
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. 2023, at 17:50, Paul Stead  wrote: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"PaulOn Sat, Oct 28, 2023, 3:56 PM Rick Frey  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. - RickOn Oct 27, 2023, at 6:31 PM, Mark Andrews  wrote:Named now uses NS lookups to perform QNAME minimisation.  If one puts garbage in the NSrecords then they should expect lookups to fail.  The NS records on both sides of a zonecut are supposed to be IDENTICAL.  This is not a new requirement.  It has been this waysince the very beginning.The bank needs to fix what they publish.MarkOn 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.xEvery 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 && ldconfigInterstate Telecommunications Coop., Inc.312 4th Street West • Clear Lake, SD 57226Phone: (605) 874-8313michael.martin...@itccoop.comwww.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 listISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information.bind-users mailing listbind-users@lists.isc.orghttps://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

Re: 9.18 BIND not iterated over all authoritative nameservers

2023-10-28 Thread Paul Stead 
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 not
> feel obligated to reply outside your normal working hours.
>
> On 28. 10. 2023, at 17:50, Paul Stead  wrote:
>
> 
> 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  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  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
>
>
-- 
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