Re: [v6ops] New draft at dnsop a bis for DNS IPv6 Transport Operational Guidelines

Philip Homburg <pch-v6ops-12@u-1.phicoh.com> Fri, 24 November 2023 19:43 UTC

Return-Path: <pch-b538D2F77@u-1.phicoh.com>
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF09EC151076 for <v6ops@ietfa.amsl.com>; Fri, 24 Nov 2023 11:43:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.907
X-Spam-Level:
X-Spam-Status: No, score=-1.907 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, T_SCC_BODY_TEXT_LINE=-0.01] autolearn=unavailable autolearn_force=no
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q6IzW1T9nEUT for <v6ops@ietfa.amsl.com>; Fri, 24 Nov 2023 11:43:03 -0800 (PST)
Received: from stereo.hq.phicoh.net (stereo.hq.phicoh.net [IPv6:2a10:3781:2413:1:2a0:c9ff:fe9f:17a9]) (using TLSv1.2 with cipher ECDHE-RSA-CHACHA20-POLY1305 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D765CC14CE54 for <v6ops@ietf.org>; Fri, 24 Nov 2023 11:43:01 -0800 (PST)
Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (TLS version=TLSv1.2 cipher=ECDHE-RSA-CHACHA20-POLY1305) (Smail #158) id m1r6c4j-0000K4C; Fri, 24 Nov 2023 20:42:53 +0100
Message-Id: <m1r6c4j-0000K4C@stereo.hq.phicoh.net>
To: v6ops@ietf.org
Cc: Havard Eidnes <he=40uninett.no@dmarc.ietf.org>
From: Philip Homburg <pch-v6ops-12@u-1.phicoh.com>
Sender: pch-b538D2F77@u-1.phicoh.com
References: <927959F5-71C8-4488-A52D-2A5A0969A951@apnic.net> <ZU8-4cLjPvTzXyJB@Space.Net> <2532F4E0-725A-4403-9B62-0145EB9279BB@apnic.net> <20231123.193744.1766915964051686702.he@uninett.no>
In-reply-to: Your message of "Thu, 23 Nov 2023 19:37:44 +0100 (CET) ." <20231123.193744.1766915964051686702.he@uninett.no>
Date: Fri, 24 Nov 2023 20:42:53 +0100
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/jrskgJcDwFkhTOAHKVFjSaMz_1A>
Subject: Re: [v6ops] New draft at dnsop a bis for DNS IPv6 Transport Operational Guidelines
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: v6ops discussion list <v6ops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/v6ops>, <mailto:v6ops-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/v6ops/>
List-Post: <mailto:v6ops@ietf.org>
List-Help: <mailto:v6ops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/v6ops>, <mailto:v6ops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 24 Nov 2023 19:43:07 -0000

>If I understand correctly, the gist of the argument is that too
>many IPv6 resolvers run with pre-DNS-flag-day-2020 values for
>EDNS0 buffer size (typically 4K), and too many of these actually
>fail to receive fragmented IPv6/UDP responses, and the argument
>is that this together should hold us back from issuing a blanket
>recommendation to use IPv6 for DNS transport at the publishing
>side.

What seems to be mostly ignored in this discussion is that an authoritative
DNS server is free to truncate (and set the TC flag) a UDP response at 
something smaller than the buffer size advertised by the resolver.

So even if the resolver advertises 4KB, the auth. server can still truncate
at something less then 1500 octets.

So to properly evaluate the effect of fragmentation issues, we need to look
not only at resolvers but also at the behavior of authoritative servers.

Where a recursive resolver can be fire and forget, an authoritative server
tends to be essential to business.