Re: [DNSOP] Priming query transport selection

Nicholas Weaver <nweaver@ICSI.Berkeley.EDU> Thu, 14 January 2010 16:40 UTC

Return-Path: <nweaver@ICSI.Berkeley.EDU>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 087153A6819 for <>; Thu, 14 Jan 2010 08:40:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.449
X-Spam-Status: No, score=-6.449 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 2sRSaZ62Ieok for <>; Thu, 14 Jan 2010 08:40:21 -0800 (PST)
Received: from fruitcake.ICSI.Berkeley.EDU (fruitcake.ICSI.Berkeley.EDU []) by (Postfix) with ESMTP id 3EBD73A67A3 for <>; Thu, 14 Jan 2010 08:40:21 -0800 (PST)
Received: from [IPv6:::1] (jack.ICSI.Berkeley.EDU []) by fruitcake.ICSI.Berkeley.EDU ( with ESMTP id o0EGeAGs004086; Thu, 14 Jan 2010 08:40:10 -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="iso-8859-1"
Message-Id: <>
Content-Transfer-Encoding: quoted-printable
From: Nicholas Weaver <nweaver@ICSI.Berkeley.EDU>
Date: Thu, 14 Jan 2010 08:40:10 -0800
To: Patrik Fältström <>
X-Mailer: Apple Mail (2.1077)
Cc:,, Nicholas Weaver <nweaver@ICSI.Berkeley.EDU>
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: Thu, 14 Jan 2010 16:40:22 -0000

On Jan 14, 2010, at 7:58 AM, Patrik Fältström wrote:
> Please do not start talking about enforcing some fixed limit that we will laugh about 10 years from now... And if you talk about a limit, pick something very large (like 65535 that seems to be already chosen).
> It is enough problems with the 512 limit of today. I do not want to have the same problems when we pass 4096.
> Implementations should be free to choose an implementation limit smaller if they want to (and signal that in the EDNS0 size), but please do not say that "max value on EDNS0 size will forever be 4096" or something similar.
> Be careful with the wording...

Except that EDNS0 MTU is closely coupled with the UDP protocol and its unreliable nature: this message MTU is irrelevant for TCP or another reliable protocol.

It is highly unlikely that the network's MTU will expand beyond 1500B:  There is too much Ethernet, and >1500B MTUs don't really benefit things anyway, because the overhead reductions of going to a higher MTU are near zero (Amdahl's law).  

Which means the number of fragments which ALL need to be received correctly goes up linearly with the size of the message.

Even WITH a larger MTU, bit-errors become more common.  So, even at a minimum, you'd expect many more failures, dropped packets, etc, with a 40,000B datagram than a 4000B datagram.  And DNS over UDP is already unreliable enough, at least when you consider it all the way to the end host with a reasonable timeout on lookups.

Thus given the nature of the UDP protocol, it is highly unlikely that you'd ever want to do ~10K+ byte UDP datagrams.