Duane, At 2016-01-26 22:32:45 +0000 "Wessels, Duane" <[email protected]> wrote:
> > On Jan 23, 2016, at 2:25 PM, Matthäus Wander <[email protected]> > > wrote: > > > > > > There's another issue: once root-servers.net is signed, the priming > > response will contain RRSIG in the ADDITIONAL section. > > Indeed. According to my simple test if root-servers.net is signed (the > same way as the root zone), the response size jumps quite a bit: > > > EDNS0? UDPsize DO= RSN signed? resp size > ------ ------- --- ----------- --------- > n - - n 492-512 > y 4096 0 n 755 > y 4096 1 n 913 > y 8192 1 y 4081 > > And these sizes could increase if two remaining letters decide to add AAAA > records. This means that the section talking about the EDNS reassembly size could become outdated: The recursive resolver SHOULD use EDNS0 [RFC6891] for priming queries and SHOULD announce and handle a reassembly size of at least 1024 octets [RFC3226]. Doing so allows responses that cover the size of a full priming response (see Section 4.2). I guess a new RFC can be rolled if root-servers.net is signed, but we could just future-proof it now and recommend a larger size? Of course, if the result is larger than 4096 - the most common value for EDNS right now IIRC - then maybe we should just start recommending TCP right away? (My colleague Davey Song actually has an expired draft saying just that - draft-song-dnsop-tcp-primingexchange - but I think that a single sentence in the priming draft saying something like "if the DO bit is set, then TCP SHOULD be used, since a UDP response may be truncated" is enough). Personally I think TCP for root priming makes complete sense, since root priming traffic is a small fraction of a percent of both root server traffic and resolver queries. (In fact this is a subset of the general set of queries where "if you expect truncation, just start with TCP". That's a possibly useful optimization that probably nobody has bothered with because truncation is very rare.) Cheers, -- Shane _______________________________________________ DNSOP mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsop
