Re: Broken DNS QNAME Recovery

2024-04-22 Thread Mark Andrews
No. “Forward zones” are not DNS zones. They are overrides to the DNS resolution 
processes that just happened to be configured in named by overloading the zone 
syntax element.  Similarly stub and static stub are not zones. The are other 
things. 

-- 
Mark Andrews

> On 23 Apr 2024, at 01:24, John Thurston  wrote:
> 
>  On 4/21/2024 10:05 PM, Mark Andrews wrote:
>> On 19 Apr 2024, at 16:12, Crist Clark  wrote:
>>> 
>>> First, yes, I know. Their DNS is broken. They should fix their DNS. We 
>>> shouldn't need to make QNAME-minimization work around broken DNS.
>>> 
>>> Name and shame a domain name in question,
>>> 
>>> e1083.d.akamaiedge.akamai.csd.disa.mil
>>> 
>>> The problem I see: akamai.csd.disa.mil is a delegated zone. All four name 
>>> servers for the zone are in the zone. All four of the addresses in the 
>>> parent's glue are unresponsive. It's actually the same for 
>>> d.akamaiedge.akamai.csd.disa.mil too.
>>> 
>>> That is breaking resolution for BIND 9.18 servers with default 
>>> qname-minimization. If qname-minimization is set "off", it works. That's 
>>> because the disa.mil NSes will respond with the answer for that full name. 
>>> We never go farther up the name to try to find the non-responsive NS 
>>> servers.
>>> 
>>> (And yes, the DNS "authoritative" servers here are questionable too. The 
>>> TTLs look like they are caching answers, but all of the responses have AA 
>>> set.)
>>> 
>>> Does that assessment look correct? I know BIND defaults to "relaxed" QNAME 
>>> minimization. It works around certain cases of brokeness. I guess this is 
>>> not one of them? Should it be? It's a case where things work without 
>>> minimization. The brokeness is hidden for non-minimizing resolvers.
>>> 
>>> Again, yeah, they are broken. They should fix it, but it broke someone's 
>>> Very Important Work at our shop. And it used to work and it works from home 
>>> and for other customers so it must be our DNS that's broken. So we end up 
>>> setting "qname-minimization off" globally despite the fact they are really 
>>> the broken ones. We'd rather keep minimization on, but it's the only 
>>> reasonable work around we could find.
>> Just use a forward zone in forward only mode.  When the parent servers give 
>> you non working nameservers for child zones there isn’t a sensible automatic 
>> solution.
>> 
>> zone disa.mil {
>> type forward;
>> forward only;
>> forwarders { 152.229.110.235; 214.3.125.231; 131.77.60.235; };
>> };
> 
> Can such forward-zones be defined in catalog-zones?
> 
> 
> 
> --
> Do things because you should, not just because you can. 
> 
> John Thurston907-465-8591
> john.thurs...@alaska.gov
> Department of Administration
> State of Alaska
> -- 
> 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: Broken DNS QNAME Recovery

2024-04-22 Thread John Thurston

On 4/21/2024 10:05 PM, Mark Andrews wrote:

On 19 Apr 2024, at 16:12, Crist Clark  wrote:

First, yes, I know. Their DNS is broken. They should fix their DNS. We 
shouldn't need to make QNAME-minimization work around broken DNS.

Name and shame a domain name in question,

 e1083.d.akamaiedge.akamai.csd.disa.mil

The problem I see: akamai.csd.disa.mil is a delegated zone. All four name 
servers for the zone are in the zone. All four of the addresses in the parent's 
glue are unresponsive. It's actually the same for 
d.akamaiedge.akamai.csd.disa.mil too.

That is breaking resolution for BIND 9.18 servers with default qname-minimization. If 
qname-minimization is set "off", it works. That's because the disa.mil NSes 
will respond with the answer for that full name. We never go farther up the name to try 
to find the non-responsive NS servers.

(And yes, the DNS "authoritative" servers here are questionable too. The TTLs 
look like they are caching answers, but all of the responses have AA set.)

Does that assessment look correct? I know BIND defaults to "relaxed" QNAME 
minimization. It works around certain cases of brokeness. I guess this is not one of 
them? Should it be? It's a case where things work without minimization. The brokeness is 
hidden for non-minimizing resolvers.

Again, yeah, they are broken. They should fix it, but it broke someone's Very Important 
Work at our shop. And it used to work and it works from home and for other customers so 
it must be our DNS that's broken. So we end up setting "qname-minimization off" 
globally despite the fact they are really the broken ones. We'd rather keep minimization 
on, but it's the only reasonable work around we could find.

Just use a forward zone in forward only mode.  When the parent servers give you 
non working nameservers for child zones there isn’t a sensible automatic 
solution.

zone disa.mil {
 type forward;
 forward only;
 forwarders { 152.229.110.235; 214.3.125.231; 131.77.60.235; };
};



Can such forward-zones be defined in catalog-zones?


--
Do things because you should, not just because you can.

John Thurston907-465-8591
john.thurs...@alaska.gov
Department of Administration
State of Alaska
-- 
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: RFC8482: Implementation

2024-04-22 Thread Greg Choules via bind-users
Hi.
In BIND, since 9.11, there is an option/view statement called
"minimal-any", which defaults to "no". That might be what you're after.

Cheers, Greg

On Sat, 20 Apr 2024 at 17:29, Amaury Van Pevenaeyge <
avanpevenae...@outlook.fr> wrote:

> Hello everyone,
>
> I've been looking for days and days for a way to implement the principle
> documented in RFC8482 (Providing Minimal-Sized Responses to DNS Queries
> That Have QTYPE=ANY) as Cloudflare is currently doing. I can't find the
> solution to do this. Can anyone help me with this?
>
> Thanks in advance
> --
> 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: Broken DNS QNAME Recovery

2024-04-22 Thread Mark Andrews


> On 19 Apr 2024, at 16:12, Crist Clark  wrote:
> 
> First, yes, I know. Their DNS is broken. They should fix their DNS. We 
> shouldn't need to make QNAME-minimization work around broken DNS.
> 
> Name and shame a domain name in question,
> 
> e1083.d.akamaiedge.akamai.csd.disa.mil
> 
> The problem I see: akamai.csd.disa.mil is a delegated zone. All four name 
> servers for the zone are in the zone. All four of the addresses in the 
> parent's glue are unresponsive. It's actually the same for 
> d.akamaiedge.akamai.csd.disa.mil too.
> 
> That is breaking resolution for BIND 9.18 servers with default 
> qname-minimization. If qname-minimization is set "off", it works. That's 
> because the disa.mil NSes will respond with the answer for that full name. We 
> never go farther up the name to try to find the non-responsive NS servers.
> 
> (And yes, the DNS "authoritative" servers here are questionable too. The TTLs 
> look like they are caching answers, but all of the responses have AA set.)
> 
> Does that assessment look correct? I know BIND defaults to "relaxed" QNAME 
> minimization. It works around certain cases of brokeness. I guess this is not 
> one of them? Should it be? It's a case where things work without 
> minimization. The brokeness is hidden for non-minimizing resolvers.
> 
> Again, yeah, they are broken. They should fix it, but it broke someone's Very 
> Important Work at our shop. And it used to work and it works from home and 
> for other customers so it must be our DNS that's broken. So we end up setting 
> "qname-minimization off" globally despite the fact they are really the broken 
> ones. We'd rather keep minimization on, but it's the only reasonable work 
> around we could find.

Just use a forward zone in forward only mode.  When the parent servers give you 
non working nameservers for child zones there isn’t a sensible automatic 
solution.

zone disa.mil {
type forward;
forward only;
forwarders { 152.229.110.235; 214.3.125.231; 131.77.60.235; };
};

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

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742  INTERNET: ma...@isc.org

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