Re: [DNSOP] Priming query transport selection

Nicholas Weaver <nweaver@ICSI.Berkeley.EDU> Wed, 13 January 2010 23:16 UTC

Return-Path: <nweaver@ICSI.Berkeley.EDU>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 4FBCD3A68E6 for <>; Wed, 13 Jan 2010 15:16:58 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id m4ISfZ2+jw2l for <>; Wed, 13 Jan 2010 15:16:57 -0800 (PST)
Received: from fruitcake.ICSI.Berkeley.EDU (fruitcake.ICSI.Berkeley.EDU []) by (Postfix) with ESMTP id 3C0483A688B for <>; Wed, 13 Jan 2010 15:16:57 -0800 (PST)
Received: from [IPv6:::1] (jack.ICSI.Berkeley.EDU []) by fruitcake.ICSI.Berkeley.EDU ( with ESMTP id o0DNGpvU025745; Wed, 13 Jan 2010 15:16:52 -0800 (PST)
References: <> <> <D9CCEA0D18D9D5B457A90853@Ximines.local> <> <CDE7E0414BC50C42E4FCC54F@Ximines.local> <> <>
In-Reply-To: <>
Mime-Version: 1.0 (Apple Message framework v1077)
Content-Type: text/plain; charset="us-ascii"
Message-Id: <>
Content-Transfer-Encoding: quoted-printable
From: Nicholas Weaver <nweaver@ICSI.Berkeley.EDU>
Date: Wed, 13 Jan 2010 15:16:51 -0800
To: Olafur Gudmundsson <>
X-Mailer: Apple Mail (2.1077)
Cc: Nicholas Weaver <nweaver@ICSI.Berkeley.EDU>,, Alex Bligh <>
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 23:16:58 -0000

On Jan 13, 2010, at 2:41 PM, Olafur Gudmundsson wrote:

> At 16:16 13/01/2010, Jim Reid 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.
> EDNS0 RFC restricts EDNS0 to 4096 bytes, number of implementations
> will not send more even if client ask for it. Firewalls will
> enforce this.

We should have some additional numbers for this with the new run (we just released an updated version of Netalyzr, )  Among the new tests is a detailed check for actual DNS MTU rather than advertised DNS MTU.

Basically, you can't RELY on UDP packets over 1500B being received by DNS resolvers when requested, but it works a large amount of the time.

So basically, I'd have the model of "Try at EDNS4000, fallback to EDNS1280, fallback to TCP", and cache whether the resolver needs to do this for all authorities (because its side is fragment-broken) or just particular remote authorities.