Re: [DNSOP] Call for Adoption: draft-fujiwara-dnsop-avoid-fragmentation

Mukund Sivaraman <> Tue, 14 April 2020 23:41 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 512533A12A5; Tue, 14 Apr 2020 16:41:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 9qbBvy8OUSie; Tue, 14 Apr 2020 16:41:51 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-CHACHA20-POLY1305 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 4586F3A12A4; Tue, 14 Apr 2020 16:41:50 -0700 (PDT)
Received: from localhost (unknown []) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature ECDSA (P-256) server-digest SHA256) (No client certificate requested) by (Postfix) with ESMTPSA id 56DA6E204AC; Tue, 14 Apr 2020 23:41:48 +0000 (GMT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;; s=mail; t=1586907709; bh=uvFcio8XcmPLM4Djjq5k5wZ4ZLPpjqc8iLEqJX7Csj8=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=g0OsTeBr/G+9aF/I/STt0mUK0XdVmAwnvRagl+CZPEnxlZNanmcO33Ht5ZEGVR9aA uN46nG7+qpAFMxlCVdMrd+Zw0AlHzESj3i/XWk5s9ThRwRWwm8uXqc+SSGhbwKSNTf Wi4nicEsO+374hPkcru+5FS/5Ip6HdpGDgbDwfos=
Date: Wed, 15 Apr 2020 05:11:46 +0530
From: Mukund Sivaraman <>
To: Tim Wicinski <>
Cc: dnsop <>, dnsop-chairs <>
Message-ID: <>
References: <> <>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <>
Archived-At: <>
Subject: Re: [DNSOP] Call for Adoption: draft-fujiwara-dnsop-avoid-fragmentation
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: Tue, 14 Apr 2020 23:41:53 -0000

One more question:

> 3.  Proposal to avoid IP fragmentation in DNS

>    o  UDP requestors and responders SHOULD send DNS responses with
>       IP_DONTFRAG / IPV6_DONTFRAG [RFC3542] options, which will yield
>       either a silent timeout, or a network (ICMP) error, if the path
>       MTU is exceeded.  Upon a timeout, UDP requestors may retry using
>       TCP or UDP, per local policy.

If the IP_DONTFRAG/IP_DF/IP_PMTUDISC_DO option is available and can be
used to set the DF flag on DNS over UDP over IPv4 PDUs, why are any of
the following maximum-size mitigations (the next 3 items after the above
quoted item) necessary?

A large response may be dropped on path, but such conditions are already
expected by resolvers; they make use of the OPT UDP payload size field
to retry to settle on a maximum size that will work with the peer.

It would be helpful to the reader to understand better, if the
requirements of "SHOULD" are annotated with the specific reasons why
that particular item is suggested. The 3 items after the above quoted
item don't specify reasons, and so it's not clear how with DF=1 set,
these items matter.

Off-topic, it appears to me that some of this overlaps with general DNS
over UDP behavior between client server, esp. a resolver vs. upstream. I
am not aware of an RFC/draft that describes in sufficient detail the
tricks (song and dance sequence) that a resolver uses to start
communications with an unknown peer and deal with UDP datagram loss on
path due to a variety of possible factors (loss due to
PMTU/fragmentation+drops, routing, EDNS0 behavior, lack of EDNS support,
etc. some of which was the topic of DNS flag day 2019). A resolver
retries with changes in how it makes its request. IP fragmentation
issues is a subset of this topic of how to communicate with a DNS peer
over UDP. You may want to consider documenting the techniques a client
could use when talking to a peer over UDP.

More generally, a modern day resolver algorithm includes nameserver
selection (SRTT-derived metric, bad peers, transport, etc.), limits on
recursion and indirection, response message processing, etc. These have
security implications and documentation is scant, of low-quality, and
scattered. Documentation for understanding of resolver<->NS
communication behavior is an often-requested item from users.