Alfred HÎnes wrote: > I apologize for cross-posting due to topical overlap. > Please confine follow-up messages to the appropriate list. > > > In the message to DNSOP regarding draft-ietf-dnsop-resolver-priming-02 > archived at > <http://www.IETF.ORG/mail-archive/web/dnsop/current/msg07843.html>, > Olafur Gudmundsson scratched at a topic of interest to namedroppers > as well; he wrote: > >> ... >> >> Background: >> 26 signed glue records will require about 5K answer if each RRSet is >> signed by a single 1024 bit RSA key. >> This will never fit into an ENDS0 answer as number of implementations >> have 4096 byte hard limit on answer size. > > > Did you read the News these days? > > An international team lead by the BSI (the "German NSA") and others > has solved the RSA-768 challenge, and experts reportedly expect, due > to significant progresses, that RSA-1024 will be solved in a rather > short time, likely by the end of this year or so! > > This means that we should immediately plan operationally for > widespread use of 2048-bit RSA keys in the "near" future. > > >> As of today all the root servers instances that my host reached >> answered a TCP query. >> >> 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 _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
