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

Fred Baker <> Mon, 13 November 2023 18:09 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 63DC0C15152E for <>; Mon, 13 Nov 2023 10:09:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.201
X-Spam-Status: No, score=-1.201 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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MIME_HTML_ONLY=0.1, MIME_HTML_ONLY_MULTI=0.001, MIME_QP_LONG_LINE=0.001, MPART_ALT_DIFF=0.79, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, T_SCC_BODY_TEXT_LINE=-0.01, T_SPF_TEMPERROR=0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=no autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 3dv0FmTvs03b for <>; Mon, 13 Nov 2023 10:09:32 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4864:20::1035]) (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 4144AC14CEFF for <>; Mon, 13 Nov 2023 10:09:27 -0800 (PST)
Received: by with SMTP id 98e67ed59e1d1-28098ebd5aeso4226222a91.0 for <>; Mon, 13 Nov 2023 10:09:27 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20230601; t=1699898967; x=1700503767;; h=to:references:message-id:cc:date:in-reply-to:subject:mime-version :content-transfer-encoding:from:from:to:cc:subject:date:message-id :reply-to; bh=uRX+aziV6NOrt+Fea+kzo6hSl17PQJACH9AzWCgTVoQ=; b=YYom9wutVaHs17lPaQGTKozUNrtwNmYWDn49ej1deuxdd2yGt6ywqJaX5dJ2ZEwK9i eLDzEJox3qf3WA+lYvrrerIvwIw8CnczBgVCga1zC/HcHgtMl96WKHzBG62mPFthiB2j IlgRl39o7mmThS5lNtws7PkYFZR74C65zKaeZ9FpDEbokElu9vj9MkO8DOsyMtY8kFzk PhgKjrpbVvNcHu+EHph8429Ezm4egm0Ezuofn+BkRWbQfDK8It7Dt7pDrCAwKdVHopLq j9fAzMzT4+9fYbbtSCwuIVMBWbWZqbQ4YCi6Pn0J1SG4z/O06cmSC/+8zrpVJx7pYdu4 w45A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20230601; t=1699898967; x=1700503767; h=to:references:message-id:cc:date:in-reply-to:subject:mime-version :content-transfer-encoding:from:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=uRX+aziV6NOrt+Fea+kzo6hSl17PQJACH9AzWCgTVoQ=; b=mfvjsCXioujA7mz3C3koFtdbiUTE4FVpLaJdhhYONCCknxSz74oGR1O/zMDKWatZ3b eD/KoOo5c1Oee13HJC/boBvh7efbChDWkPxWOzTwvQPe6l3LGD3/PJ5aAuLSbvlI2BeP WMEcyNx7UP9upYH3vPsUyGHvgbikDFcDQ/lNjl5CMpEUUCglZGqCnt47K2e0r1ZuRd5z OwMMFZLn0i9PJrfe+AjExkyZIE6yyofpt8srOuh00HOHajQCzBXm+ZFENhyLNXyh8MFE f7IuXugSGOtdWvprtUSYZgwszgOV7sDA1jkmZtOUd/cM5ioJrp1wCpmkRvw62remFgVm dsNw==
X-Gm-Message-State: AOJu0YyziFYu0Z9m+LQbpTLfL8nM95KQw7IoWUt9k9ecWjEW55+f6SlL ZDp5AeJqiW1BAN+A3IG9vFDcSpA/OfM=
X-Google-Smtp-Source: AGHT+IGZA9vpTD84ffR3Z32qXzbxBOaRGfg/CiLm6ZYEWYuaRXzVRnr3gyt29TJWRjW25zHzQ6JYCg==
X-Received: by 2002:a17:90b:4f8b:b0:263:f630:228f with SMTP id qe11-20020a17090b4f8b00b00263f630228fmr8313791pjb.23.1699898967142; Mon, 13 Nov 2023 10:09:27 -0800 (PST)
Received: from ([2600:8801:d605:5e00:75dc:2b88:a40d:2dd5]) by with ESMTPSA id cp18-20020a17090afb9200b0027909a8994fsm5845830pjb.13.2023. (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 13 Nov 2023 10:09:26 -0800 (PST)
From: Fred Baker <>
X-Google-Original-From: Fred Baker <>
Content-Type: multipart/alternative; boundary="Apple-Mail-1AF557E6-25FA-4DB1-9735-5C741D892BA8"
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (1.0)
In-Reply-To: <>
Date: Mon, 13 Nov 2023 10:09:15 -0800
Cc: Nick Buraglio <>, list <>
Message-Id: <>
References: <>
To: Geoff Huston <>
X-Mailer: iPhone Mail (21C5040g)
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: Mon, 13 Nov 2023 18:09:36 -0000

Thought: IPv6 is supported by the root servers, which is a case in point that the technology works for DNS.

Sent using a machine that autocorrects in interesting ways...

On Nov 9, 2023, at 8: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 (" rel="nofollow"> 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 <> 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. 



On Thu, Nov 9, 2023 at 7:28 AM Momoka Yamamoto <> wrote:

I've submitted a draft to the dnsop wg 
DNS IPv6 Transport Operational Guidelines
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.


v6ops mailing list" rel="noreferrer nofollow" target="_blank">
v6ops mailing list

v6ops mailing list