[v6ops] Re: Carrying large DNS packets over UDP in IPv6 networks

Havard Eidnes <he@uninett.no> Wed, 19 June 2024 09:16 UTC

Return-Path: <he@uninett.no>
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 28585C15154D for <v6ops@ietfa.amsl.com>; Wed, 19 Jun 2024 02:16:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.107
X-Spam-Status: No, score=-2.107 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, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=uninett.no
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id 1oCVT-ALj80E for <v6ops@ietfa.amsl.com>; Wed, 19 Jun 2024 02:15:55 -0700 (PDT)
Received: from smistad.uninett.no (smistad.uninett.no [IPv6:2001:700:1:0:eeb1:d7ff:fe59:fbaa]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 28961C151076 for <v6ops@ietf.org>; Wed, 19 Jun 2024 02:15:53 -0700 (PDT)
Received: from smistad.uninett.no (smistad.uninett.no []) by smistad.uninett.no (Postfix) with ESMTP id B311443EA00; Wed, 19 Jun 2024 11:15:48 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=uninett.no; s=he201803; t=1718788548; bh=AC3yYFFSH3TiNqtOvw/2VymGz7i5Zn2ixoxyGFS2JT8=; h=Date:To:Cc:Subject:From:In-Reply-To:References:From; b=e89zQHkBTIMejwI9yPnngkkF+hYppc2Mhu8d1V1seFMZxdNi2RblOpYjb1H++xCT9 06RkzxOTELzPpmTFm+i6dwYMad+4uEr2Xsbz3mMD1kxMHYvsvzh5Tkt328Ka0+A7EG JDqgHuRmBA8m+hxEyAb/z+nniHH9ZZWBPOc7jRwc=
Date: Wed, 19 Jun 2024 11:15:48 +0200
Message-Id: <20240619.111548.909374711618175678.he@uninett.no>
To: Suresh.Krishnan@gmail.com
From: Havard Eidnes <he@uninett.no>
In-Reply-To: <E35DC12F-D1CE-4AE5-B155-612C639A348B@gmail.com>
References: <E35DC12F-D1CE-4AE5-B155-612C639A348B@gmail.com>
X-Mailer: Mew version 6.9 on Emacs 28.2
Mime-Version: 1.0
Content-Type: Text/Plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
X-MailFrom: he@uninett.no
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-v6ops.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header
CC: v6ops@ietf.org
X-Mailman-Version: 3.3.9rc4
Precedence: list
Subject: [v6ops] Re: Carrying large DNS packets over UDP in IPv6 networks
List-Id: v6ops discussion list <v6ops.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/363AVvEW1fGM6JzWgni3gqzYb3A>
List-Archive: <https://mailarchive.ietf.org/arch/browse/v6ops>
List-Help: <mailto:v6ops-request@ietf.org?subject=help>
List-Owner: <mailto:v6ops-owner@ietf.org>
List-Post: <mailto:v6ops@ietf.org>
List-Subscribe: <mailto:v6ops-join@ietf.org>
List-Unsubscribe: <mailto:v6ops-leave@ietf.org>

>   At the last 6man meeting in Brisbane, Jared Mauch brought up
> an issue with large DNS packets carried over UDP in IPv6
> networks. Bob and I have written a draft recommending the use
> of TCP or QUIC for such large packets instead of UDP.
> https://datatracker.ietf.org/doc/draft-hinden-v6ops-dns/
> We would greatly appreciate your comments on this draft.

I agree with the general goal of avoiding DNS-over-UDP
fragmentation, particularly over IPv6, as that has been shown to be

As a DNS operator, one would have had to live under a rock to not be
aware of the 2020 DNS flag day recommendation, which specifies to
limit DNS-over-UDP payload size to 1232 bytes, ref.


The posted draft does however not specify how a recursive DNS
resolver can discover that it is possible to use QUIC for DNS
transport to a given publishing DNS name server.  I would claim that
recommending dynamic probing for this would be a non-starter at the
moment with a very low success rate, and has a potential for
introducing needless delay in DNS name resolution.  How and how
quickly is a recursive resolver able to discover that a given
publishing DNS name server doesn't implement DNS-over-QUIC if you
try to dynamically probe for this?  Isn't it at least partially this
problem that the DNSOP-related "DNS delegation" about-to-be-
established working group is looking at solving?  Therefore, I think
it would be premature to *now* recommend "just try to talk DNS-over-
QUIC" to random publishing DNS name servers.  The currently single
"safe" fallback for when the truncation flag is set in a DNS-over-
UDP response is to fall back to plain old DNS-over-TCP.  Ref. the
line from the DNS flag day web site which says "Resolvers MUST
resend queries over TCP if they receive a truncated UDP response
(with TC=1 set)!"

Best regards,

- Håvard