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]
