Re: [DNSOP] Priming query transport selection

[Jim Reid <[e-mail]>]

On 13 Jan 2010, at 18:19, Olafur Gudmundsson wrote:

> I would like to propose that the document take the plunge of  
> recommending that
> modern DNSSEC capable resolvers perform the priming query over TCP.

I'm not sure it's a good idea to encourage more TCP traffic to the  
root servers or make that the default. It doesn't seem right to oblige  
servers with decent underlying transport that can handle big EDNS0  
payloads to ignore that and use TCP for their priming queries.

How about the following text instead?

Priming queries from DNSSEC-aware resolvers

A DNSSEC-aware priming query will generate a response of at least 5K.  
DNSSEC-aware resolvers making a priming query with EDNS0 SHOULD use a  
minimum buffer size of foo*. If such a priming query fails -- say  
because of fragmentation issues in the underlying network -- a DNSSEC- 
aware resolver SHOULD use TCP. If TCP is refused or times out a  
different server SHOULD be tried. After TCP failures from 3 root  
servers, the resolver SHOULD fall back on UDP and use an EDNS0 buffer  
no larger than bar*. A resolver resorting to UDP/EDNS with a buffer  
size of bar should use that combination for subsequent queries needed  
to fully validate the response to their priming query.

Priming queries from DNSSEC-ignorant resolvers

A resolver that is DNSSEC ignorant but EDNS0 capable SHOULD issue the  
priming query over UDP using ENDS0 and MUST provide a buffer size of  
1220 or larger.  If the UDP query with EDNS0 times out or fails, TCP  
SHOULD be tried.

Priming queries from DNSSEC-ignorant resolvers

An EDNS0 ignorant resolver MUST issue the priming query over UDP.


* The values for foo and bar are open for discussion. Though there  
should be some text to explain whatever values were decided. As a  
straw man, how about 8K for foo and 1220 for bar? As a number plucked  
from the air, 8K should be "big enough" to cope with larger or extra  
signatures, when there's say a rollover of 2048 bit RSA keys under  
way. [I've not done the arithmetic to check if a signed root response  
with 2 such keys will fit in 8K. So shoot me...] For bar, the number  
is even murkier. It needs to be much less than foo (obviously), so  
maybe the payload should be set to that for an unsigned UDP response?