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 ===============================================
_______________________________________________ DNSOP mailing list -- [email protected] To unsubscribe send an email to [email protected]
