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

Andrew McConachie <> Wed, 12 August 2020 10:30 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 219CE3A11F8 for <>; Wed, 12 Aug 2020 03:30:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id yqYY6tb6u1Ja for <>; Wed, 12 Aug 2020 03:30:00 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::d31]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 1DA913A11F6 for <>; Wed, 12 Aug 2020 03:29:59 -0700 (PDT)
Received: by with SMTP id k23so1928830iom.10 for <>; Wed, 12 Aug 2020 03:29:59 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20150623; h=from:to:cc:subject:date:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=LRB6BSPq/px9VEmUHzrzfX//DP0lUtaevWw+mRu++uw=; b=YkowhDWrey6hirrm8+KvJ88GS2DqONqLfYGnoIKR544DQiCrDzN8QUU9AsBIkwa7mS o8Y+7vNCnA14cUm+oYdR8AXNY6W77KAg16JTAmb7D4D8PrxoGCmcXa5eBjI+ux4rblxp bkxkxuy9n3hKj309vqrB+5y87+maNb4jovv+mAWqTeR6DuR42zJ/t1v/ciJfHMb7ntO+ 6vO+0g8l8JXRw9Crt2Iw4p/WXZNVyg5/V+BQCxAH6ABlp5745/JoRxtHFx0a7mHY/un0 bkdmksMTHlb0fb5RFvVAkWYoscQuVK6jm59YP2tQKEW6hipaqKsCyRK8nD/UG4TmT5bp X42g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=LRB6BSPq/px9VEmUHzrzfX//DP0lUtaevWw+mRu++uw=; b=iCS31nZtP0ZB2WRO9aDBrLL+mYPLoYxDofDrVc+XrCPoZ6ahcn3LPghzWjdLSKDc8E 1wtSJG9Zsh9ORAlu8eyaZwkLmQna5ORB3vTi6/tXCJ3x5tDFNKSoQffsWYNzxrlW+u/k yKIneaMVjOR3kJu/qDA6JsB1t21pRKdxLhdwCcBmm3F9R3CpgAL5pKofh+WU3+XBWCy8 HBPEoY5DJpwDRexFqDumQqsIGVKp8zvOAtXPO326iC0VDNTUzJCZxwqjvdc3AjD8DUAI mBREVY+kiw1qRhEUDVdgKRM5VA/IobAQeBziohPfNKFCcPYwpk5C+dPm40KBzHCFkM/y j2QQ==
X-Gm-Message-State: AOAM5321BxPIlbm9M/s1HweuzQsDgHRTkjKMVGo+ic0C3vwsY6Y72ZbE QcBmSec1oBiowVHey/rU4XNAyJuHFF0=
X-Google-Smtp-Source: ABdhPJzgy/FLJlVtOJIUAK8NVlEQbWNMu2Ylr8+6hVNTZ43L1wUETj67u4rwNT7EJWVLlD/xrmCO9A==
X-Received: by 2002:a05:6602:cb:: with SMTP id z11mr15077548ioe.96.1597228198854; Wed, 12 Aug 2020 03:29:58 -0700 (PDT)
Received: from [] ([2a02:a212:9285:29f0:4c0e:3dcc:9c7a:ce63]) by with ESMTPSA id b1sm859083ilc.81.2020. (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 12 Aug 2020 03:29:58 -0700 (PDT)
From: "Andrew McConachie" <>
Date: Wed, 12 Aug 2020 12:29:55 +0200
X-Mailer: MailMate (1.13.1r5671)
Message-ID: <>
In-Reply-To: <>
References: <>
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: <>
Subject: Re: [DNSOP] I-D Action: draft-ietf-dnsop-avoid-fragmentation-00.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: Wed, 12 Aug 2020 10:30:03 -0000

Dear Mr Vixie and Mr Fujiwara,

I’m a relative noob to DNS and the IETF, and I’m often confused in 
how the term MTU is used when discussing DNS. Essentially it is a 
layer-2 term, and outside of layer-2 it can be difficult to understand 
what is meant by it. It’s a term that’s become overloaded.

For example this sentence, “In practice, the smallest MTU witnessed in 
the operational DNS community is 1500 octets, the Ethernet maximum 
payload size.” Does this imply an Ethernet overhead of 18 bytes 
(6+6+2+4) (DA+SA+ET+FCS)? And what precisely is meant by Ethernet here? 
Contemporary layer-2 technologies that we call ethernet do not have this 
1500 byte limit. The problem is that as a reader it’s not clear to me 
how many bytes are left over for layer-3 and above.

Perhaps it’s too late in the game to limit the use of ‘MTU’ to 
layer-2 discussions. But it would be a lot clearer to me if we used a 
term like ‘packet size’ when discussing layer-3 and above, and kept 
the MTU term for use only when discussing layer-2 segment maximum 
datagram sizes.

Also, it seems odd to not mention NAT in the second sentence, “Path 
MTU discovery remains widely undeployed due to security issues”. NAT 
breaks PMTUD when ICMP is used as the discovery mechanism. This should 
get mentioned in the document somewhere. There are likely many 
technologies deployed that break PMTUD that I’m not even aware of, 
it’s not just ‘security issues’.


On 30 Jun 2020, at 12:36, wrote:

> A New Internet-Draft is available from the on-line Internet-Drafts 
> directories.
> This draft is a work item of the Domain Name System Operations WG of 
> the IETF.
>         Title           : Fragmentation Avoidance in DNS
>         Authors         : Kazunori Fujiwara
>                           Paul Vixie
> 	Filename        : draft-ietf-dnsop-avoid-fragmentation-00.txt
> 	Pages           : 10
> 	Date            : 2020-06-30
> Abstract:
>    Path MTU discovery remains widely undeployed due to security 
> issues,
>    and IP fragmentation has exposed weaknesses in application 
> protocols.
>    Currently, DNS is known to be the largest user of IP fragmentation.
>    It is possible to avoid IP fragmentation in DNS by limiting 
> response
>    size where possible, and signaling the need to upgrade from UDP to
>    TCP transport where necessary.  This document proposes to avoid IP
>    fragmentation in DNS.
> The IETF datatracker status page for this draft is:
> There are also htmlized versions available at:
> Please note that it may take a couple of minutes from the time of 
> submission
> until the htmlized version and diff are available at
> Internet-Drafts are also available by anonymous FTP at:
> _______________________________________________
> DNSOP mailing list