Hello.
If the parent zone also implements authenticated encryption, this provides sufficient protection for the glue records, but many important parent zones seem unlikely to implement authenticated encryption in the near future.
I'm not very convinced about the motivation so far. Let me look top-down in the tree.
1: the root seems unlikely to support encryption, but we already do have ways of serving/prefetching the whole root zone locally including all glue, which is superior also in other respects like leaking random typos (and it's standardized and implemented). So far the best security for root glue in there is https with web PKI, I think, but that's not so bad for privacy and ZONEMD is supposed to get deployed in there soon, resulting in DNSSEC-secure glue. ZONEMD is standardized as well, and implementations are coming around already.
2: communication to TLD servers. I believe we have very privacy-interesting data in QNAMEs there already, arguably even the most sensitive parts. That seems unavoidable, unless sensitive services want to move, e.g. grouped into specialized SLDs, and there will hopefully be the alternative of moving into supporting TLDs. And if a TLD offers encrypted service, I can't see much use for the proposed DSGLUE, as we got assurance because of the QNAMEs already.
DSGLUE sure is way easier to implement and operate than encrypted authoritative DNS, but I'd really hope that we can skip this step and get (some) encrypted TLDs.
Note that proxying and forwarding cases won't suffer from this either. They don't communicate with auths directly, so they don't need any of the glue information. They have to rely with this privacy aspect on the final layer talking to auths.
--Vladimir | knot-resolver.cz _______________________________________________ dns-privacy mailing list [email protected] https://www.ietf.org/mailman/listinfo/dns-privacy
