Ben, [responses inline - sorry for the vacation-induced late reply!]
On Thu, Aug 19, 2021 at 7:14 PM Ben Schwartz <[email protected]> wrote: > > Thanks for the review, Alex. I've just released a new revision that > addresses some of your comments: > > https://datatracker.ietf.org/doc/html/draft-schwartz-ds-glue-02 > > The main change in this revision is the removal of the NSEC approach to > authenticated nonexistence. This proved too complicated for me to get right > in the examples, and implementers told me that it would not be easy to > implement, as I had hoped. Instead, draft-02 encodes each RRSet as a unit, > and authenticates nonexistence by encoding an empty RRSet. I can't speak as an implementor, but looks good (and logical) to me! > > I don't think we can avoid placing NS records in DSGLUE. Authenticating the > NS records is crucial for both out-of-bailiwick and in-bailiwick delegations. > True. You do mention in the draft that if the parent allowed for authenticated encryption, so - in theory - plain glue from such servers should have similar trust properties as DS-GLUE NS RRSets. However, implementing that additional state (potentially per RRset) might be too complex on the resolver side.. My gut feeling tells me we're introducing new failure modes somewhere here, so that's where my caution came from initially. The text in the "Interpretation" section is very clear, though, and i can't name a problematic case right now (cyclically dependent NS records, maybe?). Hmm, maybe one: Assume AAAA records for a nameserver are authenticated (from DS-GLUE), A records are not. Resolver prefers DS-GLUE sourced records, attempts to contact auth server via AAAA address(es), queries time out. Resolver could now (a) indicate to client that authenticated glue is exhausted (SERVFAIL?), (b) attempt to contact the auth server via unauthenticated A records. It could also fall back to the "normal" delegation response initially received? So, as always, the "success case" is pretty straightforward, while the "failure cases" might be full of painful obstacles (and require most of the discussion time). >> >> It's cool to >> have a generic mechanism to convey arbitrary records, but once those >> records overlap with a "legacy deployment", we need to be very very >> careful about the interactions between those two channels (eg. domain >> name owners expecting they can safely remove the NS records from the >> registry, because they supply those records in DS-GLUE already). I >> think there should be some text in the draft about this in future >> revisions. > > OK, I've added that text here: > https://datatracker.ietf.org/doc/html/draft-schwartz-ds-glue-02#section-6.1 Perfect. Concise and to the point. >> Maybe we should even restrict DS-GLUE to a set of >> pre-defined use cases.> > > draft-02 now does this, by opening a registry of allowed RR types. As we > reach an understanding of how to interpret other RR types in DS Glue, we can > add them to the registry. Sounds good to me. I know that IANA has lots of "idle" registries (which never get updated), so we could also go for the option of listing the allowed RR Types in the document itself, and wait for a future extension of the protocol to UPDATE the base spec (by adding new records), and eventually creating an IANA registry. But i guess that's a decision between IANA and the AD.. best, Alex _______________________________________________ dns-privacy mailing list [email protected] https://www.ietf.org/mailman/listinfo/dns-privacy
