[DNSOP] Re: [Ext] Re: Call for Adoption: draft-davies-internal-tld

[Mark Andrews <[e-mail]>]

> On 2 May 2025, at 02:04, Paul Hoffman <[e-mail]> wrote:
> 
> On Apr 30, 2025, at 17:59, Mark Andrews <[e-mail]> wrote:
>> 
>> 
>> 
>>> On 1 May 2025, at 03:34, Paul Hoffman <[e-mail]> wrote:
>>> 
>>> On Apr 30, 2025, at 10:21, Ted Lemon <[e-mail]> wrote:
>>>> 
>>>> The reason to do an insecure delegation is so that the public dns doesn’t securely deny the existence of the zone. If there is a secure denial of existence, a validating stub resolver will not use responses from the local resolver because they will be bogus.
>>> 
>>> This seems to be talking about a validating stub resolver that is configured to also get answers from a particular recursive resolver, yes?
>>> 
>>> 1) Wouldn't the stub get two conflicting NS records for .internal, one from the root itself and the other from the recursive? All attempts for lookups would have a 50% chance of going to the blackhole nameserver.
>> 
>> No. The delegating NS records in the root zone are NOT signed.  
> 
> The latter is true, but that doesn't explain the "No". If a stub resolver gets an NS record from an authoritative source (in this case, the root zone), and it gets a second NS record from a trusted source (in this case, its configured resolver), why wouldn't it use both of those records? I see nothing in any of the DNS standards that says it should not, but I might be missing something.

Recursive servers don’t merge RRsets.  Stub resolvers don’t merge RRsets and even if they did they don’t make iterative queries.  Also if the recursive server is properly configured to know about a private internal zone it will only return answers from that source for internal names sans the DS query response.

>>> 2) Wouldn't having an insecure delegation in the root prevent the recursive from signing .internal itself because the root responds with an NSEC proving there cannot be a DS?
>> 
>> It doesn’t prevent them signing the stub .internal zone.  It prevents the validator validating as secure responses from .internal.
> 
> Yes, that's better wording. So by having an insecure delegation in the root zone, the validating stub resolver will always see what the resolver has for that zone as insecure.
> 
>> Note there is no point
>> in signing the public .internal instance the same way as we don’t sign the public 10.in-addr.arpa instances.
> 
> That may be your preferred security policy, but others might want to have a policy of signing all records they create. I see nothing in our standards that says that cannot or should not sign zones that they create out of thin air.

Did I say one can’t sign the private copy of .internal?  I said there is no point in signing the PUBLIC version of .internal.  If you want to sign the private copy of .internal and distribute trust anchors for it go ahead.  Note there is no protocol for distributing trust anchors so the BYO devices won’t get DNSSEC validation without manual intervention.

>>> Again, I could be missing something, but it seems that both of those would hurt the validating stub resolver. A validating stub resolver could instead easily be configured with the trust anchor for the recursive resolver it is configured for.
>> 
>> Recursive resolvers don’t have trust anchors.  Domain names have trust anchors.  And no it isn’t easy to setup different trust anchor based on location.  We have no protocol for it.  Devices move between sites.
> 
> A recursive resolver might have a trust anchor for zones that it creates from thin air. "isn't easy" is not the same as "prohibited", and some organizations might want validating stub resolvers to validate all those zones. I understand this is not your security model, but unless we have standards saying that such a model is prohibited, I don't think you should be imposing that on others.

Paul, you said "A validating stub resolver could instead easily be configured with the trust anchor for the recursive resolver it is configured for.”  which I answered.  You seem to be arguing about "A validating stub resolver could instead easily be configured with the trust anchors that the recursive resolver it is using has configured been for.”  That is a different question.  If you have full control over the stub resolver and the recursive server then yes.  If you don’t have full control, as with BYO devices, no.

I don’t know what this has to do with deciding if there should be an insecure delegation for .internal.


> --Paul Hoffman


-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: [phone]              INTERNET: [e-mail]