> the deployment of IPv6 has changed significantly in that time
But the behaviour of IPv6 when used as the transport for DNS over UDP has not The draft notes that IP fragmentation has reported to be fragile, large DNS payload sizes should be avoided and TCP fall-back should be used in its place. The draft fails to note the isses of the additional time taken in signalling truncation and setting up a TCP session for re-query, nor in the non-negligible DNS-over-TCP failure rates that are part of today's DNS [1]. 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? If it's the former, then the draft certainly achieves that, although the term "Best Current Practice" appears to contradict the anticipatory message in the draft about what we should be doing in the future, as distinct from current operational practices. If it's the latter purpose then the advice in RFC3901 is still salient advice about building a robust and resilient DNS name resolution environment, and probably constitutes what would be best current practice, in my view. 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. Geoff [1] https://www.potaroo.net/ispcol/2024-03/truncation-v6.html > On 6 Mar 2025, at 8:37 am, Suzanne Woolf <[email protected]> > wrote: > > Dear > colleagues, > > After > several discussions in f2f meetings and on the list, we’ve > decided to adopt draft-momoka-dnsop-3901bis for DNSOP, with a few caveats. > > Several > weeks ago, the chairs put out a Call for Adoption for this draft. > We hadn’t reported back on that because we had some discussion and have been > pondering what to do. Looking at the results of the CfA, we didn’t see a lot > of support from DNSOP participants; there seemed to be more interest from > V6OPS participants. But we do > see a couple of reasons to revisit RFC 3901 from a DNS operations > perspective: it’s 20 years old now, the deployment of IPv6 has changed > significantly in that time, and the audience for such a document has also > evolved. > > We > also agree that the draft needs input from both IPv6 and DNS experts if it’s > to proceed. > > Looking > at the draft as a DNSOP work item, we have the same questions we’ve often > asked about other drafts, particularly as updates to BCPs: is the draft in > fact describing a best current practice or a "likely-to-be best practice"? > For a -bis version of a BCP, what > drives the requirement for an update? What is it recommending, why are its > recommendations “best” under common circumstances, and what operational > limits or exceptions does it have? The current draft touches on these > questions but needs some expansion in the > reasoning (as discussed on the list between Tobias, Geoff, and others). > > We > also note that BCPs have sometimes proven very difficult to converge on > consensus in DNSOP, because there are so many knobs and quirks and exceptions > in the deployment of DNS, and engaging with them can have enormous > operational impacts. So it’s a good idea > in such cases to resist scope creep as much as possible. > > Authors, > please post draft-ietf-dnsop-3901bis. > > > Best, > Benno, > Suzanne, and Tim > _______________________________________________ > DNSOP mailing list -- [email protected] > To unsubscribe send an email to [email protected]
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ DNSOP mailing list -- [email protected] To unsubscribe send an email to [email protected]
