Danny Mayer wrote, in a response sent to me, referring to Olafur Gudmundsson's text proposal quoted in my posting on Jan 13:
>>> Proposed replacement text: >>> >>> |2.1. Parameters of a Priming Query >>> | >>> | A priming query MUST use a QNAME of "." and a QTYPE of NS, QCLASS >>> | of IN, with RD bit set to 0, the source port of the query should >>> | be randomly selected [RFC5452]. >>> | >>> | A DNSSEC aware resolver SHOULD sent the priming query over TCP. >>> | If TCP is refused a different server SHOULD be tried, after 3 tries >>> | the resolver SHOULD fall back on UDP. >>> | >>> | A DNSSEC ignorant but EDNS0 capable, resolver SHOULD issue the >>> | priming query over UDP, ENDS0 option MUST be included with buffer >>> | size of 1220 or larger. If the UDP query times out TCP SHOULD be >>> | tried. >>> | >>> | An EDNS0 ignorant resolver MUST issue the priming query over UDP. >>> >>> ... > > I'm not sure I understand the point to this part. Since this is a draft > and you would be talking about the next versions of resolvers that would > be expect to support this (as opposed to existing ones) why would you > expect there to be any future resolver ignorant of DNSSEC? Aren't we > trying to make DNSSEC mandatory for future resolvers? > > Danny Danny, Please note that the quoted block of text wasn't mine, so maybe your message ought to have be addressed primarily to its author. But never mind. It has arrived there and on the lists. The primary goals of my posting were to point out that: - limiting the recommended priming query discussion and advice in teh Priming Query draft by a perspective on 1024-bit RSA keys and signatures is too narrow-headed if the advice shall last for more than a very small couple of years, and - with respect to message size issues and efficiency, DNSEXT should resume work on ECC keys and signatures for DNSSEC ASAP. Regarding your argument agaibst Olafur's suggested text, I fear there will be lots of resolvers for many years that cannot reasonably be expected to be DNSSEC aware, i.e. performing DNSSEC validation. I do not want to touch on policy issues -- whether CPE and end systems are in a better place for providing useful trust by performing DNSSEC validation than typical large-scale caching resolvers provided and maintained by ISPs. However: DNSSEC is a huge code addition, in particular for embedded TCP/IP implementations; the proliferation of signature algorithms we are starting to admit will make things even more complicated. In contrast, EDNS0 is a rather tiny addition providing general utility and it indeed really should be supported by such implementations. Therefore, I believe that we should give valid advice for such small-scale implementions as well -- they'll depend on working priming queries in any case. As pointed out by other folks in another current thread on DNSOP, BCP documents should not restrict the advice they are giving to a single mainstream scenario when the topic is more general in nature, but better cover various important scenarios. Thus, I indeed recommend to keep appropriate advice for DNSSEC unaware resolvers in the Priming Query draft. Kind regards, Alfred. -- +------------------------+--------------------------------------------+ | TR-Sys Alfred Hoenes | Alfred Hoenes Dipl.-Math., Dipl.-Phys. | | Gerlinger Strasse 12 | Phone: (+49)7156/9635-0, Fax: -18 | | D-71254 Ditzingen | E-Mail: a...@tr-sys.de | +------------------------+--------------------------------------------+ _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop