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? Is that what we want it to do? 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? > > > Even if it does, unless it uses DoH, the edge router can intercept the > > query. > > The IETF does not promote "edge router can intercept the query". :-) Further, > even in that scenario, then there is no reason for an insecure delegation: no > delegation works fine. Of course not. The IETF also doesn’t promote .internal. I’m under the impression that no delegation at the root means the delegation can be proven not to exist. Am I mistaken? > > 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.
_______________________________________________ DNSOP mailing list -- dnsop@ietf.org To unsubscribe send an email to dnsop-le...@ietf.org
