Geoff, On Wed, 2025-03-05 at 23:17 +0000, Geoff Huston wrote: > > Personally, I ascribe to this latter interpretation of a BCP > document, and accordingly I think it premature for this working group > to implicitly advocate an operational configuration for DNS resolvers > that today (i.e. "current") is prone to be slower and less reliable.
I really appreciate your commitment to the continued reliability of the DNS. However, by now, I would argue that _not_ supporting IPv6 actually leads to the negative outcome you describe, for example and not limited to, due to the following reasons: - When one takes the CrUX Top 10M domains, and tests every single NSSet with all (un)reasonbale MTU settings (1500,1280+pmtud,1280+no_pmtud, 1280onpath+no_pmtud), the impact of v6 is, overall, negligible; https://data.measurement.network/dns-mtu-msmt/out_data/ For example, for the SERVFAIL rates, we are talking <1% of all NSSets in that data: https://data.measurement.network/dns-mtu-msmt/out_data/2025-03-02/plots/timeout_comp/timeout_comp_all_psl_domains.pdf Similarly, for resolver fall-backs being needed, we are talking <1% as well: https://data.measurement.network/dns-mtu-msmt/out_data/2025-03-02/plots/pcap_comp/pcap_comp_no_dnssec_comp_afi-v4-UDP_client_edns_fallback.pdf Similar when comparing DNSSEC vs. no DNSSEC hosting NSSets; https://data.measurement.network/dns-mtu-msmt/out_data/2025-03-02/plots/pcap_comp/pcap_comp_comp_dnssec-both-UDP_packet_too_big.pdf Interestingly, the v4/v6 difference is smaller for DNSSEC hosting NSSets: https://data.measurement.network/dns-mtu-msmt/out_data/2025-03-02/plots/pcap_comp/pcap_comp_dnssec-both-UDP_client_edns_fallback.pdf https://data.measurement.network/dns-mtu-msmt/out_data/2025-03-02/plots/pcap_comp/pcap_comp_no_dnssec-both-UDP_client_edns_fallback.pdf This means that the negative impact of IPv6 is not as big as claimed in other work. - In general, responses do not have to be _that_ large in most cases; At least not when we did a full-tree exploration of the DNS last year. Mind: Running on that dataset might be a bit time consuming given its ~30TB size. https://data.measurement.network/dns-full-tree-msmt/ For the collection methodology of that dataset, please see the corresponding paper here: https://pure.mpg.de/pubman/faces/ViewItemOverviewPage.jsp?itemId=item_3633648 However, IIRC, similar datasets with a comparable coverage, while not performing full tree exploration, highlight similar results. - Clients, these days, regularly find themselves behind CXLAT etc.; Those, interestingly, are a _prime_ source of (accidental) MTU blackholes while translating back and forth, opportunities to drop state, and other fun ways of abandoning packets. I would seriously be interested into the global costs of CGN/statekeeping hardware if you calculate it pro-rata for the amount of DNS traffic they have to handle; If it is only q1/q8/q9. > Is the purpose of a BCP to proselytise an ideal outcome, even though > it may incur operational penalties in so doing? Or is the purpose of > a BCP to describe what we think is the _current_ optimal operational > approach? That is an interesting (philosophical) question. An example for the first would probably be something that imposes additional operational overhead on the Internet community, asking them to return unused netblocks (given that, at the time, it was not really a thing, i guess) [BCP4]. Similarly, a BCP could be written to clarify a great deal of confusion about, e.g., the use of specific resources, and be equally forward lookingly applicable to IDRP (which we will start using when BGP becomes obsolete; Right after Linux on the desktop.) [BCP6]. Similarly, I am sure that BCP14 was pretty much normative w.r.t. language being used, also introducing operational overhead given that now everyone <bcp14>MUST</bcp14> enclose normative language in tags. When we come to BCP16, we have a document that directly opens with a note that _current_ placement is not ideal, hence prescribing additional effort that needs to be applied to secondary placement. My favorite is probably BCP30, as that document even kind of tells operators to build a full authoritzation system they did not need before, enabling authz on their mail servers, despite mail working _significantly_ better without auth; Especially for users. With BCP30, they would now have to remember passwords, many mail-clients are not even... anyway; I digress. Similar arguments can probably be made about BCP38 and BCP194 (I specifically dig the IXP LAN & uRPF parts); Point being, as far as I see the entries in the BCP series, they tend to be very much about ideal outcomes that might hurt a bit on the way there. And, see the previous point, even if they weren't, and should only focus on cementing a specific 'now' without considering the negative impact that may have on the future development of the Internet, it is not like IPv4 still is smooth sailing, with everyone having a public IP address on all of their devices, and the end-to-end principle as a cherished guardian of good (IPv4) connectivity. -- So, in summary; I disagree with your technical statements based on the above provided data; Please feel free to go through that data yourself if you do not trust my judgement there (all inputs, intermediate steps, and raw data shared, of course); I'd be happy to do the same for your datasets as well, given that both our data seems to be disagreeing on some points. I also disagree with your more philosophical point re: the purpose of BCPs given the lived practice of documents that have been published in that stream in the past. As such, I would argue that not acknowledging the use of IPv6 for recursive/authoritative DNS as a BCP actually makes the Internet worse. Looking forward to further discussions at 122. With best regards, Tobias -- Dr.-Ing. Tobias Fiebig T +31 616 80 98 99 M [email protected] Pronouns: he/him/his _______________________________________________ DNSOP mailing list -- [email protected] To unsubscribe send an email to [email protected]
