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

Owen DeLong <owen@delong.com> Sun, 12 November 2023 00:54 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 65F8FC151061 for <v6ops@ietfa.amsl.com>; Sat, 11 Nov 2023 16:54:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.105
X-Spam-Level:
X-Spam-Status: No, score=-2.105 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_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 z4SJMRZWQYEC for <v6ops@ietfa.amsl.com>; Sat, 11 Nov 2023 16:54:39 -0800 (PST)
Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id 984D4C14CE45 for <v6ops@ietf.org>; Sat, 11 Nov 2023 16:54:39 -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 3AC0sZpO2881259 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sun, 12 Nov 2023 00:54:36 GMT
DKIM-Filter: OpenDKIM Filter v2.11.0 owen.delong.com 3AC0sZpO2881259
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=delong.com; s=mail; t=1699750476; bh=hIg0+9lL+R5J8FikKiXEhSeAOpelYptsqQynYY4KDUo=; h=From:Subject:Date:In-Reply-To:Cc:To:References:From; b=yj0jKFHK5/RuIWWWALtUqLvh60Vu7TPX9L42Fn8b/ypJALmG1vuPYs46SlCE/umKA gKs0sZoyPijiXeYc4GQ3qCJTKT8KuyjTd7Yn7SEs4TJeX7anRmi/vI0QtcnsDWV1XP DEeLH04l0jUSbrtGZo0LpWolf72K+pibR+tm9k2g=
From: Owen DeLong <owen@delong.com>
Message-Id: <F8EF42B7-E548-4BCB-B88B-2114E01FFC01@delong.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_15443985-9D69-48C6-9080-54ED73BBCD2F"
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3774.100.2.1.4\))
Date: Sat, 11 Nov 2023 16:54:25 -0800
In-Reply-To: <4B765D39-5201-4814-BFAE-8F3D71D24469@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> <00356A59-2B04-4A46-B2B4-EA595A4F02A1@delong.com> <4B765D39-5201-4814-BFAE-8F3D71D24469@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]); Sun, 12 Nov 2023 00:54:36 +0000 (UTC)
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/3bAbYtso2hGuLCy0ctHYkvyPeng>
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: Sun, 12 Nov 2023 00:54:43 -0000

No, but I’ve observed it in TCPDUMPs from MAC and Windows systems at least.

Owen


> On Nov 11, 2023, at 15:15, Geoff Huston <gih@apnic.net> wrote:
> 
> Have you measured that behaviour in any structured manner? Are the results of such a measurement online anywhere?
> 
> G
> 
>> On 12 Nov 2023, at 10:01 am, Owen DeLong <owen@delong.com> wrote:
>> 
>> 
>> 
>>> 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
>> 
>