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

Martin Huněk <martin.hunek@tul.cz> Thu, 09 November 2023 23:15 UTC

Return-Path: <martin.hunek@tul.cz>
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 037F0C17DC0C for <v6ops@ietfa.amsl.com>; Thu, 9 Nov 2023 15:15:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.108
X-Spam-Level:
X-Spam-Status: No, score=-7.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, 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=tul.cz
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 npc1gmo_5dZq for <v6ops@ietfa.amsl.com>; Thu, 9 Nov 2023 15:15:24 -0800 (PST)
Received: from bubo.tul.cz (bubo.tul.cz [147.230.16.1]) (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 5C49FC17DBFA for <v6ops@ietf.org>; Thu, 9 Nov 2023 15:15:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at tul.cz
Received: from asclepius.adm.tul.cz (unknown [IPv6:2001:718:1c01:11::1:15]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by bubo.tul.cz (Postfix) with ESMTPSA id 70ED018050DD5 for <v6ops@ietf.org>; Fri, 10 Nov 2023 00:15:19 +0100 (CET)
DKIM-Filter: OpenDKIM Filter v2.11.0 bubo.tul.cz 70ED018050DD5
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tul.cz; s=tul2021; t=1699571719; bh=7XKomFHNFKCEk/M4NCuEHSoKMQhaWBaBOLjSyCgHASw=; h=From:To:Subject:Date:In-Reply-To:References:From; b=gdwSIYMgT2CNgd0oY+1g2bsMpMQH6lyQYe++uSmtWadZ/ly4GPti1TSVaesq/OtGv 9dYuKQX/mD2G6xqSEtC+aauLIzPTfwX8AOvbJCV7nyMnFGfQywQAY9VY8XacOebcgz durPGdGnrlO84l9l4NqNWF1ivmr7gdL3mss+7bcjeIjQcPiXy5VjRAlxp0+2+Qkave Rzi/HtsvnLYuzacAcrmk5mXhEklwygI1ssr4/ACv9n1QbPPjWGaNbmVi5xWuY4k7n3 QFb3Qul6/KCy0AVJQQxfnKRsm+gB8r1LMdE1MdlgbOx9sofP+eWnQc9oLMKNiZbb97 95mKdbwEtN3Lg==
From: Martin Huněk <martin.hunek@tul.cz>
To: v6ops@ietf.org
Date: Fri, 10 Nov 2023 00:15:07 +0100
Message-ID: <2147103.zmpluvigLD@asclepius.adm.tul.cz>
Organization: Technická univerzita v Liberci
In-Reply-To: <CACMsEX-wR9T2BtPqY+wmEObB9YjSE-NezK2jSLg13Xu2faTapw@mail.gmail.com>
References: <CAD9w2qYhCmkp2bOiGet4DY4AmbGHXj7r_reMibCK18rR8ivbMQ@mail.gmail.com> <B57D7BFA-ECE9-4F23-9324-7591E91F457B@apnic.net> <CACMsEX-wR9T2BtPqY+wmEObB9YjSE-NezK2jSLg13Xu2faTapw@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="nextPart3007758.MaSQosenkx"; micalg="sha384"; protocol="application/pkcs7-signature"
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/BVs8dnJnOGzox3RYCMMeJvhWI-4>
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: Thu, 09 Nov 2023 23:15:29 -0000

Hi,

The presented data are somehow disturbing. Could it dependent on the DNSSEC algo used by the authoritative server? We can see the shift from algo 8 to algo 13 which produces smaller replies ...

However, without the IPv6 address on at least one authoritative server, the domain would not be reachable/visible for the IPv6-only network. What is better?

Regards,
Martin

Dne čtvrtek 9. listopadu 2023 20:11:31 CET, Nick Buraglio napsal(a):
> 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.”
> >
> 
> 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>
> > 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
> >
> >
> >
>