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

[Shane Kerr <[e-mail]>]

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.)

Cheers,

--
Shane