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

Owen DeLong <owen@delong.com> Sat, 11 November 2023 23:01 UTC

Return-Path: <owen@delong.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 16F24C151525 for <v6ops@ietfa.amsl.com>; Sat, 11 Nov 2023 15:01:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.104
X-Spam-Level:
X-Spam-Status: No, score=-2.104 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=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=delong.com
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 Z66MaIH-42ee for <v6ops@ietfa.amsl.com>; Sat, 11 Nov 2023 15:01:16 -0800 (PST)
Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id 43A7DC14EB19 for <v6ops@ietf.org>; Sat, 11 Nov 2023 15:01:16 -0800 (PST)
Received: from smtpclient.apple ([192.168.100.138]) (authenticated bits=0) by owen.delong.com (8.17.1/8.15.2) with ESMTPSA id 3ABN1BDr2852220 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sat, 11 Nov 2023 23:01:12 GMT
DKIM-Filter: OpenDKIM Filter v2.11.0 owen.delong.com 3ABN1BDr2852220
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=delong.com; s=mail; t=1699743672; bh=GP2Q10MVCmZZVVV3g9EA+MI63xW8FQscOV8eFdK0vDM=; h=From:Subject:Date:In-Reply-To:Cc:To:References:From; b=RVkhAK/yZJwZ6mTc0Z5eJWSDsJF17BDemm7PzQp8LVadOsj3n8HfqvSROyuXWsBog Zsv/UQA1FEQlMVOfrCCcu41k6fsr/3bg5S4UhxAn/HXbc22J8ufogeV6PHTX1b1Q1f IBm/iCrv4AeDH9Dx0swLMuQ5iTCOY83+cx1yVLuI=
From: Owen DeLong <owen@delong.com>
Message-Id: <00356A59-2B04-4A46-B2B4-EA595A4F02A1@delong.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_9A8CFFE4-FA56-4541-8B9A-F80575329748"
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3774.100.2.1.4\))
Date: Sat, 11 Nov 2023 15:01:01 -0800
In-Reply-To: <4F493716-44FA-473A-8EFC-C6811B1E1C7A@apnic.net>
Cc: Gert Doering <gert@space.net>, list <v6ops@ietf.org>
To: Geoff Huston <gih@apnic.net>
References: <CAD9w2qYhCmkp2bOiGet4DY4AmbGHXj7r_reMibCK18rR8ivbMQ@mail.gmail.com> <CACMsEX8wQB3B1w2TOpPTjZoADYf5ybrKhpOXmo=iuOhUFJbJ5g@mail.gmail.com> <B57D7BFA-ECE9-4F23-9324-7591E91F457B@apnic.net> <ZU6WpbDBJ9lcik_3@Space.Net> <927959F5-71C8-4488-A52D-2A5A0969A951@apnic.net> <5A47C4EB-7DFD-472D-87DE-F2AEF9971844@delong.com> <4F493716-44FA-473A-8EFC-C6811B1E1C7A@apnic.net>
X-Mailer: Apple Mail (2.3774.100.2.1.4)
X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.6.4 (owen.delong.com [192.159.10.2]); Sat, 11 Nov 2023 23:01:12 +0000 (UTC)
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/YiKdIyG-PfCXIpl7pVSUvYjuDA4>
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: Sat, 11 Nov 2023 23:01:20 -0000


> On Nov 10, 2023, at 20:55, Geoff Huston <gih@apnic.net> wrote:
> 
> 
> 
>> On 11 Nov 2023, at 8:45 am, Owen DeLong <owen@delong.com> wrote:
>> 
>>> 
>>> Failure takes time. If a server is serving large responses over IPv6 it may take longer and may take some time to conclude that a response cannot reach the querier over IPv6. To recommend that this extended time SHOULD be the default seems to me to lack adequate operational motivation and lack some cohesion elsewhere in this space to shave off delay elements. TLS 1.3, QUIC, etc.. It we are all for a slower DNS then lets be upfront with that desire! ( :-) )
>>> 
>> 
>> In fairness, isn’t working around this sort of thing a big part of Happy Eyeballs (for better or worse)?
> 
> There is no “Happy Eyeballs” in protocol choice for DNS resolution queries. There is no “fast failover” either.
> 
> The current theological orthodoxy is to set your EDNS Buffer size to 1232 and if the response is larger than that then burn up an additional 2 RTT cycles to get the client to query using TCP. In theory this avoids waiting for a timeout, but it’s still a time penalty. But this message does not appear to have made it through. In the APNIC measurement platform some 47% of DNS queries over IPv6 present with a 4096 EDNS buffer size. 
> 
> 
> 

It may not be in the HE RFCs, but I’ve noticed MANY implementations will ask over v4 and v6 for the same resolver query on the first shot, or in some cases a few seconds later, so there is, in fact, happy eyeballs like implementation in the wild even if it isn’t official.

Owen