On Mon, Sep 20, 2021 at 10:53 AM Vladimír Čunát <[email protected]> wrote:
> 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 I agree: local root (plus ZONEMD) is sufficient to authenticate root glue. 2: communication to TLD servers. I believe we have very > privacy-interesting data in QNAMEs there already, arguably even the most > sensitive parts. In general, I agree. However, there are some cases where the lower labels are more sensitive (e.g. tumblr.com). ... > 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. > There are two key reasons for DSGLUE: authentication and RR type flexibility. In this model, it's not enough to secure the existing glue RR types; we also need to convey the nameserver's ADoT configuration during (in-bailiwick) delegation. There seem to be many participants in the WG who believe that getting new glue RR types into parent zones (and especially TLDs) is a very distant prospect. 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. > Yes, I think we will get *some*, but I think it will be a very long time before we get *most*. Having an intermediate solution to protect lower labels during that transition seems worthwhile to me.
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ dns-privacy mailing list [email protected] https://www.ietf.org/mailman/listinfo/dns-privacy
