Dear colleagues, Despite the speed with which I went through the dns64 issue, there is in fact something in this that could really do with some attention. Again, this isn't a WG document and really needs to be discussed in behave, but I'll make a more detailed plea here now that you all heard me talking really fast saying something.
Suppose that we have a security-aware, non-validating stub behind a translator. On query it sets DO and does not set CD. The translator is a validating, recursive resolver that also performs the translation function (a "translating validator", for short). The general principle is that we MUST validate before translation. So, the translating validator queries for the AAAA record, doesn't get one, queries for the A record, and gets one with all the DNSSEC data necessary for validation. The translating validator successfully validates the A record. Now, it translates. To perform the translation, it moves the A record to the additional section, strips off all the RRSIG and other DNSSEC-relevant data, synthesizes the AAAA record to match the A record, and sets the AD bit. It then ships the resulting response to the stub. The question is whether that's broken in such a way that it will break any clients. In particular, are there clients that will get heartburn if AD is set on a response when there's otherwise apparently no security data in the response? For background, the extant -02 draft doesn't do it as outlined above. It said instead that the translating validator MUST NOT set the AD bit, because the answer being returned isn't actually validatable. The counter-argument, raised by Dave Thaler, is that RFC 4035 allows the validator to set AD if it knows it can trust the answer (and of course, the validator can know that: it validated the response from the DNS, and it knows the prefix it is using). In addition, Dave reports that there is an implementation that uses the AD bit, in a secure-last-hop context, as a boolean security flag such that applications can make different decisions based on whether AD was set. So he has a use case that he wants supported. Any feedback welcome. As I said at the mic, discussion is really going on in behave; I'll happily take direct feedback as well. Thanks for your time today. A -- Andrew Sullivan a...@shinkuro.com Shinkuro, Inc. _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
