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

[Mark Elkins <[e-mail]>]

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 <[e-mail]> 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 <[e-mail]>
>>> 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 <[e-mail]>
>>> 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
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/v6ops
>>>>
>>> _______________________________________________
>>> v6ops mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/v6ops
>>>
>>>
>>>
>
> _______________________________________________
> v6ops mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/v6ops
-- 

Mark James ELKINS  -  Posix Systems - (South) Africa
[e-mail]       Tel: [phone] <tel:[phone]>
For fast, reliable, low cost Internet in ZA: https://ftth.posix.co.za 
<https://ftth.posix.co.za>

Posix SystemsVCARD for MJ Elkins