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

Hi dnsop list

I sent an email to v6ops to notify my draft draft-momoka-dnsop-3901bis
yesterday.
Geoff gave very informative concerns and this started a discussion on the
thread on v6ops that should have been on the DNSOP list so I am sending
part of the discussion here.

the whole thread can be found here.
https://mailarchive.ietf.org/arch/msg/v6ops/HOYM-6maxLDza1kv3JrEJEYymUA/

Thank you to all who have given useful feedback.

Momoka

On Fri, Nov 10, 2023 at 7:58 AM Geoff Huston <[email protected]> wrote:

> Hi David
>
> My reaction is that this would make things worse, not better. But as in
> many things setting up the scenario and testing it with real resolvers at
> the other end is perhaps the best way to get to what actually happens, so
> my opinion here is probably just that - a personal opinion, as I have not
> set up this scenario into a large scale measurement system.
>
> The combination of UDP, IPv6 and large payloads is a very challenging
> scenario, and the DNS has no magic solutions for this!
>
> Geoff
>
>
>
> On 10 Nov 2023, at 7:52 am, David Farmer <[email protected]> wrote:
>
> Geoff,
>
> An associated draft draft-momoka-v6ops-ipv6-only-resolver discusses an
> IPv6-only recursive DNS server communicating with an IPv4 authoritative DNS
> server through NAT64. Considering this scenario, the large DNS response you
> refer to will be fragmented on the IPv4 side of the conversation. Now,
> RFC6146 discusses two ways for NAT64 to translate fragments, reassemble the
> packet, and then translate it or translate each fragment.
>
> Do you think this scenario helps or frustrates the situation you refer to,
> and does it matter how the fragments are translated?
>
> If the IPv6-only recursive DNS server and the NAT64 translator are part of
> the same network, it would seem likely to increase the success rate for the
> IPv6 fragmentation process. Instead of the IPv6 fragmentation process
> occurring across the Internet.
>
> Thanks
>
> On Thu, Nov 9, 2023 at 10:50 AM Geoff Huston <[email protected]> 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.”
>>
>> 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 <[email protected]>
>> 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 <[email protected]>
>> 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
>>> [email protected]
>>> https://www.ietf.org/mailman/listinfo/v6ops
>>>
>> _______________________________________________
>> v6ops mailing list
>> [email protected]
>> https://www.ietf.org/mailman/listinfo/v6ops
>>
>>
>> _______________________________________________
>> v6ops mailing list
>> [email protected]
>> https://www.ietf.org/mailman/listinfo/v6ops
>>
>
>
> --
> ===============================================
> David Farmer               Email:[email protected]
> Networking & Telecommunication Services
> Office of Information Technology
> University of Minnesota
> 2218 University Ave SE        Phone: 612-626-0815
> Minneapolis, MN 55414-3029   Cell: 612-812-9952
> ===============================================
>
>
> _______________________________________________
> v6ops mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/v6ops
>

_______________________________________________
DNSOP mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dnsop