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

[Ted Lemon <[e-mail]>]

Okay, but if they are not going to the authoritative  servers to get the chain of trust, they are going to the local full-service resolver or some public third-party resolver. And so if there is an insecure delegation, that resolver can make up an answer, and it will “validate” correctly as insecure. But if the delegation is securely denied, that can’t happen. That’s why it’s important for there to be an insecure delegation to a black hole name server. 

On Thu, May 1, 2025, at 5:05 PM, Joe Abley wrote:
> On 1 May 2025, at 22:57, Ted Lemon <[e-mail]> wrote:
> 
> > If validating stubresolvers all go to the root, we get no benefit from caching. That seems bad if at some point they become commonplace, although of course it’s fine now. 
> 
> I think validating stub resolvers need to go to the root in a namespace sense. They need to retrieve sufficient generations of parental data to be able to validate an RRSet attached to a child. This data might well be cached at a node in the resolver graph close to the stub. 
> 
> I don't think validating stub resolvers need to send queries to root servers.
> 
> I think we are overloading the word "root" and the result is some mild confusion.
> 
> 
> Joe