Er, I should add that since using DoH is pretty common, if .internal isn’t listed in the locally-served domains registry its subdomains probably will indeed show up as nxdomain.
On Wed, Apr 30, 2025, at 9:25 PM, Ted Lemon wrote: > The local resolver can safely lie about the delegation, so unless the stub > resolver queries the root directly this isn’t an issue. Even if it does, > unless it uses DoH, the edge router can intercept the query. 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. > > On Wed, Apr 30, 2025, at 1:34 PM, Paul Hoffman wrote: >> On Apr 30, 2025, at 10:21, Ted Lemon <mel...@fugue.com> 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. >> >> 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? >> >> 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. >> >> --Paul Hoffman >> >> > > _______________________________________________ > DNSOP mailing list -- dnsop@ietf.org > To unsubscribe send an email to dnsop-le...@ietf.org >
_______________________________________________ DNSOP mailing list -- dnsop@ietf.org To unsubscribe send an email to dnsop-le...@ietf.org
