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

Mark Elkins <mark@posix.co.za> Fri, 10 November 2023 07:59 UTC

Return-Path: <mje@posix.co.za>
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 27D85C17C8A8 for <v6ops@ietfa.amsl.com>; Thu, 9 Nov 2023 23:59:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.198
X-Spam-Level:
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: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=posix.co.za
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 kLdaMwTiMHKL for <v6ops@ietfa.amsl.com>; Thu, 9 Nov 2023 23:59:53 -0800 (PST)
Received: from relay.vweb.co.za (relay.vweb.co.za [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 ietfa.amsl.com (Postfix) with ESMTPS id 10016C17C534 for <v6ops@ietf.org>; Thu, 9 Nov 2023 23:59:51 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=posix.co.za ; 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 [165.255.87.210] (port=52422 helo=[160.124.48.9]) by relay.vweb.co.za with esmtpsa (TLS1.3) tls TLS_AES_128_GCM_SHA256 (Exim 4.96.2) (envelope-from <mark@posix.co.za>) id 1r1MQc-001QTG-1V for v6ops@ietf.org; Fri, 10 Nov 2023 09:59:46 +0200
Reply-To: mje@posix.co.za
To: v6ops@ietf.org
References: <CAD9w2qYhCmkp2bOiGet4DY4AmbGHXj7r_reMibCK18rR8ivbMQ@mail.gmail.com> <B57D7BFA-ECE9-4F23-9324-7591E91F457B@apnic.net> <CACMsEX-wR9T2BtPqY+wmEObB9YjSE-NezK2jSLg13Xu2faTapw@mail.gmail.com> <2147103.zmpluvigLD@asclepius.adm.tul.cz>
From: Mark Elkins <mark@posix.co.za>
Organization: Posix Systems
Message-ID: <d1c58128-a529-8ba1-4298-26a3081bd336@posix.co.za>
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: <2147103.zmpluvigLD@asclepius.adm.tul.cz>
Content-Type: multipart/alternative; boundary="------------368AB5462CB93339D0B2984E"
Content-Language: en-GB
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/paskBrATbUHRhNT7yrqj4L-gdvY>
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 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 <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
>>>
>>>
>>>
>
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops
-- 

Mark James ELKINS  -  Posix Systems - (South) Africa
mje@posix.co.za       Tel: +27.826010496 <tel:+27826010496>
For fast, reliable, low cost Internet in ZA: https://ftth.posix.co.za 
<https://ftth.posix.co.za>

Posix SystemsVCARD for MJ Elkins