Hi Goeff, One comment on this part:
> I personally > don't see a role for such documents advocating what should (or > should not) be an operational practice that is not in common use > today and the underlying rationale for such advocacy. > Informally, I see a BCP as saying "this is what we do > operationally today to support a reliable and efficient service." I'm afraid that this personal interpretation of BCP status does not exactly match what we have in our reference process documents. Per RFC2026, a BCP: "is a vehicle by which the IETF community can define and ratify the community's best current thinking on a statement of principle or on what is believed to be the best way to perform some operations or IETF process function." The present document falls under the 2026 BCP definition. Thank you. Cheers, Med > -----Message d'origine----- > De : Geoff Huston <[email protected]> > Envoyé : mercredi 7 janvier 2026 01:10 > À : [email protected] > Cc : dnsop <[email protected]>; [email protected] > Objet : Re: [DNSOP] [Last-Call] draft-ietf-dnsop-3901bis-09 ietf > last call Dnsdir review > > > My apologies for the delay in response as I took a break from > email over the Christmas and New Year period. > > I see that others have chimed on with responses to my DNSDIR > review, and I don't propose to add to that conversation here. > > More generally, in my review I had taken an interpretation of the > role of a BCP document that the purpose of as BCP is to describe > what is regarded as current operational practices that result in > service outcomes that are reliable and efficient. I personally > don't see a role for such documents advocating what should (or > should not) be an operational practice that is not in common use > today and the underlying rationale for such advocacy. > Informally, I see a BCP as saying "this is what we do > operationally today to support a reliable and efficient service." > > In my view, this particular document heads into a proselytising > mode that esposes a possible future operational practice, "best" > or otherwise. I realise that this mode is standard operational > practice for many IPv6 evangelists, but for me such an approach > confuses a factual description of current reality with a desired > outcome. > > It appears to me that _as an Informational RFC_, this draft is as > ready as it will ever be, and its a fine document. As a BCP, > however, it is Not Ready in my view, as it strays beyond the role > of a BCP. > > regards, > > Geoff > > > > > On 20 Dec 2025, at 6:07 am, Tobias Fiebig > <[email protected]> wrote: > > > > Dear Reviewer, > > > > thank you for your thoughtful feedback on our submission. After > > carefully reading your comments. To solicit further input from > the WG, > > we also put the WG in Cc:; we would like to address your > suggestions > > in the following ways: > > > >> 2 Section 3.3 - " At the time of writing" -> This reference is > >> already 2 > >> years old. Perhaps the document should explicitly state this > as a > >> reference to measurements undertaken in 2023, as per the > citation > > > > We would address this comment with the following PR: > > > https://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2F > gith > > ub.com%2Fietf-wg-dnsop%2Fdraft-ietf-dnsop- > 3901bis%2Fpull%2F58&data=05% > > > 7C02%7Cmohamed.boucadair%40orange.com%7C9a26c5534f2246ad6c5108de4d > 813f > > > 5d%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C639033414673784669 > %7CU > > > nknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsI > lAiO > > > iJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=ZGG > MnIe > > QYHEFVwk8eiCGVvofaHOm4WjcRlx2Qu%2FZfyQ%3D&reserved=0 > > > >> Issues: > >> > >> 1 Section 3 is a treatise on on the pontential fragmentary > pressures > >> on a [...] Restating at length material from other DNS > literature, > >> including RFCs, appears to this reviewer to wander from the > intended > >> scope and purpose of this proposed revision to RFC3901. > > > > Inclusion of this section in its verbatim nature esp. regarding > IP > > layer fragmentation has been the result of extensive discussions > on > > the DNSOP mailinglist. Especially in 2024, prominent voices were > > notably adamant about including this text. > > > > Beyond that, the section also provides necessary context and > > background for non-fragmentation related aspects of the > document, esp. > > in the context of NS validation at delegation time, as it also > > discusses Zone Misconfigurations (3.1) and intentional reasons > (3.3) > > for namespace fragmentation; > > > > We would hence argue that, also following the extensive WG > discussion, > > changes here are not strictly necessary. > > > > > >> 2 Section 4.1 "It is usually recommended that DNS zones > contain at > >> least two name servers, which are geographically diverse and > operate > >> under different routing policies [IANANS]." This reference to > advice > >> from the IANA is advice that explicitly limits itself to > >> consideration of the root zone, and delegations in the TLDs > .int and > >> .arpa, and does not purport to describe a usual case. Either > the > >> text should be modified toi note the intended limited scope of > the > >> IANA advice, or other DNS literature should be cite to justify > this > >> claim. > > > > We would address this comment with the following PR: > > > https://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2F > gith > > ub.com%2Fietf-wg-dnsop%2Fdraft-ietf-dnsop- > 3901bis%2Fpull%2F59&data=05% > > > 7C02%7Cmohamed.boucadair%40orange.com%7C9a26c5534f2246ad6c5108de4d > 813f > > > 5d%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C639033414673798849 > %7CU > > > nknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsI > lAiO > > > iJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=UPk > d%2F > > 6t29PpEaNwzZ0BF2aT1aP5CNkuy3Vt7n%2FqZlv8%3D&reserved=0 > > > >> 3 Section 4.1: "RECOMMENDED that at least two name servers for > a > >> zone are dual-stack name servers." There is no justification > for this > >> recommendation, [...] The reviewer suggests that this > recommendation > >> be rewritten to address a requrement for resilience in each > protocol > >> familty. > > > > We would address this comment with the following PR: > > > https://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2F > gith > > ub.com%2Fietf-wg-dnsop%2Fdraft-ietf-dnsop- > 3901bis%2Fpull%2F60&data=05% > > > 7C02%7Cmohamed.boucadair%40orange.com%7C9a26c5534f2246ad6c5108de4d > 813f > > > 5d%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C639033414673808648 > %7CU > > > nknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsI > lAiO > > > iJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=5V% > 2BTk > > YdSe8hHGMquvSN1W%2F0grfmktjcDVP%2BejgyM7yU%3D&reserved=0 > > > >> 4. Section 4.1: "IPv4 adoption: Every DNS zone SHOULD be served > by at > >> least one IPv4-reachable authoritative DNS server". It appears > that > >> the intent of the RECOMMENDATION in the previous paragragh is > that > >> there is a minimum of TWO IPv4-reachable authoritative DNS > servers. > >> Which is it? > > > > We would address this comment with the following PR: > > > https://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2F > gith > > ub.com%2Fietf-wg-dnsop%2Fdraft-ietf-dnsop- > 3901bis%2Fpull%2F61&data=05% > > > 7C02%7Cmohamed.boucadair%40orange.com%7C9a26c5534f2246ad6c5108de4d > 813f > > > 5d%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C639033414673818060 > %7CU > > > nknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsI > lAiO > > > iJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=nRp > mH5l > > 7rXYep859USQRoQYKsdmij8uDLFZN2JvvmEc%3D&reserved=0 > > > >> 5. Section 4.1: "Given the IPv4 address scarcity, operators MAY > opt > >> not to provide DNS services via IPv4, if they can ensure that > all > >> clients expected to resolve this zone do support DNS resolution > via > >> IPv6." [...] The review suggests that this sentence has no > place in a > >> BCP relating to the DNS on the public internet, and should be > >> removed. > > > > This author would like to respectfully disagree on this point. > > Operators expressed the need to at least have the option of > creating > > domain specific services, e.g., an ISP who mostly provides IPv6 > > connectivity, that are IPv6 only, if they know that all clients > to > > expect will have IPv6 connectivity. > > > > To ensure consensus in this point, the document leave the option > > (BCP14 > > MAY) to operators. > > > >> 6. Section 4.1: "To avoid reachability issues, authoritative > DNS > >> servers SHOULD use native IPv6 addresses instead of IPv4- > converted > >> IPv6 addresses for receiving queries." [...] the reviewer dowa > not > >> believe that "native IPv6 addresses" is a well defined term in > the > >> IPv6 address architecture. > > > > We would address this comment with the following PR: > > > https://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2F > gith > > ub.com%2Fietf-wg-dnsop%2Fdraft-ietf-dnsop- > 3901bis%2Fpull%2F57%2Ffiles& > > > data=05%7C02%7Cmohamed.boucadair%40orange.com%7C9a26c5534f2246ad6c > 5108 > > > de4d813f5d%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C6390334146 > 7382 > > > 7476%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuM > DAwM > > > CIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&s > data > > =tN4XO92yMFLH%2Fjx7LExPtID8SbnqWwDxszjXcXL8RkQ%3D&reserved=0 > > > > > >> 7. Section 4.1: "IPv6 adoption: Every DNS zone SHOULD be served > by at > >> least one IPv6-reachable authoritative DNS server". It appears > that > >> the intent of the RECOMMENDATION in the previous paragragh is > that > >> there is a minimum of TWO IPv6-reachable authoritative DNS > servers. > >> Which is it? > > > > We would address this comment with the following PR: > > > https://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2F > gith > > ub.com%2Fietf-wg-dnsop%2Fdraft-ietf-dnsop- > 3901bis%2Fpull%2F61&data=05% > > > 7C02%7Cmohamed.boucadair%40orange.com%7C9a26c5534f2246ad6c5108de4d > 813f > > > 5d%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C639033414673836743 > %7CU > > > nknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsI > lAiO > > > iJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=teH > emcH > > lbrfwQ4tteCtApT3hSKjRLPmUiRf6%2FCTzf64%3D&reserved=0 > > > >> 8. Section 4.1 Avoiding IP Fragmentation: This appears to be a > more > >> concise treatment of the material [...] This reviewer suggests > that > >> the material in Section 3 can be dropped in favour of this > treatment > >> in Section 4.1. > > > > Please revisit our response to Point 1. > > > >> 9. Section 4.2: "Every recursive DNS resolver SHOULD be dual- > stack." > >> This is not justified in the body of the document, [...] If > >> autheorativbe servers follow the recommendations on Section 4.1 > then > >> it would appear thathere is no generic requirement for all > recursive > >> resolvers to be dual-stacked in every instance. > > > > Especially this section has been extensively discussed in DNSOP, > also > > during 124. There, operators also noted the progressing decline > of > > IPv4 connection quality they observe in practice. > > > > The WG ultimately converged to the above recommendation, which > > includes a point on query forwarding, which has not been > considered in > > this comment (see below). > > > >> 10. Section 4.2: "..a configuration where it forwards > queries.." > >> Embedding non-explicit forwarding of queries in the DNS > resolution > >> process is not exactly an instance of Best Current Practice. > [...] > >> This reviewer suggests removing all references to query > forwarding by > >> recursive resolvers in Section 4.2. > > > > The suggestion provided here would effectively only cause the > issue > > identified above. The text is clear on leaving transition > > technologies, including using a dedicated upstream for non AFI > > resolvable names; Also, the text explicitly notes that the > forwarded > > to system must have capabilities for the concerned AFI > resolution. > > > > As such, we would again respectfully disagree with the reviewer > on > > this issue, and point towards the text resulting from WG > discussion instead. > > > >> 11. Section4.2: "when responding to recursive queries sent by > stub > >> DNS". How can a recursive resolver know that a query has been > sent by > >> a stub resolver? > > > > For all practical matters, any query received by a recursive > resolver > > has been issued by either a stub resolver, or by another > recursive > > resolver unable to perform recursion and, hence, in that > instance, > > acting as a stub resolver. > > > >> 12. Section 5. Security Considerations: "introduce no new > security\ > >> considerations into the DNS protocol." This reviewr differs > with > >> respect to the recommendation that under certain circumstances > a > >> recursive resolver may forward a query to another recursive > resolver. > >> As already noted, the DNS resolution protocol has no form of > query > >> loop detection or excessive resolver query chain detection, and > there > >> is the potential for scenarios that can be used to launch a DOS > >> attacks on recursive resolvers. The authors should reconsider > this > >> section in the light of the advice relating to resover-to- > resolver > >> forwarding in this document. > > > > The reviewers concern is being heard. However, the text in the > > document clearly only leads to one(1) forwarding hop (if the > necessary > > AFI is not supported by the recursive resolver first receiving > the query). > > > > Theoretically, one could intentionally misconfigure a set of two > > single stack recursive resolver to allow for an infinite loop of > a > > query if the query was neither resolvable via IPv4 nor IPv6. > However, > > at the moment, it is unclear to this author how such a scenario > could > > be created in practice. > > > > It would be appreciated if a working example could be provided > by the > > reviewer who voiced the concern. > > > > > > With best regards, > > Tobias > > > > -- > > Dr.-Ing. Tobias Fiebig > > T +31 616 80 98 99 > > M [email protected] > > > > _______________________________________________ > > DNSOP mailing list -- [email protected] > > To unsubscribe send an email to [email protected] ____________________________________________________________________________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. Thank you. _______________________________________________ DNSOP mailing list -- [email protected] To unsubscribe send an email to [email protected]
