Re: [DNSOP] DNSSEC in draft-ietf-dnsop-resolver-priming

["Wessels, Duane" <[e-mail]>]

> On Feb 18, 2016, at 3:06 AM, Shane Kerr <[e-mail]> wrote:
> 
> Duane,
> 
> At 2016-01-26 22:32:45 +0000
> "Wessels, Duane" <[e-mail]> wrote:
> 
>>> On Jan 23, 2016, at 2:25 PM, Matthäus Wander <[e-mail]> 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.)


I took a look at some data to see if priming queries truly are a small
fraction.  From what I see, about 3.5 to 4.0% of root server traffic is
priming queries.  I have a "second opinion" analysis running at DNS-OARC
but that is taking longer, so if it indicates anything different I'll
follow up.

I guess I'm a little hesitant here because in an earlier discussion on this
document we talked about saying "resolvers SHOULD send DO when priming"
and if we add "SHOULD use TCP when DO is set" then TCP sort of becomes
the default for all priming queries.  Unless and until the root-servers.net
zone is signed, the priming response doesn't really need TCP because it can
entirely fit in an unfragmented UDP packet.

DW