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

[Paul Hoffman <[e-mail]>]

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.

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

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