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.
- [v6ops] New draft at dnsop a bis for DNS IPv6 Tra… Momoka Yamamoto
- Re: [v6ops] New draft at dnsop a bis for DNS IPv6… Nick Buraglio
- Re: [v6ops] New draft at dnsop a bis for DNS IPv6… Geoff Huston
- Re: [v6ops] New draft at dnsop a bis for DNS IPv6… Nick Buraglio
- Re: [v6ops] New draft at dnsop a bis for DNS IPv6… Martin Huněk
- Re: [v6ops] New draft at dnsop a bis for DNS IPv6… Mark Elkins
- Re: [v6ops] New draft at dnsop a bis for DNS IPv6… Geoff Huston
- Re: [v6ops] New draft at dnsop a bis for DNS IPv6… Havard Eidnes
- Re: [v6ops] New draft at dnsop a bis for DNS IPv6… Geoff Huston
- Re: [v6ops] New draft at dnsop a bis for DNS IPv6… Havard Eidnes
- Re: [v6ops] New draft at dnsop a bis for DNS IPv6… David Farmer
- Re: [v6ops] New draft at dnsop a bis for DNS IPv6… Momoka Yamamoto
- Re: [v6ops] New draft at dnsop a bis for DNS IPv6… Gert Doering
- Re: [v6ops] New draft at dnsop a bis for DNS IPv6… Owen DeLong
- Re: [v6ops] New draft at dnsop a bis for DNS IPv6… Geoff Huston
- Re: [v6ops] New draft at dnsop a bis for DNS IPv6… Owen DeLong
- Re: [v6ops] New draft at dnsop a bis for DNS IPv6… Geoff Huston
- Re: [v6ops] New draft at dnsop a bis for DNS IPv6… Gert Doering
- Re: [v6ops] New draft at dnsop a bis for DNS IPv6… Owen DeLong
- Re: [v6ops] New draft at dnsop a bis for DNS IPv6… Geoff Huston
- Re: [v6ops] New draft at dnsop a bis for DNS IPv6… Owen DeLong
- Re: [v6ops] New draft at dnsop a bis for DNS IPv6… Geoff Huston
- Re: [v6ops] New draft at dnsop a bis for DNS IPv6… Marco Davids (IETF IMAP)
- Re: [v6ops] New draft at dnsop a bis for DNS IPv6… David Farmer
- Re: [v6ops] New draft at dnsop a bis for DNS IPv6… Owen DeLong
- Re: [v6ops] New draft at dnsop a bis for DNS IPv6… Fred Baker
- Re: [v6ops] New draft at dnsop a bis for DNS IPv6… Geoff Huston
- Re: [v6ops] New draft at dnsop a bis for DNS IPv6… Havard Eidnes
- Re: [v6ops] New draft at dnsop a bis for DNS IPv6… Geoff Huston
- Re: [v6ops] New draft at dnsop a bis for DNS IPv6… Mark Andrews
- Re: [v6ops] New draft at dnsop a bis for DNS IPv6… Geoff Huston
- Re: [v6ops] New draft at dnsop a bis for DNS IPv6… Momoka Yamamoto
- Re: [v6ops] New draft at dnsop a bis for DNS IPv6… Philip Homburg
- Re: [v6ops] New draft at dnsop a bis for DNS IPv6… Gert Doering