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

David Farmer <farmer@umn.edu> Fri, 10 November 2023 06:52 UTC

Return-Path: <farmer@umn.edu>
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 33281C18E528 for <v6ops@ietfa.amsl.com>; Thu, 9 Nov 2023 22:52:40 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, 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 (2048-bit key) header.d=umn.edu
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 fVgTFzK4WaeC for <v6ops@ietfa.amsl.com>; Thu, 9 Nov 2023 22:52:35 -0800 (PST)
Received: from mta-p8.oit.umn.edu (mta-p8.oit.umn.edu [134.84.196.208]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A9A80C18E1A5 for <v6ops@ietf.org>; Thu, 9 Nov 2023 22:52:34 -0800 (PST)
Received: from localhost (unknown [127.0.0.1]) by mta-p8.oit.umn.edu (Postfix) with ESMTP id 4SRTz55JK8z9vpxp for <v6ops@ietf.org>; Fri, 10 Nov 2023 06:52:33 +0000 (UTC)
X-Virus-Scanned: amavisd-new at umn.edu
Received: from mta-p8.oit.umn.edu ([127.0.0.1]) by localhost (mta-p8.oit.umn.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e19e2beqjHgp for <v6ops@ietf.org>; Fri, 10 Nov 2023 00:52:33 -0600 (CST)
Received: from mail-ej1-f71.google.com (mail-ej1-f71.google.com [209.85.218.71]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mta-p8.oit.umn.edu (Postfix) with ESMTPS id 4SRTz50zf5z9vpxm for <v6ops@ietf.org>; Fri, 10 Nov 2023 00:52:32 -0600 (CST)
DMARC-Filter: OpenDMARC Filter v1.3.2 mta-p8.oit.umn.edu 4SRTz50zf5z9vpxm
DKIM-Filter: OpenDKIM Filter v2.11.0 mta-p8.oit.umn.edu 4SRTz50zf5z9vpxm
Received: by mail-ej1-f71.google.com with SMTP id a640c23a62f3a-9de267de2a0so131000166b.3 for <v6ops@ietf.org>; Thu, 09 Nov 2023 22:52:32 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=umn.edu; s=google; t=1699599151; x=1700203951; darn=ietf.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=p7opGr4W237oXOdAeGxZjAdWifSiVgn3eQyYjQNcIvg=; b=IKv4FfHtjMvt8WSchjNc4lZKsNkTWFQ1byTxljJGhzZQEbOHfzL0u43sAeK0HibMIB pKy8HSBlSxND9GZ3Ygh11xxkGgnzjXt1Yzs5SxdNRX5Bcc0DI0uwAONxVEy0TDzodt/T yUsEeahM7v2cOZw0zo93hSXMjMwXcQzk6RQmR9iq68elAknByinW7Bl+bgbA7jlIpLYv Nf3sL27gnLnoZHrMcPuY8eGWFTogLfkeRmX2RhiXVwPMJ3VgLzsQmWJ52PG8NB+ZU4uN lkG4YS+hv72tp7H8FFqTqYMjAfOoRoJCOediQcbjaC07KAgbhcX3PZBz0ONKUL+7f65A vTqQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1699599151; x=1700203951; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=p7opGr4W237oXOdAeGxZjAdWifSiVgn3eQyYjQNcIvg=; b=WNPXqmWyeQABxWXP8g83fe0Vl3PGfEXgn9tNwZbf5LLyhSgpypCGh1pyV0zxWMYwNe hRkSrv/LKMRJY+YLOzou/4St8yKzInORW6CbYZaLDedG1hSWlh3BFszHOc8yJn9cHH98 N06Uapi9aC/5YYU/Y//CmBnv+qorjFc8Mu3Gy24mASoab7jCynxXDhMXK7naVsX3Jjdr jPXqmRcLs7cSfMgln6g9OryrZtUu0NsaltcwbJ460HzA81DO87WKE5P1kaCOSNJuWdTX KESE2ZEMNxw6PM6Yve/FbJS+zGB/VrgLoWCZv5YQFSW/67z5+++QJ5USNx/2seqQzrBl UO/g==
X-Gm-Message-State: AOJu0Yxhg8+NoviAB2gPOKOJ90+Kgplmf5EgB6JN6Z17+Rp27Lbq9zBK KC/n+wKVQupiFPldBSj8Vr7CMPMwIY4oG92ifSZKHFRWtcrbkb7RalXpoHXQo+fUDI83NT3nt7m nW7+sRFHp3PyxMmFT+pGT+FlEgp9JKq/pa6b6
X-Received: by 2002:a17:907:744:b0:9de:32bb:faab with SMTP id xc4-20020a170907074400b009de32bbfaabmr5851287ejb.32.1699599150904; Thu, 09 Nov 2023 22:52:30 -0800 (PST)
X-Google-Smtp-Source: AGHT+IFfH3wRkbkJoeznVSW6dcPSmGA2B75wfyYsDs2bJWf63GEPse8Qz/TSBDv35JHw0jD0n7itujmePK3gUgZzmWw=
X-Received: by 2002:a17:907:744:b0:9de:32bb:faab with SMTP id xc4-20020a170907074400b009de32bbfaabmr5851272ejb.32.1699599150526; Thu, 09 Nov 2023 22:52:30 -0800 (PST)
MIME-Version: 1.0
References: <CAD9w2qYhCmkp2bOiGet4DY4AmbGHXj7r_reMibCK18rR8ivbMQ@mail.gmail.com> <CACMsEX8wQB3B1w2TOpPTjZoADYf5ybrKhpOXmo=iuOhUFJbJ5g@mail.gmail.com> <B57D7BFA-ECE9-4F23-9324-7591E91F457B@apnic.net>
In-Reply-To: <B57D7BFA-ECE9-4F23-9324-7591E91F457B@apnic.net>
From: David Farmer <farmer@umn.edu>
Date: Fri, 10 Nov 2023 00:52:13 -0600
Message-ID: <CAN-Dau2rCQR=CJvwG96BvyY-p1SWoByQUGQ=bQo_kS6fKLUvyA@mail.gmail.com>
To: Geoff Huston <gih@apnic.net>
Cc: Nick Buraglio <buraglio@forwardingplane.net>, list <v6ops@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000a0c35d0609c6c307"
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/36z1dB27rJIoLumuCNa-HBp7si8>
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:52:40 -0000

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> 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>
> 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>
> 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
>> https://www.ietf.org/mailman/listinfo/v6ops
>>
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops
>
>
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops
>


-- 
===============================================
David Farmer               Email:farmer@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
===============================================