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

Mark Andrews <marka@isc.org> Fri, 24 November 2023 00:17 UTC

Return-Path: <marka@isc.org>
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 A0CEDC151545 for <v6ops@ietfa.amsl.com>; Thu, 23 Nov 2023 16:17:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.107
X-Spam-Level:
X-Spam-Status: No, score=-7.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_DNSWL_HI=-5, 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=isc.org header.b="TMjCBjE1"; dkim=pass (1024-bit key) header.d=isc.org header.b="lZpXDGSX"
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 jEWvXohBqCOa for <v6ops@ietfa.amsl.com>; Thu, 23 Nov 2023 16:17:05 -0800 (PST)
Received: from mx.pao1.isc.org (mx.pao1.isc.org [149.20.2.50]) (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 088DFC14CF15 for <v6ops@ietf.org>; Thu, 23 Nov 2023 16:17:03 -0800 (PST)
Received: from zimbrang.isc.org (zimbrang.isc.org [149.20.2.31]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx.pao1.isc.org (Postfix) with ESMTPS id 78CB93AB006; Fri, 24 Nov 2023 00:17:03 +0000 (UTC)
ARC-Filter: OpenARC Filter v1.0.0 mx.pao1.isc.org 78CB93AB006
Authentication-Results: mx.pao1.isc.org; arc=none smtp.remote-ip=149.20.2.31
ARC-Seal: i=1; a=rsa-sha256; d=isc.org; s=ostpay; t=1700785023; cv=none; b=qB2P8UuAI9clp3dvqbMdy7JhTN+XMkyn6LdZPjnZAJPs3WLDfJvwp7H7GUvqm3p31X0XFXSX59XarBiCsJjbWvdIxFILWo++LCbCbsxKA82UStAl6geCUmxvH1nSWsmM99fgkfN7EsDvGJf6G7vsZGlYTnqldP7rLxwQtTO+XT4=
ARC-Message-Signature: i=1; a=rsa-sha256; d=isc.org; s=ostpay; t=1700785023; c=relaxed/relaxed; bh=q0RMKQVe4rZ4jnVJoFvsDIZhsh3N/c1+g/tCL+WlPq4=; h=DKIM-Signature:DKIM-Signature:Mime-Version:Subject:From:Date: Message-Id:To; b=V5WWfw/1Wd15H3YMDWLwZlbCopjX4Z3Wa6GMQiUaSm637D9b9Ku3Gm0xEFsQa5Xn5D098z/3Pytz1Ac7YZycVHVNy+9LAaCS+QViOcZoRT11YheS+JZEWSkD3OzebsHOyYfe03u//lIhjW+LcZBXFHeqzXpUaboGMKMY53kByO4=
ARC-Authentication-Results: i=1; mx.pao1.isc.org
DKIM-Filter: OpenDKIM Filter v2.10.3 mx.pao1.isc.org 78CB93AB006
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=isc.org; s=ostpay; t=1700785023; bh=LRqgm4SK/CcaCjP+Gy+r2Bbg3Il5AfL+NB/2czc/KJ4=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=TMjCBjE1zNyABGptx6fnCj8fcrJ0uSY0gND58DVscOXeRtWN3zoFMLqaRToRmCF4Q LP2/5TnKwahLLPF60D5XUqZMJsXw9pH3gDutaI/excqsM9dlD+KisRWF3RbN3NaAAr Azs1hdUIwq39Z4Kqk5mS8TOj7SuKfzk7hqVPdeZg=
Received: from zimbrang.isc.org (localhost.localdomain [127.0.0.1]) by zimbrang.isc.org (Postfix) with ESMTPS id 71AB51109FBE; Fri, 24 Nov 2023 00:17:03 +0000 (UTC)
Received: from localhost (localhost.localdomain [127.0.0.1]) by zimbrang.isc.org (Postfix) with ESMTP id 4B3281109FC9; Fri, 24 Nov 2023 00:17:03 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.10.3 zimbrang.isc.org 4B3281109FC9
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isc.org; s=05DFB016-56A2-11EB-AEC0-15368D323330; t=1700785023; bh=q0RMKQVe4rZ4jnVJoFvsDIZhsh3N/c1+g/tCL+WlPq4=; h=Mime-Version:From:Date:Message-Id:To; b=lZpXDGSXZxytX3+kMfzzEZHyCjIjJmxQF0O/ZhUDWOTtpiwcajvE/pttslMf8PXbQ ylmabr6QpbrmDcwgkVAyF69QhqYC+MJSLyWyfdrzyy6QBMUYJjbDaftzNg9TWEf8Rt Z5zEKbCmKcpa6UQMHr1nmwMrUZBSPiCdbyFUkFSs=
Received: from zimbrang.isc.org ([127.0.0.1]) by localhost (zimbrang.isc.org [127.0.0.1]) (amavis, port 10026) with ESMTP id OBErI3-xe4dS; Fri, 24 Nov 2023 00:17:03 +0000 (UTC)
Received: from smtpclient.apple (n49-187-27-239.bla1.nsw.optusnet.com.au [49.187.27.239]) by zimbrang.isc.org (Postfix) with ESMTPSA id 7CB901109FBE; Fri, 24 Nov 2023 00:17:02 +0000 (UTC)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3731.700.6\))
From: Mark Andrews <marka@isc.org>
In-Reply-To: <A137855F-F70F-429A-AFB2-B1F3271F1BE5@apnic.net>
Date: Fri, 24 Nov 2023 11:16:50 +1100
Cc: Havard Eidnes <he@uninett.no>, "v6ops@ietf.org" <v6ops@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <035B98C3-517E-4839-9725-81A79B0A8419@isc.org>
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> <A137855F-F70F-429A-AFB2-B1F3271F1BE5@apnic.net>
To: Geoff Huston <gih@apnic.net>
X-Mailer: Apple Mail (2.3731.700.6)
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/7p_1RozMXX2EGjv_qwnn5ZD2dcU>
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 00:17:09 -0000

There are a number of issues involved here

Anycast DNS servers and blocking of PTB breaking PMTUD for both TCP and UDP.

1) set a lower MSS for TCP (e.g. 1280) so the replies don’t generate PTBs.  TCP
retransmission timers are much too big for DNS.  The TCP sessions are torn down
if there is no response in a couple of seconds.
2) set IPV6_USE_MIN_MTU=1 so that UDP packets are fragmented at network minimum MTU.

BIND does both of these by default. Other servers do one or the other, both or none
of these measures.

Get firewall vendors to permit fragments from the reversed src/dst pairs when setting
up connection tracking using the same expiry timers that they are using for the non
fragmented responses.  IPv6 has a 32 bit fragment id which makes off path fragmentation
reassembly attacks very hard for IPv6.  Alternatively just permit fragments.  They
should be doing this independently of DNS.

Servers should have a pool of multiple non sequential fragmentation identifier sources
which are randomly selected from based on destination address.

The reason for the draft is that DNS queries are being made from behind NAT64’s and
that puts a lot of state there if there aren’t IPv6 servers available.

Recursive DNS servers track RTT, preference IPv6 servers and use sub second timeouts
when talking to the set of server addresses for a zone.

As for EDNS advertised UDP size servers can restrict the response size independently
of the client’s advertised response size if they want.  It comes at a cost of more TCP.

Mark

> On 24 Nov 2023, at 06:07, Geoff Huston <gih@apnic.net> wrote:
> 
> 
> 
>> On 24 Nov 2023, at 5:37 am, Havard Eidnes <he@uninett.no> wrote:
>> 
>>> 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.
>> 
>> ...
> 
> Thanks for the thoughtful response Havard.As a minor point of correction the data 
> in that article is not a census of individual resolvers, but a census of users. i.e. if a resolver
> is used by 100 users and another is used by just a single user the data will be weighted in
> favour of the heavily used resolver.
> 
> So the current data shows that some 69% of users pass their queries to a recursive
> resolver over IPv6 use an EDNS buffer size that is greater than 1232 bytes, 
> and 49% use a buffer size that is greater than 1500. In these cases the 
> odds of encountering a timeout rather than a response for large responses
> is considerably higher. What this means is that it takes more time to resolve the name
> (1 second is the most commonly observed timeout).
> 
> So why should the IETF be proposing in a normative SHOULD the adoption of
> an operational configuration that results in cases of slower response and an elevated 
> set of retransmissions?  To quote RFC2119:
> 
> "[SHOULD] MUST only be used where it is actually required for interoperation
> or to limit behaviour which has potential for causing harm (e.g., limiting 
> retransmissions)"
> 
> As I said in the article (https://www.potaroo.net/ispcol/2023-11/dns-ipv6.html) I offerred an 
> alternative wording for this 3901bis draft along the lines of:
> 
> In using IPv6 as the platform for DNS queries, DNS implementations SHOULD
> use an EDNS Buffer Size value of 1,232 bytes. An operator MAY use a greater
> value for this parameter, but only if the DNS operator is confident that this
> local setting will not result in IP packet fragmentation being required to pass
> a DNS message to its intended recipient.
> 
> If the reduced EDNS Buffer Size parameter is used by a DNS resolver, then such
> DNS resolvers MAY order the list of servers that could be queried to prefer to
> use an IPv6 query as the initial query.
> 
> That would prevent the client performing a timeout and in the case of a large response
> would allow the client to commence a TCP re-query within a single RTT.
> 
> 
> regards,
> 
>   Geoff
> 
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742              INTERNET: marka@isc.org