Re: [DNSOP] Priming query transport selection

Alex Bligh <alex@alex.org.uk> Wed, 13 January 2010 20:49 UTC

Return-Path: <alex@alex.org.uk>
X-Original-To: dnsop@core3.amsl.com
Delivered-To: dnsop@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B2B553A6804 for <dnsop@core3.amsl.com>; Wed, 13 Jan 2010 12:49:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XeRAeQFpUmyp for <dnsop@core3.amsl.com>; Wed, 13 Jan 2010 12:49:52 -0800 (PST)
Received: from mail.avalus.com (mail.avalus.com [89.16.176.221]) by core3.amsl.com (Postfix) with ESMTP id D0BDA3A67FC for <dnsop@ietf.org>; Wed, 13 Jan 2010 12:49:51 -0800 (PST)
Received: from [192.168.100.15] (87-194-71-186.bethere.co.uk [87.194.71.186]) by mail.avalus.com (Postfix) with ESMTPSA id 1C683C562F7; Wed, 13 Jan 2010 20:49:47 +0000 (GMT)
Date: Wed, 13 Jan 2010 20:49:47 +0000
From: Alex Bligh <alex@alex.org.uk>
To: Jim Reid <jim@rfc1035.com>
Message-ID: <CDE7E0414BC50C42E4FCC54F@Ximines.local>
In-Reply-To: <631E7931-47D4-4AAF-B2C6-62DA6DA5A4CA@rfc1035.com>
References: <201001131823.o0DINxYv068180@stora.ogud.com> <555CFB98-BB21-4AD4-9D4A-3AF3BD98E4B2@rfc1035.com> <D9CCEA0D18D9D5B457A90853@Ximines.local> <631E7931-47D4-4AAF-B2C6-62DA6DA5A4CA@rfc1035.com>
X-Mailer: Mulberry/4.0.8 (Mac OS X)
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format="flowed"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Cc: dnsop@ietf.org, Alex Bligh <alex@alex.org.uk>
Subject: Re: [DNSOP] Priming query transport selection
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: Alex Bligh <alex@alex.org.uk>
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dnsop>, <mailto:dnsop-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dnsop>
List-Post: <mailto:dnsop@ietf.org>
List-Help: <mailto:dnsop-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsop>, <mailto:dnsop-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 13 Jan 2010 20:49:52 -0000

--On 13 January 2010 20:34:49 +0000 Jim Reid <jim@rfc1035.com> wrote:

>>> An EDNS0 ignorant resolver MUST issue the priming query over UDP.
>>
>> I presume you mean DNSSEC ignorant.
>
> That's implicit. The language was in Olafur's original text BTW...
>
> If a resolver doesn't speak EDNS0, it can't set the DO bit. Which means
> the authoritative server isn't supposed to send back DNSSEC-related RRs.
> Unless the resolver explicitly queries for those RRtypes. Which seems
> unlikely, particularly in the context of a priming query. It would be
> very odd for a DNS implementation to be DNSSEC-aware and not support
> EDNS0. Then again, the DNS is full of all sorts of weirdness and bizarre
> implementations.

I understand DNSSEC support implies EDNS0 support. What I meant was
that if the rationale for using TCP is merely that a large
packet won't fit into a normal EDNS0 window, and that
otherwise TCP is a bad thing as it creates server load, then
we should apply the injunction to use UDP (or more accurately
not use TCP) to any scenario where we know that large packet
isn't going to arrive. Current operational practice would
result in DO clear packets fitting within 4096 bytes,
so no need for TCP when DO is clear.

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.

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.

-- 
Alex Bligh