Re: [DNSOP] Priming query transport selection
Alex Bligh <alex@alex.org.uk> Wed, 13 January 2010 21:35 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 CF0373A6842 for <dnsop@core3.amsl.com>; Wed, 13 Jan 2010 13:35:55 -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=[AWL=0.000, 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 XWGykv22yZjz for <dnsop@core3.amsl.com>; Wed, 13 Jan 2010 13:35:54 -0800 (PST)
Received: from mail.avalus.com (mail.avalus.com [89.16.176.221]) by core3.amsl.com (Postfix) with ESMTP id C7EA43A6840 for <dnsop@ietf.org>; Wed, 13 Jan 2010 13:35:53 -0800 (PST)
Received: from [10.40.215.19] (87-194-71-186.bethere.co.uk [87.194.71.186]) by mail.avalus.com (Postfix) with ESMTPSA id 50322C562AB; Wed, 13 Jan 2010 21:35:50 +0000 (GMT)
Date: Wed, 13 Jan 2010 21:35:48 +0000
From: Alex Bligh <alex@alex.org.uk>
To: Jim Reid <jim@rfc1035.com>
Message-ID: <074C291445D8E2F871990FD2@nimrod.local>
In-Reply-To: <E87EE584-97B5-4FE8-B47D-21048A702B51@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> <CDE7E0414BC50C42E4FCC54F@Ximines.local> <E87EE584-97B5-4FE8-B47D-21048A702B51@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 21:35:55 -0000
--On 13 January 2010 21:16:49 +0000 Jim Reid <jim@rfc1035.com> wrote: > 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. Indeed - my slack language. I meant that UDP should at least be given a go as we don't know a priori that it will fail. We pretty much do know that for a DO set query. > 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. You've eliminated TCP fallback for non-DNSSEC supporting clients. On e.g. small MTU dialup, (4) will not succeed in certain circumstances (i.e. where fragments are not transmitted correctly). I think here you are relying on [5] to work, but it seems to me reasonable for a well behaved (but not DNSSEC supporting) client to make a TCP query if UDP doesn't get through for whatever reason. > Perhaps the recommended resolver behaviour should apply to all queries > and not just the priming query? This is somewhat swimming against the tide of (e.g.) draft-ietf-dnsext-dns-tcp-requirements and draft-bellis-dns-recursive-discovery (unadopted, disclosure: am coauthor), which each take the view that there's enough middlebox and fragmentation breakage of UDP that TCP should be available as a reliable fallback. Sure, clients should as a general rule try getting UDP to work, but I think preventing them falling back to UDP unless they are prepared to take the overhead of adding DO set is not right. It might have the perverse effect of encouraging people to set DO unnecessarily. -- Alex Bligh
- [DNSOP] Priming query transport selection Olafur Gudmundsson
- Re: [DNSOP] Priming query transport selection Jim Reid
- Re: [DNSOP] Priming query transport selection Alex Bligh
- Re: [DNSOP] Priming query transport selection Alex Bligh
- Re: [DNSOP] Priming query transport selection Jim Reid
- Re: [DNSOP] Priming query transport selection Alex Bligh
- Re: [DNSOP] Priming query transport selection Alfred Hönes
- Re: [DNSOP] Priming query transport selection Jim Reid
- Re: [DNSOP] Priming query transport selection Olafur Gudmundsson
- Re: [DNSOP] Priming query transport selection Alex Bligh
- Re: [DNSOP] Priming query transport selection Edward Lewis
- Re: [DNSOP] Priming query transport selection Alex Bligh
- Re: [DNSOP] Priming query transport selection Jim Reid
- Re: [DNSOP] Priming query transport selection Olafur Gudmundsson
- Re: [DNSOP] Priming query transport selection Jaap Akkerhuis
- Re: [DNSOP] Priming query transport selection Olafur Gudmundsson
- Re: [DNSOP] Priming query transport selection Jaap Akkerhuis
- Re: [DNSOP] Priming query transport selection Nicholas Weaver
- Re: [DNSOP] Priming query transport selection Ray.Bellis
- [DNSOP] RSA cracking Jim Reid
- Re: [DNSOP] Priming query transport selection Patrik Fältström
- Re: [DNSOP] Priming query transport selection bmanning
- Re: [DNSOP] Priming query transport selection Nicholas Weaver
- Re: [DNSOP] Priming query transport selection Patrik Fältström
- Re: [DNSOP] Priming query transport selection Sebastian Castro
- Re: [DNSOP] Priming query transport selection Ray.Bellis
- Re: [DNSOP] Priming query transport selection Simon Leinen
- Re: [DNSOP] Priming query transport selection Florian Weimer
- Re: [DNSOP] Priming query transport selection Jim Reid
- Re: [DNSOP] Priming query transport selection Florian Weimer
- Re: [DNSOP] Priming query transport selection George Barwood
- Re: [DNSOP] Priming query transport selection George Barwood
- [DNSOP] signing glue and additional data Jim Reid
- Re: [DNSOP] signing glue and additional data George Barwood
- Re: [DNSOP] Priming query transport selection Sebastian Castro
- [DNSOP] on what glue is (was: signing glue and ad… Andrew Sullivan
- Re: [DNSOP] on what glue is (was: signing glue an… Roy Arends
- Re: [DNSOP] [dnsext] Re: Priming query transport … Danny Mayer
- Re: [DNSOP] [dnsext] Re: Priming query transport … Alfred Hönes
- Re: [DNSOP] [dnsext] Re: Priming query transport … Olafur Gudmundsson