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

Havard Eidnes <he@uninett.no> Thu, 23 November 2023 18:37 UTC

Return-Path: <he@uninett.no>
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 0EA4BC152573 for <v6ops@ietfa.amsl.com>; Thu, 23 Nov 2023 10:37:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.108
X-Spam-Level:
X-Spam-Status: No, score=-2.108 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_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 ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ty7or3L_dNbd for <v6ops@ietfa.amsl.com>; Thu, 23 Nov 2023 10:37:50 -0800 (PST)
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 B6CDDC1519AB for <v6ops@ietf.org>; Thu, 23 Nov 2023 10:37:48 -0800 (PST)
Received: from smistad.uninett.no (smistad.uninett.no [158.38.62.77]) by smistad.uninett.no (Postfix) with ESMTP id A243C43ECF3; Thu, 23 Nov 2023 19:37:44 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=uninett.no; s=he201803; t=1700764664; bh=kbiSkOiUn309NaLu4lnN9iMOduS3Nh9CzyB1tINl4o0=; h=Date:To:Cc:Subject:From:In-Reply-To:References:From; b=d4jQ/7nCRI51OSmL6Avw1cqmr6E7G+JHI4NWB8agt99Jw++iSHYW7RAb/jCTPD+C0 WchTJWk/52K7PFhwP9rPKILehd4dyjCPyhYxJICixfRP+ynPaLR2jhQo75WCdyXB8Y KC/KNSrAPmQ96QNc6//wVsKdhQ2kldoSmzEWXm2o=
Date: Thu, 23 Nov 2023 19:37:44 +0100
Message-Id: <20231123.193744.1766915964051686702.he@uninett.no>
To: gih@apnic.net
Cc: gert@space.net, v6ops@ietf.org
From: Havard Eidnes <he@uninett.no>
In-Reply-To: <2532F4E0-725A-4403-9B62-0145EB9279BB@apnic.net>
References: <927959F5-71C8-4488-A52D-2A5A0969A951@apnic.net> <ZU8-4cLjPvTzXyJB@Space.Net> <2532F4E0-725A-4403-9B62-0145EB9279BB@apnic.net>
X-Mailer: Mew version 6.9 on Emacs 26.3
Mime-Version: 1.0
Content-Type: Text/Plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/uAtw32rVAhSqHcsWarD6DvSbuKA>
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: Thu, 23 Nov 2023 18:37:55 -0000

> Go read https://www.potaroo.net/ispcol/2023-11/dns-ipv6.html to
> get a clearer explanation of the issues here about the DNS, UDP
> and IPv6.

OK, I've done that, and I'm not entirely certain that I fully
agree.


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.


I personally think that this would put too much power in the
hands of those who do not follow long-since issued advice.  Those
affected by "announcing too high EDNS0 buffer size", or
"inability for an IPv6 resolver to receive IPv6 fragments" are
both the users of that particular resolver, and it's the
responsibility of the resolver operator or his network provider
to fix those problems.

Why "too high EDNS0 buffer size" is announced could be for
multiple reasons, e.g. "install once, never upgrade", or
"slow-paced propagation of vendor-provided defaults through the
software delivery/update chain", or, as you implicitly suggested,
statically configured EDNS0 buffer size, and noone in the
vicinity heard about the DNS flag day 2020 or lifted a finger to
do anything about it.  Either way, those affected by such mis-
configuration are primarily the users of the affected resolver
node, and it's the responsibility of the operator of that node to
take care of that.

And ... if I'm not entirely mistaken, DNS resolvers typically
keep track of which publishing name servers (at which address)
respond, and within which time, and tend to prefer responsive and
quick-to-respond publishing name servers's addresses.  So, in a
sense, such recursive resolvers don't behave entirely similar to
the "happy eyeballs" algorithm, but rather as "happy eyeballs
with a memory of past performance", and thus tend to adapt to the
prevailing conditions.

One possible counter-argument could be that one *might* see an
increase in DNS traffic from such now considered to be
"mis-configured resolver setups", but given the "happy eyeballs
with a memory" functionality I think that this will be far less
than a doubling.


So, in sum, I am not so worried about recommending that DNS zones
should be served by at least 2 IPv6-capable publishing name
servers (which seems to be the gist of the revised
recommendation, though I agree that the wording could be better).


Regards,

- Håvard