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

Geoff Huston <gih@apnic.net> Fri, 10 November 2023 06:58 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 167C0C17DBE1 for <v6ops@ietfa.amsl.com>; Thu, 9 Nov 2023 22:58:33 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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_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 Ge4Oi0i1175O for <v6ops@ietfa.amsl.com>; Thu, 9 Nov 2023 22:58:28 -0800 (PST)
Received: from AUS01-SY4-obe.outbound.protection.outlook.com (mail-sy4aus01on2081.outbound.protection.outlook.com [40.107.107.81]) (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 E8BD2C17C526 for <v6ops@ietf.org>; Thu, 9 Nov 2023 22:58:27 -0800 (PST)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=alGCIuluk/Sf9/DjcxMAKTXzK8BVCH/CiZVDrn3fNEmmNEQ5FdY5BOI6CS6egWIyioV7fuTh8IPevxk4SHZuyrSB3BG5K33x4aYRftBisBfNNomnpwv0Q2NfKobK41EVPCg7+Q8t0rzMU7NM3IPSYmCWgi0z9RXdVEXrt4Ar3N1K+GdlDEZfVFK9S3skxhpGHRVLgn3biUGKXjyvXkXQhziSD/Q3TqYR+rpZEueDDiuwlfWmJjFr8JMgu/ZNtG38ru08KZs1qG55i7cBVfy1/2/6xFyJYF+r6n22L+RQD7WSpdehDpHed1R3sdRzASl/HHWQkagO+hC1ufvMFBQkhA==
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=PrUyAbve+j/Aw+wm5Jaqk+twJXLhc15dtPQUCO6v/uI=; b=eNskMoHvoosgwyuE4ts4foLIJhmR5GQ5ovD7ijXC+AEUkzuGzOQkc8zCpG8ML334ZBBsY2aRTrYWIthhS/+QNy6P6GzmICpIEFy7KlulS4lwyIslM1/zwVnhHaXyYF1RdCDAKFJuGNkzNX58orLJkuLjLjQapSh/djEzIagGIrDTNPa/Wzbdgteq9w+Ru1tlGJhkPgC/T/yN/LenrY0SLpQMXpjb+sN0nVxCMBNuWkk/2X+UH+wEO6BWWNug4pT8HU0fL1oj+km/vrTVuWI5FB/vdf/qQ1pWpgSmxDBhBjbGQbNrNTufPSpHa40xKMRxTzkX+Gb4l7+LNpWMzCd9Kw==
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=PrUyAbve+j/Aw+wm5Jaqk+twJXLhc15dtPQUCO6v/uI=; b=Fu0J+e7RZOW2FmWLuQyeyX92H/JfMzrk+L5XCuAJPLeTOMnFMDI2IsRuwQBJ4S02mQVrrcA8eDMiJgD9sFo+vOC73x0d36koNdpe/u3wv211+eyPMN692MNRZxarvPAyS8Dt5IWQUsoaH27PcG5cEg3rdgEvrmO6gkDCddjIlf8=
Received: from SYZP282MB3169.AUSP282.PROD.OUTLOOK.COM (2603:10c6:10:176::18) by ME0P282MB4301.AUSP282.PROD.OUTLOOK.COM (2603:10c6:220:227::13) 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 06:58:22 +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 06:58:22 +0000
From: Geoff Huston <gih@apnic.net>
To: David Farmer <farmer@umn.edu>
CC: Nick Buraglio <buraglio@forwardingplane.net>, list <v6ops@ietf.org>
Thread-Topic: [v6ops] New draft at dnsop a bis for DNS IPv6 Transport Operational Guidelines
Thread-Index: AQHaExC9b2onPeoBBkiWl+bgdD+8xbByBSuAgAAuPoCAAOtTgIAAAauA
Date: Fri, 10 Nov 2023 06:58:22 +0000
Message-ID: <03FBC196-0A24-40BE-A190-D89221346745@apnic.net>
References: <CAD9w2qYhCmkp2bOiGet4DY4AmbGHXj7r_reMibCK18rR8ivbMQ@mail.gmail.com> <CACMsEX8wQB3B1w2TOpPTjZoADYf5ybrKhpOXmo=iuOhUFJbJ5g@mail.gmail.com> <B57D7BFA-ECE9-4F23-9324-7591E91F457B@apnic.net> <CAN-Dau2rCQR=CJvwG96BvyY-p1SWoByQUGQ=bQo_kS6fKLUvyA@mail.gmail.com>
In-Reply-To: <CAN-Dau2rCQR=CJvwG96BvyY-p1SWoByQUGQ=bQo_kS6fKLUvyA@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_|ME0P282MB4301:EE_
x-ms-office365-filtering-correlation-id: 5f6b09a5-690e-420b-67aa-08dbe1ba6d93
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: TpewuaTY/Pl+X1If/sT8eMNncJYOVv3zYx4qSPjUEIRt+5f3y09JEsXOm/7CNxFHLms45rYSJmhkJxvv6egqdQnNhefINSpIsE4czPpH+AUdMXjhNdZ1fxCPgcUIuxkHrmOHquyEx97gs8jVEBOcQuIuIM3sOyVZGDUE7/7Kt62DUsNYxFh7soTioXFpBfwf+58e6DXuEHl8xeOEpn7gUy6hpDoUk/KUDO4R6In9c1J5Sg2O+3HV/rk5oGYMU4A6tyQMIEEl817gupz+fLL35xhZtl1ftUOK8qHD+6zHL/PxVLPrSgixDGnVfKgcATOaiNiF1/aWbF37Ta9zG4J6PSvIU8sEHwJIInljCDLUeOTRqb5dbAXBPLfVl4gunMUYdz2fuiwQudhgvIe0K07ajT7olYQD3YZwK5tGMZEUoyVg5m1BaVKoiAR5k81/e5LFw0ZMn2/h4KKzgds4xZUzgUQqdrJlSXzWnYZpFO8ZKV+Ako71H4oYM52mQb9qnVDuWt9pbW5vQKyWF2ohQjQbgvhijaHJnxRe3gBOw7FzQnhqHiaZ/QoYde0swsX8k+LARxMokDkYD6st5Vx4Bqa53xhtdEgdIgi1ORhTHsBGWDIiJqz0Z6LImmNnXzDYws85
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)(39840400004)(136003)(396003)(376002)(366004)(346002)(230922051799003)(64100799003)(451199024)(186009)(1800799009)(316002)(478600001)(966005)(91956017)(71200400001)(4326008)(8936002)(8676002)(6486002)(76116006)(66574015)(53546011)(5660300002)(6506007)(21615005)(83380400001)(41300700001)(66476007)(64756008)(66946007)(66556008)(54906003)(66446008)(6916009)(2906002)(2616005)(38100700002)(166002)(122000001)(86362001)(33656002)(40140700001)(36756003)(38070700009)(6512007)(45980500001); DIR:OUT; SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0: 2/yQWDkI25KIUeX4azU9XgxH2dlNP0tiTE2EaEMRnSHtVRQZ1ZIIcppdcK/5eWtF4cisOxMD/U2/P3TrmpCuUeIA1VJVftesPnkeIHv4y03VrUjpZh0HeRVuVJnPmXsRxKhakD/Qkl97o/+b4f5zFz0fuHDUgEqA0FMoTg3bY5YlrWMLuDIsyj7WXxlo7NFdPHTanKybjp5pmHmqlpCFeXNQ+N8tNaMzrzRQvf+Mt+cSpk9h1YuBbDx/dBAjL4+bCbuJCylVQgF49P4/61GqyLp8h1mJHRiamP0fJ2ZSkOSjMF4A/IUtxsmbgflcgfe0t5CmOhe+nuoUDaGWphMfQLfltfoKZB0wek5RfW8JgS/t1p5QulYMqUJl8E7FsX55+8/o7CK9WBkGWV07C3RKMGghMbQ3Chu79LZOjQCqa9IoXu8cDE0bMNnNZjtZqWefvn75OqRORFWHmkcPrFDfHhfNu4GkdN84gu/CprP30ce+oFNDqASINXcU36FhyGmaplCOJ5qYCbxry3XYa4gnOwfRiSTZAZI3xbk17Zs+ziiQqBLai17H1b7TR2rdnhBYWkP0xAaSDUdbpMP1h2NnPLtEtpZBN6tuDHtnC8Bk2rCxZJSLKlmm0JOH6IebTidJH2Y676mWkZd7dR+i257k3QmuQklZxrpK4kY2utmcmBqQBfqLhOVkuzrN+fPnNWe/9O/Q3mJG+UhKLN+jMs4a5iNgSKFARjj/2pacWOGGHiX/J/raUPb4yvhIadHzl09EdvmWZmq3O6Dje/VcfiYYolLQP45dYZh3z2k0gevVl2q2dyDWDT1rfvHWcJEg/T8EPxABOFxATB5BYhEBADdc4RIDj2V8Z08hzgJgHgTBinjhhaIMCogY1uOz2S3R10wsEoz/r0vpsefGHmoTvyiCk8oXphQIRssYwAJVdw1VhUfadZEyPbbIb8AmKnSe0gyUQSUswc05wA2ZZokCmE++cCxq4sGgaPr5u7er9DO5dN8iBjiOY/VOTKrMg5clUE5Rmj6QA0fuik/mmneTfLFMT0NwTPivrI0uOkNgfAG7exwP/sK1e7e+UlttpPfZEWwfBmVqVQtp4FW68MrHkMM9xxnHRF59cC/NQ9eaIv46YKTsbeVsvcEyVO44GfRH1/CKsbhfy/fxQsuvylI4XExCv6htPy0gfDoXOFbRJquOAxRM//WHrhJKiT57k+jp7707aQ4dx2z8AeS8e6KXNn2BkwgqDb/nBcL7qO2hb9e4E4bJIvv08wpDreN7EdGGSH/EBSZlUS2QPcWlIyWQnTW99LLvYgavnAqHd8afxjepCiF0RyPbLSjpiTeyt+g/3oiqyqGgY2F/oLEwYuO1ZWoKEPAepzvrQ27ds0dk+ZR9tWig7/KrvmGZWWcX5noRTWhgnY8MDR7nNCVS9olYPUA3koAS+QR7aBsbgqu+r5c59MuontdtNjnAIzP8yATyRuIsMvyuaPsELtFiPS42re7/WKN3pdCygDRv8nkeu+/b56QCkjHV7SsqmWWEAiv9fcKaJm2F9ApX75bVJNqOj+PSdn0l2JxfeJEA80SLPj0Oyq9oGkyulw7L2dzaSOu9247B56XST9uVCMsVnpmM3MPvFOs13/5LxVKGHLsKxtK4FXtbVx3he3adqBX6sHtlSPL7
Content-Type: multipart/alternative; boundary="_000_03FBC1960A2440BEA190D89221346745apnicnet_"
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: 5f6b09a5-690e-420b-67aa-08dbe1ba6d93
X-MS-Exchange-CrossTenant-originalarrivaltime: 10 Nov 2023 06:58:22.1281 (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: s9dfZZdyt5+T5jMoIrU6Rf6rsoRSupqKjkyDM4kTCmKitfT7RRqFg408h3nSc9DY
X-MS-Exchange-Transport-CrossTenantHeadersStamped: ME0P282MB4301
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/U7aTOdY993U_2hNy1ZZHaXu8T6s>
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 06:58:33 -0000

Hi David

My reaction is that this would make things worse, not better. But as in many things setting up the scenario and testing it with real resolvers at the other end is perhaps the best way to get to what actually happens, so my opinion here is probably just that - a personal opinion, as I have not set up this scenario into a large scale measurement system.

The combination of UDP, IPv6 and large payloads is a very challenging scenario, and the DNS has no magic solutions for this!

Geoff



On 10 Nov 2023, at 7:52 am, David Farmer <farmer@umn.edu> wrote:

Geoff,

An associated draft draft-momoka-v6ops-ipv6-only-resolver discusses an IPv6-only recursive DNS server communicating with an IPv4 authoritative DNS server through NAT64. Considering this scenario, the large DNS response you refer to will be fragmented on the IPv4 side of the conversation. Now, RFC6146 discusses two ways for NAT64 to translate fragments, reassemble the packet, and then translate it or translate each fragment.

Do you think this scenario helps or frustrates the situation you refer to, and does it matter how the fragments are translated?

If the IPv6-only recursive DNS server and the NAT64 translator are part of the same network, it would seem likely to increase the success rate for the IPv6 fragmentation process. Instead of the IPv6 fragmentation process occurring across the Internet.

Thanks

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.”

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.


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

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


--
===============================================
David Farmer               Email:farmer@umn.edu<mailto:Email%3Afarmer@umn.edu>
Networking & Telecommunication Services
Office of Information Technology
University of Minnesota
2218 University Ave SE        Phone: 612-626-0815
Minneapolis, MN 55414-3029   Cell: 612-812-9952
===============================================