Reverse delegation (RFC 2317) is the way IP-to-FQDN lookups are usually done now. Before this was popular, you could get your ISP to defer to your DNS for reverse records directly, versus them using a set of individual PTR records.
Even though the RFC was written in 1998, it took a while for it to catch on. For years, my DNS servers were using both methods.
Both methods make use of the .in-addr.arpa "domain" syntax.
> Reverse delegation (RFC 2317) is the way IP-to-FQDN lookups are usually done now
> Before this was popular, you could get your ISP to defer to your DNS for reverse records directly
I'm not actually seeing the difference between these two... besides this new "reverse delegation" allowing different nameservers for prefixes longer than /24... aren't you still relying on your ISP/upstream provider (if you don't own your own IPs) to delegate reverse lookups to your own DNS server either way?
Correct, what RFC2317 brings you, is an example of you creating a new namespace in some structured format (IIRC, there are three different example formats given in this RFC), and you just have the upstream ISP, which has the reverse delegation done on the zone cut boundary for the IP ranges it controls inserting a CNAME out to your new namespace on nameservers you control for the reverse PTRs so the reverse PTRs can be formed that way.
Running a long time ISP, I found extremely few customers wanting to do something like RFC2317, or could actually figure out and do it effectively. Almost all were content with control panel/API and having the ISP do it after I pointed them to this informational RFC asking them if this is what they wanted.
Between resolver.arpa, ipv4only.arpa, and the fact that your email won't be delivered to anywhere you actually care about without in-addr.arpa I'm not sure I'd call it legacy.
I didn't even realize that half of the parts of the stack mentioned here existed. I'm going through the process of setting up a home server, and this is definitely giving me some ideas for nonsense to implement.
Reverse delegation (RFC 2317) is the way IP-to-FQDN lookups are usually done now. Before this was popular, you could get your ISP to defer to your DNS for reverse records directly, versus them using a set of individual PTR records.
Even though the RFC was written in 1998, it took a while for it to catch on. For years, my DNS servers were using both methods.
Both methods make use of the .in-addr.arpa "domain" syntax.
> Reverse delegation (RFC 2317) is the way IP-to-FQDN lookups are usually done now
> Before this was popular, you could get your ISP to defer to your DNS for reverse records directly
I'm not actually seeing the difference between these two... besides this new "reverse delegation" allowing different nameservers for prefixes longer than /24... aren't you still relying on your ISP/upstream provider (if you don't own your own IPs) to delegate reverse lookups to your own DNS server either way?
Correct, what RFC2317 brings you, is an example of you creating a new namespace in some structured format (IIRC, there are three different example formats given in this RFC), and you just have the upstream ISP, which has the reverse delegation done on the zone cut boundary for the IP ranges it controls inserting a CNAME out to your new namespace on nameservers you control for the reverse PTRs so the reverse PTRs can be formed that way.
Running a long time ISP, I found extremely few customers wanting to do something like RFC2317, or could actually figure out and do it effectively. Almost all were content with control panel/API and having the ISP do it after I pointed them to this informational RFC asking them if this is what they wanted.
super interesting. the early days of military networks always fascinate me, especially the legacy holdovers like .arpa
Between resolver.arpa, ipv4only.arpa, and the fact that your email won't be delivered to anywhere you actually care about without in-addr.arpa I'm not sure I'd call it legacy.
I didn't even realize that half of the parts of the stack mentioned here existed. I'm going through the process of setting up a home server, and this is definitely giving me some ideas for nonsense to implement.