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

Mark Elkins <> Fri, 10 November 2023 07:59 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 27D85C17C8A8 for <>; Thu, 9 Nov 2023 23:59:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.198
X-Spam-Status: No, score=-2.198 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, NICE_REPLY_A=-0.091, 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: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id kLdaMwTiMHKL for <>; Thu, 9 Nov 2023 23:59:53 -0800 (PST)
Received: from ( [IPv6:2001:42a0::73]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by (Postfix) with ESMTPS id 10016C17C534 for <>; Thu, 9 Nov 2023 23:59:51 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; ; s=2311; h=Content-Type:In-Reply-To:MIME-Version:Date:Message-ID:From: References:To:Subject:Reply-To:Sender:Cc:Content-Transfer-Encoding:Content-ID :Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To: Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe :List-Post:List-Owner:List-Archive; bh=Q9ZeJ/q4QH/ZzGxK6KLWBEFG4da+JLrLzQnW/+Eh3Tk=; b=n9hLGW8Zc21DSb+2QMM9P7YB3S fj0OPPhVTzwcxRzBeTJpUGgK7bfalP07Ap4GBojSGTNLzEiABUfWXjoU7U6h58/EYxIfud+SIYvry n3GsqZWoV4RBzQRFCYR3SQUx78380UqynQFMW1YdGwBinFJKnPU9nMapdcZ86x7mPbik=;
Received: from [] (port=52422 helo=[]) by with esmtpsa (TLS1.3) tls TLS_AES_128_GCM_SHA256 (Exim 4.96.2) (envelope-from <>) id 1r1MQc-001QTG-1V for; Fri, 10 Nov 2023 09:59:46 +0200
References: <> <> <> <>
From: Mark Elkins <>
Organization: Posix Systems
Message-ID: <>
Date: Fri, 10 Nov 2023 09:59:15 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.6.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: multipart/alternative; boundary="------------368AB5462CB93339D0B2984E"
Content-Language: en-GB
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: Fri, 10 Nov 2023 07:59:59 -0000

Interesting. I administer the EDU.ZA zone. I'm using Algo 13 and some 
EDU.ZA Nameservers have IPv6 addresses.
Looking at Geoff's paper - he gives one particular example.... dig 
+dnssec DNSKEY org
That currently gives me 923 bytes in reply.

Checking EDU.ZA - I get either 427 or 399 bytes - depending on whom I 
ask (with @+ipv6_address)

(Warm fuzzy feeling)

Some years ago, EDU.ZA with Algo 8 was being used as part of a DDOS 
Amplification attack - so I moved to Algo 13

On 2023/11/10 01:15, Martin Huněk wrote:
> 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 <> 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
> _______________________________________________
> v6ops mailing list

Mark James ELKINS  -  Posix Systems - (South) Africa       Tel: +27.826010496 <tel:+27826010496>
For fast, reliable, low cost Internet in ZA: 

Posix SystemsVCARD for MJ Elkins