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

Nick Buraglio <> Thu, 09 November 2023 19:11 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id D529FC18FCDB for <>; Thu, 9 Nov 2023 11:11:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.106
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_NONE=-0.0001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=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: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id ayu7cjy7Q9N8 for <>; Thu, 9 Nov 2023 11:11:48 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4864:20::c35]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by (Postfix) with ESMTPS id E6021C18FCCF for <>; Thu, 9 Nov 2023 11:11:43 -0800 (PST)
Received: by with SMTP id 006d021491bc7-581fb6f53fcso687209eaf.2 for <>; Thu, 09 Nov 2023 11:11:43 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=google; t=1699557103; x=1700161903;; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=XYsNDMAzhhSaSt/LoQZKrRi7e99N7QZ6zSNiOdwP7VM=; b=gNTOtATUVebL0vmI32jKQpkAJsrJFZcaEqjk8F2MRvyEnwiFZr3bFhcrPh4rM5UomE /Tc8p3qjBvjBmm50Zyt+TVY/hrSylWDT+H4nTk1DOwwI0xvxaQAYa6yAVjLVhFchkaO0 fqwgOQe8dWXVJts8wVjIiFwlJHkTQePXFqvrI=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20230601; t=1699557103; x=1700161903; 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=XYsNDMAzhhSaSt/LoQZKrRi7e99N7QZ6zSNiOdwP7VM=; b=smXHTvprkFuLqtHEvmzXxv9yT9Dp8pZqHelAhh/2lLDY9ZUaNvB/6tl3rlj/ouZ0G9 cfKovCogEUu9rdrJNhT4Xhb334foRUDnOEq4u4CRzIBLY0dVQqy/Dnc0cZUUkTFd/Gs4 cjACqYtr7uNzkFWsW/u5gJVijTDs97fdR/4wMvYGUFSL8OASfcGk0faqW5NJ/MDSVPDQ F2/zVD4npcRm6Y3RYxuC/UHOxK6TSjXwGnaeu5Jh+j1zULWItxGOUmWs9qOwPOyEIxZq nPRyBpvxdqCLxpVfVAC7n2Fg7GIqBGsZoO+1+UqtxRF20VsXjADiCRIr+zsfh+S58pZE TfKg==
X-Gm-Message-State: AOJu0YywznW6axJDcIvtwIUKqmnIWqB6ZyG403eZRWQHbgckuThGjtSH 9mnrv5Un6fOs89xi3Y87B5ThWTZ+0ge/inzj2EpJ/w==
X-Google-Smtp-Source: AGHT+IGGfAKxF2iuwS5AFHYKYShTJtT/7Kjmu+kmpIqVnHZKkfTmzQz/MgSi9cR/Z6xl3KOyA+eXAV0jDHZ1b2HbwZo=
X-Received: by 2002:a05:6358:6e95:b0:16b:a950:8e3a with SMTP id q21-20020a0563586e9500b0016ba9508e3amr1154925rwm.0.1699557102803; Thu, 09 Nov 2023 11:11:42 -0800 (PST)
MIME-Version: 1.0
References: <> <> <>
In-Reply-To: <>
From: Nick Buraglio <>
Date: Thu, 09 Nov 2023 13:11:31 -0600
Message-ID: <>
To: Geoff Huston <>
Cc: Momoka Yamamoto <>, list <>
Content-Type: multipart/alternative; boundary="00000000000063744a0609bcf9e8"
Archived-At: <>
Subject: Re: [v6ops] New draft at dnsop a bis for DNS IPv6 Transport Operational Guidelines
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: v6ops discussion list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 09 Nov 2023 19:11:52 -0000

On Thu, Nov 9, 2023 at 10:50 AM Geoff Huston <> 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 (
> 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 <>
> 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 <>
> wrote:
>> Hi,
>> I've submitted a draft to the dnsop wg
>> DNS IPv6 Transport Operational Guidelines
>> 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 mailing list