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
