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

Geoff Huston <gih@apnic.net> Fri, 10 November 2023 05:00 UTC

Return-Path: <gih@apnic.net>
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 9CBA3C16F3E9 for <v6ops@ietfa.amsl.com>; Thu, 9 Nov 2023 21:00:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.106
X-Spam-Level:
X-Spam-Status: No, score=-2.106 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_MSPIKE_H2=-0.001, 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=apnic.net
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 yu9Ieym8WonB for <v6ops@ietfa.amsl.com>; Thu, 9 Nov 2023 21:00:28 -0800 (PST)
Received: from AUS01-SY4-obe.outbound.protection.outlook.com (mail-sy4aus01on2070.outbound.protection.outlook.com [40.107.107.70]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D7567C16F3E2 for <v6ops@ietf.org>; Thu, 9 Nov 2023 21:00:16 -0800 (PST)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=EZaC4v2mjqXtTBHpkWfylVYelcQDcDEnGhzq430CN6uhCrI8/WRlMT2ea996UacBh/jpbldCpa29ujT8EQ2UDTSzEz3Gc4LIH3vTTO7C3Y4zQpZMowyeC5ah9lkTt1IT566a6btWsYA6b2oM0p/W/M0HBwbjhaowm4MWq5dcNp7KkXmGlnJu/LRmq5a4idMnh/TmYNoZy20vDoFmFAxrSTe1Gwcr8ibvNhignfQgZ0m8ZU3esczntaAFckK2iHIKO14v11xgCfmCRUMMGpjkt/Nf+vuFrPo1WlsvfvZjnXPpCF4IiYR+yMI5n5SWCJBi8sgS/ZdkP0CTOVOEK9NHSw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=jsnPS31AOm6zsMVQIBjOCWCN0xo5x32MTebKGUbmHs4=; b=iUWEsQSiwfQo9Ur3/tlr/yk6lIldUMlT/dbZK3BgrkzjI7xG1Mqv8XUBabb0hzFJCw75DnlPaOH6W/kMnYUcFYTCohVFfIZnbGB5SEKWO22O5PRKhHDScarxMtHNGCYZcsDe6kc43N/cTnAamTrfuY8MzRh85ZRYVDGPKvqXDgJcCqGEqmHPNxo0yvMPhka3+qsYtU5LkBTf6jTWhgX/kCSnbVxrEOi5L1HFnlMKQv4jT6hZZKDyfmQ8LH55VFLi5LIpbGJrgXGk4A6RcXoXp14jxdk3eGgo6bGAIETkUeUWAemi7KTv5gPLXYl2oObXKT9nKINsjjNvILWnt0cHAw==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=apnic.net; dmarc=pass action=none header.from=apnic.net; dkim=pass header.d=apnic.net; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=apnic.net; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=jsnPS31AOm6zsMVQIBjOCWCN0xo5x32MTebKGUbmHs4=; b=UxQkibWQQ9jgDoPWff9b1ai6uJP3RL86+MjRFY1zznrN8su1OcHfsQxXAfmbsVcsbpKVdUv4HkDceKa8dIJWuecWLxg8K/PxOYWk6pZAekp1fXjmBH10g8jrCp87g76d67cJ5UCz/3mp6gTKMZWo+VVUTMvk2L2oATmclojO2ug=
Received: from SYZP282MB3169.AUSP282.PROD.OUTLOOK.COM (2603:10c6:10:176::18) by ME4P282MB1126.AUSP282.PROD.OUTLOOK.COM (2603:10c6:220:97::10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.6977.18; Fri, 10 Nov 2023 05:00:12 +0000
Received: from SYZP282MB3169.AUSP282.PROD.OUTLOOK.COM ([fe80::350c:a749:2801:a711]) by SYZP282MB3169.AUSP282.PROD.OUTLOOK.COM ([fe80::350c:a749:2801:a711%3]) with mapi id 15.20.6977.019; Fri, 10 Nov 2023 05:00:12 +0000
From: Geoff Huston <gih@apnic.net>
To: Nick Buraglio <buraglio@forwardingplane.net>
CC: Momoka Yamamoto <momoka.my6@gmail.com>, list <v6ops@ietf.org>
Thread-Topic: [v6ops] New draft at dnsop a bis for DNS IPv6 Transport Operational Guidelines
Thread-Index: AQHaExC9b2onPeoBBkiWl+bgdD+8xbByBSuAgAAuPoCAACeNgIAApHKA
Date: Fri, 10 Nov 2023 05:00:12 +0000
Message-ID: <0AF349E3-2916-4F06-A19E-211D895AEFA6@apnic.net>
References: <CAD9w2qYhCmkp2bOiGet4DY4AmbGHXj7r_reMibCK18rR8ivbMQ@mail.gmail.com> <CACMsEX8wQB3B1w2TOpPTjZoADYf5ybrKhpOXmo=iuOhUFJbJ5g@mail.gmail.com> <B57D7BFA-ECE9-4F23-9324-7591E91F457B@apnic.net> <CACMsEX-wR9T2BtPqY+wmEObB9YjSE-NezK2jSLg13Xu2faTapw@mail.gmail.com>
In-Reply-To: <CACMsEX-wR9T2BtPqY+wmEObB9YjSE-NezK2jSLg13Xu2faTapw@mail.gmail.com>
Accept-Language: en-AU, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-mailer: Apple Mail (2.3774.200.91.1.1)
authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=apnic.net;
x-ms-publictraffictype: Email
x-ms-traffictypediagnostic: SYZP282MB3169:EE_|ME4P282MB1126:EE_
x-ms-office365-filtering-correlation-id: 1cccbbc4-0716-4bd3-fe2f-08dbe1a9ebfe
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: xAx23esZNeCa//fZkSHJuqX4Ec2I0KPNQ5v1XfzlIrhn5Az+7XDa7cdVkCKYhhrlC/+HETO0fATgsiDfOGxQGzrWKrjO5iMP7yumzZ+sEJvDVQqiF5/uuGhu//p3jFSe6FhDjBKo7503TPdMpYVpmijQt5XxBrrqrhtQt+PSDfe0J1TrloD1bKgKQRQYO5jiqWSEkt383xS6PEeZaW17T0ijdhKFok1SUMl4+/1zGw915mBau/XY8hp7BGJPzcuOMLMJsfGrWmhL82H4Swd9nGlAbfnUdpm3rmlkga2kHi8lpI58bO+nPk2hlT0GeLWWPu+xcLuBBZg0Lzi3MjVC+FiI13TroIICYtDRzmACsjsAAPAhlWvz8eyoZIEjkCCS/8/WV2Wt5T4ow4Kx2bUGwWGIeYyL2F+PIVILlgrY9SmpWjWE/X37hWviNCyZU5O8WUPjHwBAJiIzoE1AZOPaeUGkWhJObMLYvq3CxZ8K1VvAAOOn89cWNpHelUhulB88QXbp7+nB57ujIlVP8GIuXpqxKLx2KVVQKGPHwIMgBaIUpJ0o0LHksrSomn4mnlStYruNN8Yvv/SoCpP2tV8x0NYGYE999UiZDVP8xK1WTsGjRjf5la0lwU3iQqlT6q8ViwMWZYzLW/wOk8joTYvaJQ==
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:SYZP282MB3169.AUSP282.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFS:(13230031)(396003)(39840400004)(376002)(346002)(136003)(366004)(230922051799003)(186009)(1800799009)(64100799003)(451199024)(53546011)(6506007)(21615005)(478600001)(6486002)(8676002)(966005)(71200400001)(8936002)(4326008)(6512007)(5660300002)(316002)(66476007)(66446008)(6916009)(91956017)(76116006)(54906003)(66946007)(64756008)(66556008)(2616005)(41300700001)(83380400001)(2906002)(122000001)(166002)(33656002)(36756003)(86362001)(38070700009)(38100700002)(45980500001); DIR:OUT; SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0: ElffKQmIwTWohFgF1/UwAoYZeqKOT4dnhxu7+NQtqxBKYfrMz5B0InNJ5H5PKfq1IAn3UeTCTlL1OiJZqtk/dsq1qLPXU+r0bK2hcQJRVDOQzoJ6YEKqm34aDDP1PvmO7TV4dNG63y2i2dIjIPw+PThGRGX/XqH5QvU2QxcBChpJRkxbeW4jjytjGjPOYIXTQ3JfC7q3ouNiRubECrb5Hzv75JBHdRacr96kfEsZNoJHxrp+jheujONzV20xoNdBsmeQIexj1BVw1e0PvexhqJE2p0EGbh5l1H8QpSpqC3BWxBqoQllUaIyTXvIE/8fGUGrY8knobPJrzOWaNnYmDADFM02SCnOs0xbbCwT6RawZKOJBwFbPXwvdbeX8jGvAyGK8gAR3jJrNw5gmJJ9QbWLSbcWFwk2sGEOyDwlxXy1Isl7wd+QnsAQrY0TS/iQz8i1mdI95KzlxkveQzRqx0vXcpVO18AhtDUCpq5G3UjgKNwSHqEXZ/BonSrLVReI9xzE1ZZopwvaybr1gEkyMfUyQ9Fn3AAIVFR8A5lMDOQ+JDKCVUfhantGUfpNHTX6OsJZFEu13RPY/Lg6wrlJaqgdfx/wRwQtryaqDXMj46Du8Zq6JIHUGfa20OLSkODferpkhOj/w5C9F35Oi3GSaGKSjr7i8oXGADctckC7XBbBCcFs7tzUCNfSMSV7WZhc/qMwLAmJwVG6RcM5Yxa3S4ZXjkuDIq1eNfiMyOKSKqmpadqIUg9T9ZaS9T1/FkCh8nN1OmQJvqvY1XKcs7Rn7rOhk3NEwXiMR26ANGW3sP0opJUcr28pvYTsAL2bfP8SaqSGk5FRInySIztRyEfJP9j3KZVI8ZuF8pQtsxprFggpWogsfHnnI/Ijs8pXJoob4zr0q3m7fKwxOwXIKFTKSLDhjsqENL0ZRNTH7zUqFnR/z/CTcBo4bNcajHE+M+C/7OFZ5EtLgwAhmUlV+Qdh2X5+uNHUY3hsqACVPJ9aYIdAXt4WXiuPSWm+0OCaYurGH4056H2gmdaJTz7HzNhLY/gDcrIkSE5JsJmvnH/s2fp8nP3xuhD2ojgg4XJCm0Rt0F9ydjH7sCs5gDbT3UuicHYJU5T5BBqiwLDH/7seIFMAi9q5eTkxvVhWl/FuLnhQks18lRuXDJFzBLtFQ4T3lEHT/j5taLUObL9odhtKl9JWuqi6AdvYPQAq+zPba3RabOjN3ywmvfLnFu+aIDY9S1MIvWfNX5cWUSxG6MNq2CXK7fbq3UNGjmZjiDY9/jHpimj3XgKrUIVGvl6ZNT5bbXewpf5RBLhkaW4w7lg72EXKbx3lcNfnOLpujNJ0rFEknQgk2TlrIoxN+7fdiJ4HF4ym/H+RyhWeIZUvVmJqTUCbMNlrUe1/RF0sHtrQAnKCLJw2Y8v3FoFA/7O449v6R0R7SCzHNq42YIAiVwBXU8wrw6w96Tfz8w/ZyuI1Gu/JW5zM4tdDuPyoa3cnCLqvO/u0xUQRFb59FN+1YviAKEBVGvDV4lsSJWs7klRkZkjS8uaQW8KCqruJ19H7kZcuNt+evqiUDmE6NZQkn0A125zswZxu/m3iZfRrSFnBh+rZGGvxcbYQ+P8/q2eIh+5gfTwXvT1GQOv1bq1/cnCKhd3QSuKgUoqsXuskZpR+cC19S
Content-Type: multipart/alternative; boundary="_000_0AF349E329164F06A19E211D895AEFA6apnicnet_"
MIME-Version: 1.0
X-OriginatorOrg: apnic.net
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: SYZP282MB3169.AUSP282.PROD.OUTLOOK.COM
X-MS-Exchange-CrossTenant-Network-Message-Id: 1cccbbc4-0716-4bd3-fe2f-08dbe1a9ebfe
X-MS-Exchange-CrossTenant-originalarrivaltime: 10 Nov 2023 05:00:12.7549 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 127d8d0d-7ccf-473d-ab09-6e44ad752ded
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: Sw49r0vlPvJQQKZ42HOB4hrdhD0RsFcslI2usoiZVeyM61w5NHJ1PTxisvDx0KzS
X-MS-Exchange-Transport-CrossTenantHeadersStamped: ME4P282MB1126
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/Zw7BhbC_a9xU3g7d2EXegHxlMFU>
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, 10 Nov 2023 05:00:32 -0000

You ask if using the truncation bit and retrying to TCP mitigates this excessive DNS loss rate. To some extent yes, but at a cost of increased delay and increased query levels. I’m not sure how much DNS detail is useful in this V6ops list, so if I just point to https://www.potaroo.net/ispcol/2020-12/xldns2.html as very detailed measurement report, and summarise the results with the observation that the result is inevitably increased delay because the original DNS query must time out (and DNS timers are generally quite conservative in order to avoid a DOS scenario based on aggressive re-querying) and a visible subset of resolvers fail with TCP (the report on TCP failure as well as other failure measurements can be found at https://www.potaroo.net/ispcol/2020-11/xldns.html)

(If you want to read those reports it makes more sense to read them in the other order: xldns first, then xldns2 next!)




On 9 Nov 2023, at 8:11 pm, Nick Buraglio <buraglio@forwardingplane.net> wrote:



On Thu, Nov 9, 2023 at 10:50 AM Geoff Huston <gih@apnic.net<mailto:gih@apnic.net>> wrote:
The issue of the way that IPv6 handles fragmentation, the use of DNS over UDP and the use of DNSSEC which creates large responses conspire together to make the recommendation in this draft, namely that "Every authoritative DNS zone SHOULD be served by at least one IPv6-reachable authoritative name server” questionable.

In fact I would say that such a SHOULD is operationally highly unwise. In a 2020 measurement study (https://www.potaroo.net/ispcol/2020-07/dns6.html) we had the following result:

"In a measurement performed at the end of April 2020 we performed this experiment some 27M times and observed that in 11M cases the client’s DNS systems did not receive a response. That's a failure rate of 41%. … . How well does IPv6 support large DNS responses? Not well at all, with a failure rate of 41% of user experiments.”

Ooof. That's a harsh number. I am glad you have these measurements and that they're freely available.


So trying to shift the DNS to use an IPv6 substrate is at best foolhardy at this point in time. I wish that folk would actually conduct careful measurements, look at behaviours and understand how the protocols interact with the network before proposing broad mandates that every server SHOULD use IPv6. We just look silly and irresponsible when we propose such actions when the measured reality says something completely different.

Based on your measurements, which are really comprehensive and quite fun to read, BTW, it looks like the percentage has jumped by about 10 points since then (great to see!). How hard is it to run that experiment again?  I hadn't considered DNSSEC and fragmentation in my thoughts, but it doesn't feel like a totally unsolvable problem.  Although admittedly my DNS running days are a few years behind me.
Definitely out of scope for this particular draft, but

If the response is larger than this size, the DNS response packet is truncated such that it is no larger than 512 octets, and the truncation bit is set in the response to flag the fact that the response has been truncated. A DNS resolver should treat this truncation bit as a signal to re-query the server using TCP, so that the larger response can be handled by TCP.

Seems like a not-really-implemented solution, since a requery over TCP would solve that problem, yeah? Or would that introduce enough latency to appear "slow"? Thinking back to my recursive DNS logs from a while ago, I do seem to remember seeing some large packet errors. These caching recursive resolvers are upstreamed to only IPv6 systems, and definitely have DNSSEC enabled. I'll dig and see if I can find the logs.

If this is potentially detrimental, the real question is how do we get from here to there?



On 9 Nov 2023, at 3:04 pm, Nick Buraglio <buraglio@forwardingplane.net<mailto:buraglio@forwardingplane.net>> wrote:

Thanks for writing this, I found it to be well written and clear. I agree and support this, "promoting" IPv6 to the same level as legacy IP is probably a bit overdue in some guidance documents, and this is an important one to address.
One off-the-cuff thought, take it or leave it:
It is briefly mentioned it in the draft, but I would emphasize the transition technologies and the part they play in masking problems. This is becoming more and more exposed as we start stripping away IPv4 and exposing where those tools are hiding gaps in plain sight. This is not likely to change, especially as we get further down the transition path, but the more of those gaps we can fill with simple things like dual stacking a resolver the less technical debt we have to dig out of later. And, as we all probably know, when DNS is broken or slow, it looks like the network is broken or slow, which often leads to things like "IPv6 is breaking the network, turn it off" and we definitely do not want that.

Thanks,

nb




On Thu, Nov 9, 2023 at 7:28 AM Momoka Yamamoto <momoka.my6@gmail.com<mailto:momoka.my6@gmail.com>> wrote:
Hi,

I've submitted a draft to the dnsop wg
DNS IPv6 Transport Operational Guidelines
draft-momoka-dnsop-3901bis
https://datatracker.ietf.org/doc/draft-momoka-dnsop-3901bis/

It has been 20 years since this RFC was published and I think it is time for an update to have IPv6 to a SHOULD for DNS servers.

I will be presenting this draft tomorrow morning at dnsop wg so I would be very grateful if you could give me feedback on this draft.

Best,

Momoka
_______________________________________________
v6ops mailing list
v6ops@ietf.org<mailto:v6ops@ietf.org>
https://www.ietf.org/mailman/listinfo/v6ops
_______________________________________________
v6ops mailing list
v6ops@ietf.org<mailto:v6ops@ietf.org>
https://www.ietf.org/mailman/listinfo/v6ops