I really like the idea of adding a column to the IPv4 and IPv6 special-purpose address space registries, and maybe that is even a better solution than changing IPv4 and IPv6 locally-served DNS zone registries at "Expert Review." Adding a column to the two special-purpose address space registries would ensure that the locally-served DNS zone registries are considered when special-purpose address space is added. In fact, I'm pretty sure that if there were a column, RFC9637 would not have forgotten the addition to the locally-served DNS zone registries.
Thanks. On Sun, Nov 23, 2025 at 4:20 AM <[email protected]> wrote: > Hi David, > > > > Good points. Here is my current take on this: > > > > (1) that we only focus on changing the policy to “Expert Review” for the > following registries: > > - IPv4 Locally-Served DNS Zone Registry > - IPv6 Locally-Served DNS Zone Registry > > > > but keep untouched these ones: > > > > - Transport-Independent Locally-Served DNS Zone Registry > - service.arpa Subdomain > > > > (2) Add under the “Designated Expert Guidance” of the new I-D an > instruction to check that an entry is also present in the Special address > space registries. > > > > (3) Consider adding a note to the “Special Address Space” registries to > mirror entries that have specific characteristics (e.g., as a function of > Forwardable/Globally Reachable values). > > > > If we can’t think of an automatic rule for IANA to mirror certain > registrations based on current columns, then maybe consider also updating > RFC6890 to add a new column that will be filled when adding an entry into > the special registry space registries. For example: > > > > NEW: > > Eligible to Locally-Served DNS Zones: A boolean value indicating whether > > the IP address block is to be added to the Locally-Served DNS Zones IANA > > registry. > > IANA has to add relevant entries for “Eligible to Locally-Served DNS > Zones” > > set to “True” in the IPvx Locally-Served DNS Zone Registry. > > > > The Designated Experts will help IANA to create the reverse zones for such > entries. This also an aspect to be discussed in “Designated Expert > Guidance” Section of the new I-D. > > > > Of course, these are suggestions. > > > > Cheers, > > Med > > > > *De :* David Farmer <[email protected]> > *Envoyé :* vendredi 21 novembre 2025 23:18 > *À :* BOUCADAIR Mohamed INNOV/NET <[email protected]> > *Cc :* V6 Ops List <[email protected]>; dnsop <[email protected]> > *Objet :* Re: [v6ops] Expanded IPv6 Documentation Address Space and the > "Locally-Served DNS Zones" registry > > > > Looking at this a little deeper, there are four sub-registries for > the Locally-Served DNS Zones. > > > > The first two sub-registries, the IPv4 and IPv6 Locally-Served DNS Zone > Registries, should be changed to "Expert Review". However, with an > additional restriction that allows only address blocks from one of the > Special-Purpose Address Space registries to be added to the corresponding > Locally-Served DNS Zones registry. Except when an address block is > concurrently added to both registries. > > > > Adding an address block to one of the Special-Purpose Address Space > registries requires "IETF Review." Following that, "Expert Review" is > probably sufficient if it was forgotten to be added to the Locally-Served > DNS Zones registry, as is the case with the Expanded IPv6 Documentation > Address Space. However, adding an address block to the IPv4 or IPv6 > Locally-Served DNS Zone Registries effectively makes it a special-purpose > address block. So, requiring Special-Purpose Address Space designation > before or concurrent with the addition to the Locally-Served DNS Zone > Registries seems appropriate. > > > > However, I'm not sure that "Expert Review" is the appropriate registry > procedure for the other two sub-registries, the Transport-Independent > Locally-Served DNS Zone Registry, and the service.arpa Subdomain registry. > > > > Thanks. > > > > On Thu, Nov 20, 2025 at 3:26 AM <[email protected]> wrote: > > Hi David, all, > > (also adding dnsop) > > > > Adding 3fff::/20 to "Locally-Served DNS Zones" registry makes sense. > However, given the registration policy of that registry and lack of a rule > that would allow us to automatically add prefixes with similar properties > to that registry, I checked with IANA and also consulted with the IESG > colleagues about how we better handle this. > > > > Given also that future similar issues may happen (the DNS registry may not > be known for other WGs, in particular), the suggested approach is to relax > the registration policy of "Locally-Served DNS Zones" registry to “Expert > Review” instead of “IETF Review”. This would be similar to the fix in > https://datatracker.ietf.org/doc/rfc9650/ but for another registry. > > > > If there is a volunteer to write a short draft to fix this, and there are > no objections to relax the registration policy, I think that this is a > document that we can fast track in DNSOP (or even as AD sponsored). > > > > Comments are welcome. > > > > Cheers, > > Med > > > > *De :* David Farmer <[email protected]> > *Envoyé :* vendredi 17 octobre 2025 19:33 > *À :* Nick Buraglio <[email protected]>; Geoff Huston < > [email protected]>; V6Ops Chairs <[email protected]> > *Cc :* V6 Ops List <[email protected]> > *Objet :* [v6ops] Expanded IPv6 Documentation Address Space and the > "Locally-Served DNS Zones" registry > > > > > > V6ops Chairs and RFC9637 Authors, > > > > I have been reviewing several IANA registries and noticed that > the Expanded IPv6 Documentation Address Space 3fff::/20 has not been added > to the "Locally-Served DNS Zones" registry. > > > > Given that RFC 9637 updates RFC 3849, and RFC 6303 referenced RFC 3849 and > included 2001:db8::/32 (8.B.D.0.1.0.0.2.IP6.ARPA) in the "Locally-Served > DNS Zones" registry [1], I believe 3fff::/20 (0.F.F.F.3.IP6.ARPA) should > also be added to that registry, but it has not been added. > > > > What is the proper procedure to correct this? > > > > I think, with RFC 9637 and the "IETF Review" registration procedure for > that registry, it should simply be a request to the IESG and/or IANA. > > > > Thanks. > > > > [1] > https://www.iana.org/assignments/locally-served-dns-zones/locally-served-dns-zones.xhtml#ipv6 > > > > -- > > =============================================== > 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 > =============================================== > > ____________________________________________________________________________________________________________ > > 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. > > > > > -- > > =============================================== > 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 > =============================================== > > ____________________________________________________________________________________________________________ > 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. > > -- =============================================== 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 ===============================================
_______________________________________________ DNSOP mailing list -- [email protected] To unsubscribe send an email to [email protected]
