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.
On Thu, May 1, 2025, at 1:55 PM, Paul Hoffman wrote: > On May 1, 2025, at 10:32, Ted Lemon <mel...@fugue.com> wrote: > > > > On Thu, May 1, 2025, at 12:07 PM, Paul Hoffman wrote: > >> > >> > >> On Apr 30, 2025, at 18:25, Ted Lemon <mel...@fugue.com> wrote: > >> > > >> > The local resolver can safely lie about the delegation, so unless the > >> > stub resolver queries the root directly this isn’t an issue. > >> > >> A validating stub resolver would indeed query the root to create the chain > >> of trust. That's the whole point of *validating* stub resolvers. > > > > > > The stub resolver queries the chain of trust, but why would it send a > > packet to a root server? > > It could ask the configured recursive for the chain-building data, but it is > more reliable to ask the source zone. > > > Is that what we want it to do? > > Unless we have specified otherwise (and I don't think we have for validating > stub resolvers), what we want is irrelevant. > > > Normally I would expect it to query the local network resolver and then > > validate. I think that’s what our implementation does unless DoH is > > configured. Is yours different? > > In the cases discussed here (the recursive has a record at foo.internal, and > either .internal is missing from the root zone or has an insecure delegation > in the root zone), how does your implementation help the validating stub > resolver build the chain of trust? And what happens if "DoH is configured"? > > > I’m under the impression that no delegation at the root means the > > delegation can be proven not to exist. Am I mistaken? > > You are not mistaken: there is no NSEC record for .internal (but there is for > .int and .international). > > >> > But this isn’t generally necessary. If you’re doing DNSSEC the only > >> > reason not to trust the local resolver is if it doesn’t give enough > >> > answers to construct the proofs. > >> > >> You may feel that way, but that's not the model adopted by the DNSSEC > >> standards. > > > > > > Again not my understanding of how existing validating stub resolvers work, > > but I’m curious to know what your experience with this is. My sample is one > > at the moment—the one in Apple’s operating systems. > > > > See my question above. The IETF has given no guidance for how a validating > stub resolver should be configured, and yet that is quite important for this > discussion. > > --Paul Hoffman > >
_______________________________________________ DNSOP mailing list -- dnsop@ietf.org To unsubscribe send an email to dnsop-le...@ietf.org
