Re: [DNSOP] I-D Action: draft-ietf-dnsop-avoid-fragmentation-01.txt

Tony Finch <> Thu, 30 July 2020 23:23 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 62A233A124B for <>; Thu, 30 Jul 2020 16:23:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.918
X-Spam-Status: No, score=-1.918 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Bmk3ibp0GJKN for <>; Thu, 30 Jul 2020 16:23:30 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 9CD703A1265 for <>; Thu, 30 Jul 2020 16:23:30 -0700 (PDT)
X-Cam-AntiVirus: no malware found
Received: from ([]:38716) by ( []:25) with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) id 1k1HtX-0002Ju-0w (Exim 4.92.3) (return-path <>); Fri, 31 Jul 2020 00:23:27 +0100
Date: Fri, 31 Jul 2020 00:23:27 +0100
From: Tony Finch <>
To: Paul Vixie <>
In-Reply-To: <1894748.tN5slbBgEf@linux-9daj>
Message-ID: <>
References: <> <1894748.tN5slbBgEf@linux-9daj>
User-Agent: Alpine 2.20 (DEB 67 2015-01-07)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Archived-At: <>
Subject: Re: [DNSOP] I-D Action: draft-ietf-dnsop-avoid-fragmentation-01.txt
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF DNSOP WG mailing list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 30 Jul 2020 23:23:33 -0000

I've had a look through and I have a few comments.

Regarding smallest MTUs, I understand from Geoff Huston that it's common
for IPv6 breakage to start at 1281 bytes.

I would find it easier to understand the recommendations if the
requirements for responder and requester were separated. In particular I
don't know how a responder can do MTU discovery (though a simplified
version might be possible).

Here's my understanding of your recommendations:


* should have a default EDNS buffer size no more than 1500 bytes (smaller
  than the 4096 that is currently typical, but bigger than the flag day

* should probe to discover the real MTU per destination, which can be less
  than the default, and use the discovered MTU for the EDNS buffer size in
  queries (resolvers already do this)

* at the moment UDP timeouts don't cause fallback to TCP, but this should
  be added to the list of recovery tactics

* requesters are supposed to guess (how?) the size of response before
  sending a query, so that they can skip UDP and go straight to TCP

* should set the DONTFRAG option, though it's unlikely they are sending
  a query big enough for this to matter. (UPDATE clients need to care,


* should have a default UDP response size limit of no more than 1500 bytes
  (smaller than the 4096 that is currently typical, but bigger than the
  flag day recommendation)

* should limit response sizes by based on the minimum of the request's
  EDNS buffer size and the server's limit (servers already do this)

* should use minimal responses

* should set the DONTFRAG option on responses

* should listen for ICMP frag needed packets, and react by re-sending the
  response (which is embedded in the ICMP packet) with a TC bit set


* should send rate-limited ICMP frag needed messages to DNS servers when

f.anthony.n.finch  <>
Mull of Kintyre to Ardnamurchan Point: Southeast 4 to 6, occasionally 7 at
first, then veering south 3 to 5 later. Slight or moderate, becoming moderate
or rough near Tiree. Rain at times then fair, then showers later. Moderate or