On Fri, Aug 27, 2021 at 9:25 AM Alexander Mayrhofer < [email protected]> wrote: ...
> I can't speak as an implementor, but looks good (and logical) to me! > Thanks! ... > 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? > I think the interpretation section covers this: the AAAA DS-GLUE replaces any colliding AAAA glue, and then delegation following proceeds as usual. The resolver is not instructed to change its behavior based on whether the A or AAAA glue records were authenticated. I think this is your option "b". If you want behavior "a", you have to do the thing shown in https://datatracker.ietf.org/doc/html/draft-schwartz-ds-glue-02#section-4.3.
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ dns-privacy mailing list [email protected] https://www.ietf.org/mailman/listinfo/dns-privacy
