This is why I mentioned locally-served domains. This is territory we’ve already been over many times. In order for .internal to be used, the resolver has to know that it is not globally unique, which means it should be in the locally-served domains registry. Like eg 1.168.172.on-address.arpa or home.arpa.
On Wed, Apr 30, 2025, at 9:55 PM, John Levine wrote: > It appears that Ted Lemon <[email protected]> said: > >-=-=-=-=-=- > > > >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. > > If you're using DoH to bypass the local resolver, you're not going to see > .internal at all. If you're using it to talk to the local resolver > you will presumably get the same asnswers as Do53 or DoT. I still see an > awful lot of assumptions about what resolvers might or might not > do. > > R's, > John > > > > > >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 <[email protected]> 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 -- [email protected] > To unsubscribe send an email to [email protected] >
_______________________________________________ DNSOP mailing list -- [email protected] To unsubscribe send an email to [email protected]
