On Jun 18, 2020, at 12:10 PM, Joe Abley <jab...@hopcount.ca> wrote: > > [As an aside, I have some concerns about RFC 8375 and I wish I was paying > more attention at the time it was discussed. Although I can understand some > of the technical arguments for the delegation, I'm not especially convinced > by them in practice, and the decision to make the unsigned delegation also a > *lame* unsigned delegation whilst simultaneously directing all leaked queries > with potential information about private networks to be sent to nameservers > that by design are intended to have anonymous operators is a poor one, I > think. I note that the security considerations section doesn't even address > the potential for information leakage.]
Ouch. That’s a depressing observation. I’m can’t think of a way to completely mitigate this risk, however, unfortunately. Any mitigation requires new code on the edge router for the provisioning domain in which the locally-served domain is being used. >> Also, what do you think the operational effect of this will be? Given that >> these domains are currently provably nonexistent, this means that a resolver >> looking up names in these domains will have to special-case them. > > I suspect it will work like every other locally-served domain or every other > private namespace that exists today, i.e. just fine with no configuration > changes expected or required on dependent (downstream) DNS clients. And if > there are new species of resolver that need to be accommodated (e.g. > validating, hybrid stub/full service resolvers embedded in applications), > whatever configuration or auto-discovery mechanisms are required to support > those other locally-served zones can surely be easily extended to these > ISO-3166-2 codes if they are used in any particular private network. What I’m getting at is that the secure denial of existence will mean that a DNSSEC-aware resolver, when asked to look up a name under ..xa, for example, will always return NXDOMAIN. > This draft describes an existing consequence of existing policy. It may be > that Ed and Roy are the first ones to think about using them to anchor > private namespaces, but in some sense any corner cases that need special > handling today also needed special handling before this draft was written; we > just didn't know it yet. I suspect that a discussion of the DNSSEC issue is in-scope. :)
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
