Re: [DNSOP] Priming query transport selection

Jim Reid <> Wed, 13 January 2010 21:16 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 83A253A683C for <>; Wed, 13 Jan 2010 13:16:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.974
X-Spam-Status: No, score=-2.974 tagged_above=-999 required=5 tests=[AWL=-0.975, BAYES_00=-2.599, J_CHICKENPOX_35=0.6]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id shJMJLrXcYNj for <>; Wed, 13 Jan 2010 13:16:54 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 8D17F3A67FA for <>; Wed, 13 Jan 2010 13:16:54 -0800 (PST)
Received: from ( []) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: jim) by (Postfix) with ESMTPSA id 104F2154283B; Wed, 13 Jan 2010 21:16:50 +0000 (GMT)
Message-Id: <>
From: Jim Reid <>
To: Alex Bligh <>
In-Reply-To: <CDE7E0414BC50C42E4FCC54F@Ximines.local>
Content-Type: text/plain; charset="US-ASCII"; format="flowed"; delsp="yes"
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v936)
Date: Wed, 13 Jan 2010 21:16:49 +0000
References: <> <> <D9CCEA0D18D9D5B457A90853@Ximines.local> <> <CDE7E0414BC50C42E4FCC54F@Ximines.local>
X-Mailer: Apple Mail (2.936)
Subject: Re: [DNSOP] Priming query transport selection
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IETF DNSOP WG mailing list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 13 Jan 2010 21:16:55 -0000

On 13 Jan 2010, at 20:49, Alex Bligh wrote:

> Current operational practice would result in DO clear packets  
> fitting within 4096 bytes, so no need for TCP when DO is clear.

I don't think that's always the case Alex. See the lengthy discussion  
in this list about datagram fragmentation and broken middleware boxes  
that don't grok EDNS0. [Or do EDNS0 with a 512 byte buffer size.  
Sigh.] Mind you, some of those boxes will also barf on TCP DNS traffic.

> I thought it might be an error as the section title in your
> proposed text doesn't match the section text, but that's
> actually because two section titles are the same which
> I think is the problem.

Indeed: a stupid cut&paste error. Sorry.

> Thinking about it, a total prohibition (at MUST level) of using TCP
> is probably a bit harsh given we don't even know they have UDP
> connectivity. Perhaps "MUST issue the priming query *first*
> over UDP", or use a SHOULD.

SHOULD is more appropriate than a MUST IMO. If the resolver has a  
priori knowledge that UDP/EDNS0 will fail for some reason, forcing  
them to do that and then revert to TCP or whatever would be a Bad Thing.

The preferred approach might probably be along these lines:
	[1] EDNS0 + DO with a buffer of 5-8K (ish)
	[2] TCP + DO when [1] fails
	[3] EDNS0 + DO + 1.5K (ish) buffer if [2] fails
	[4] EDNS0 (no DO) with a 1.5K (ish) buffer
	[5] Vanilla UDP (no EDNS0) if [4] fails

I think it would be helpful if the guidance on priming queries was  
split into 3 categories: resolvers that speak DNSSEC, those that are  
not DNSSEC-aware but speak EDNS0 and resolvers that are ignorant of  
both protocols. They'd start at [1], [4] and [5] respectively in the  
scenario above. The optimal priming behaviour for each may well be  
different, particularly wrt EDNS0 buffer minima and maxima. It would  
be good to give an explanation for those buffer sizes too in case  
we've all forgotten about that when revisiting the issue 5-10 years  
from now.

Perhaps the recommended resolver behaviour should apply to all queries  
and not just the priming query?