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 <mel...@fugue.com> 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
_______________________________________________ DNSOP mailing list -- dnsop@ietf.org To unsubscribe send an email to dnsop-le...@ietf.org
