Hello WG, I am looking into reverse delegation. I found RFC 2317 https://datatracker.ietf.org/doc/html/rfc2317 (aka BCP20). Is that really true? Does anyone use ”/” in their delegation names? <- Maybe someone who scans the whole tree could look into this? Does Ripe have a recommendation/BCP on reverse delegation (for non-octet boundaries)? Greetings from rainy Stockholm /Ulrich
Hi, I did some work on RFC 2317-based delegation in the course of the development of NetBox DNS <https://github.com/sys4/netbox-plugin-dns> which supports RFC 2317 delegation. Yes, the RFC is essentially correct, and using a / in a label is not forbidden either. You can do that, which doesn't mean that you should :-) Citing from https://datatracker.ietf.org/doc/html/rfc2317#section-4:
The examples here use "/" because it was felt to be more visible and pedantic reviewers felt that the 'these are not hostnames' argument needed to be repeated. We advise you not to be so pedantic, and to not precisely copy the above examples, e.g. substitute a more conservative character, such as hyphen, for "/".
In fact an RFC 2317 reverse zone is nothing but a normal zone and does not need to follow the normal delegation scheme for .in-addr.arpa. You can even insert your PTR records in your forward zone, as long as you poing the CNAMEs in the parent zone at the right target. Best regards, Pete.
The / is not forbidden, might be technically true, but ... I have more often seen a delegation in the style of an ip-range like 0-63. I actually expected that in the BCP. The forward zone is a neat option, but it needs more coordination with the parent if not all of your addresses are in the same forward zone. Anyway, maybe some more people can join in and tell what they are using? Thanks! /Ulrich On 2026-05-13, 13:21, "Peter Eckel via dns-wg" <dns-wg@ripe.net <mailto:dns-wg@ripe.net>> wrote: Hi, I did some work on RFC 2317-based delegation in the course of the development of NetBox DNS <https://github.com/sys4/netbox-plugin-dns> <https://github.com/sys4/netbox-plugin-dns>> which supports RFC 2317 delegation. Yes, the RFC is essentially correct, and using a / in a label is not forbidden either. You can do that, which doesn't mean that you should :-) Citing from https://datatracker.ietf.org/doc/html/rfc2317#section-4 <https://datatracker.ietf.org/doc/html/rfc2317#section-4>:
The examples here use "/" because it was felt to be more visible and pedantic reviewers felt that the 'these are not hostnames' argument needed to be repeated. We advise you not to be so pedantic, and to not precisely copy the above examples, e.g. substitute a more conservative character, such as hyphen, for "/".
In fact an RFC 2317 reverse zone is nothing but a normal zone and does not need to follow the normal delegation scheme for .in-addr.arpa. You can even insert your PTR records in your forward zone, as long as you poing the CNAMEs in the parent zone at the right target. Best regards, Pete.
Anyway, maybe some more people can join in and tell what they are using?
For my part, where I need to do RFC 2317 I prefer the form 0-63.2.0.192.in-addr.arpa 64-127.2.0.192.in-addr.arpa 128-191.2.0.192.in-addr.arpa 192-255.2.0.192.in-addr.arpa Advantage is that the characters are more conventional than the example stuff from the RFC, and you see at first glance which addresses are included in the delegated zone. Best regards, Pete.
Hi, On 5/13/26 13:57, Peter Eckel via dns-wg wrote:
For my part, where I need to do RFC 2317 I prefer the form
0-63.2.0.192.in-addr.arpa 64-127.2.0.192.in-addr.arpa 128-191.2.0.192.in-addr.arpa 192-255.2.0.192.in-addr.arpa
That is also the format used by some deSEC users. Best, Peter -- Like our community service? 💛 Please consider donating at https://desec.io/ deSEC e.V. Möckernstraße 74 10965 Berlin Germany Vorstandsvorsitz: Nils Wisiol Registergericht: AG Berlin (Charlottenburg) VR 37525
Subject: [dns-wg] Re: [Ext] Re: Reverse DNS Date: Wed, May 13, 2026 at 01:57:55PM +0200 Quoting Peter Eckel via dns-wg (dns-wg@ripe.net):
Anyway, maybe some more people can join in and tell what they are using?
For my part, where I need to do RFC 2317 I prefer the form
0-63.2.0.192.in-addr.arpa 64-127.2.0.192.in-addr.arpa 128-191.2.0.192.in-addr.arpa 192-255.2.0.192.in-addr.arpa
Advantage is that the characters are more conventional than the example stuff from the RFC, and you see at first glance which addresses are included in the delegated zone.
This is what I prefer, and have a couple times forwarded as more-or-less gospel to some operators who were a bit baffled by the functionality. IIRC Infoblox does something similar. /Måns, classless. -- Måns Nilsson primary/secondary/besserwisser/machina MN-1334-RIPE SA0XLR +46 705 989668 Xerox your lunch and file it under "sex offenders"!
On 13/05/2026 13:20, Peter Eckel via dns-wg wrote: Hi Peter,
Yes, the RFC is essentially correct, and using a / in a label is not forbidden either. You can do that, which doesn't mean that you should :-) The big problem with using a slash is that if your zone files are based on the zone name (almost universal practice), then on unix-like systems, where the slash is a path separator, you'll have a problem. You'll have to give the file a different name, and it quickly becomes messy. A dash doesn't pose any such problems.
The RIPE Database supports RFC 2317 style delegations using dashes. Regards, Anand Buddhdev RIPE NCC
On 13 May 2026, at 14:28, Anand Buddhdev <anandb@ripe.net> wrote:
On 13/05/2026 13:20, Peter Eckel via dns-wg wrote:
Hi Peter,
Yes, the RFC is essentially correct, and using a / in a label is not forbidden either. You can do that, which doesn't mean that you should :-) The big problem with using a slash is that if your zone files are based on the zone name (almost universal practice), then on unix-like systems, where the slash is a path separator, you'll have a problem. You'll have to give the file a different name, and it quickly becomes messy. A dash doesn't pose any such problems.
I have always found RFC 2317 to be a little too prescriptive. I would have preferred it if it had just said "Reverse DNS is just a naming convention, a zone is a zone, CNAME and PTR records are things that can be put in zones, feel free to connect the dots" with the proposed / notation being more clearly an example of that. In the past when hand-editing zone files was a thing I have found it convenient, for example, to $ORIGIN 90.212.199.IN-ADDR.ARPA. @ IN SOA ... @ NS ... $GENERATE 0-255 $ CNAME $.reverse.HOPCOUNT.CA. $ORIGIN HOPCOUNT.CA. @ IN SOA ... @ NS ... ; delightful.hopcount.ca. A 199.212.90.1 1.reverse PTR delightful.HOPCOUNT.CA. ; glorious.hopcount.ca. A 199.212.90.37 37.reverse PTR glorious.HOPCOUNT.CA. This to me seems fully in the spirit of 2317 and has the advantage of keeping data that should match together, so that when it doesn't match it's more obvious. No innocent punctuation was harmed in the formulation of this example. Joe
participants (6)
-
Anand Buddhdev -
Joe Abley -
Måns Nilsson -
Peter Eckel -
Peter Thomassen -
Ulrich Wisser