Re: [DNSOP] default value of draft-ietf-dnsop-avoid-fragmentation

Viktor Dukhovni <ietf-dane@dukhovni.org> Fri, 19 March 2021 02:42 UTC

Return-Path: <ietf-dane@dukhovni.org>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA8AA3A0BF6 for <dnsop@ietfa.amsl.com>; Thu, 18 Mar 2021 19:42:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ebQOY7icFjSY for <dnsop@ietfa.amsl.com>; Thu, 18 Mar 2021 19:42:53 -0700 (PDT)
Received: from straasha.imrryr.org (straasha.imrryr.org [100.2.39.101]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 34D553A0BF3 for <dnsop@ietf.org>; Thu, 18 Mar 2021 19:42:52 -0700 (PDT)
Received: by straasha.imrryr.org (Postfix, from userid 1001) id 5851FD1442; Thu, 18 Mar 2021 22:42:51 -0400 (EDT)
Date: Thu, 18 Mar 2021 22:42:51 -0400
From: Viktor Dukhovni <ietf-dane@dukhovni.org>
To: dnsop@ietf.org
Message-ID: <YFQPq6tlvJFiUet/@straasha.imrryr.org>
Reply-To: dnsop@ietf.org
References: <20210315.131604.152003594194628775.fujiwara@jprs.co.jp> <5AB6AF96-F099-4F9F-812A-2C42C1934FF1@rfc1035.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <5AB6AF96-F099-4F9F-812A-2C42C1934FF1@rfc1035.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/DxGZ7QplGBTGlZdcNVAAIjGYRoU>
Subject: Re: [DNSOP] default value of draft-ietf-dnsop-avoid-fragmentation
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnsop>, <mailto:dnsop-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/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: Fri, 19 Mar 2021 02:42:56 -0000

On Mon, Mar 15, 2021 at 05:38:40PM +0000, Jim Reid wrote:

> > However, operators of DNS servers SHOULD measure their path MTU to
> > well-known locations on the Internet, such as [a-m].root-servers.net
> > or [a-m].gtld-servers.net at setting up the servers.
> 
> I think it would be better to replace this with “Operators of DNS
> servers MAY measure their path MTU.”.

Sadly, we don't have a keyword that's midway between MAY and SHOULD, I
used to think that RECOMMENDED was it, but I was disabused of that
mistake some time back.  I think that the suggestion to measure the
path MTU is good advice.

The key thing to note is that in the resolver case this is only
applicable to full-service resolvers that directly query public
authoritative servers, and in the authoritative server case this
applies to servers serving public-Internet facing zones.

> Measuring the MTU to well-known locations on the Internet won’t be
> appropriate for some use cases. For instance inside private nets that
> aren’t connected to the Internet or for forwarding-only servers that
> never query an authoritatve server.

Right, the forwarding-mostly (or only) servers should just measure the
PMTU to the relevant upstream(s).

> IMO it’s a bad idea to recommend specific servers that could be the
> target for those PMTU probes. [Suppose those names change one day -
> unlikely for the above but you never know.] That could become a vector
> of (D)DoS attacks - probably not on the above name servers themselves
> but on the access routers in front of them that might well be
> rate-limiting ICMP packets.

I don't see the DDoS, such measurements should be rather infrequent, in
particular, I don't see why these would be much more frequent than root
zone priming queries, which full service resolvers do routinely at
startup.

> This could get nasty with icky CPE
> firmware: imagine every home router in (say) Comcast’s net doing PMTU
> to the same root server.

These would generally not all boot up at the same time, and would be
expected to be configured in forward-only mode to the relevant Comcast
iterators.

> Besides, is the PMTU to a root or .com server, going to be the same as
> that for the example.whatever name servers?

But the proposal remains sound, because that server also measures its
PMTU to the root, and assuming PMTU reduction happens mostly at the
respective edges of the network, and not in the core, the lower of
the two PMTUs to some suitable core nodes would typically also be
the PMTU end-to-end between them.

Thus if a full-service iterator bases its EDNS UDP size on its PMTU
to the core, and the authoritative server replies with a size that
is at most its respective PMTU, you'll most often end up with a
workable lower-bound.

> If PMTU is to be used, maybe it needs to be applied to all
> authoritative name servers a resolver queries?

Not needed, on the assumption that the path from each to the
core is as "wide" as the path from either a common core node.

-- 
    Viktor.