Templated PTR Records to support RFC2317 style classless reverse delegation
Instead of just creating the DNS PTR by reversing the IP and appending ".in-addr.arpa" it should be possible to create custom strings with templates.
If you only get a fraction of a /24 you can get your reverse-zone delegated as described in RFC2317. This makes crafting your PTR a special case - eventually the PTR syntax is site specific
i.e. your network is 192.0.2.128/25 and you agree with your ISP to use RFC2317 method 1.
Your ISP will add the following RRs in his Nameserver:
128/18.104.22.168.in-addr.arpa. IN NS your.name.server.tld
128/22.214.171.124.in-addr.arpa. IN NS your-other.name.server.tld
126.96.36.199.in-addr.arpa. IN CNAME 128.128/188.8.131.52.in-addr.arpa.
184.108.40.206.in-addr.arpa. IN CNAME 128.129/220.127.116.11.in-addr.arpa.
18.104.22.168.in-addr.arpa. IN CNAME 128.130/22.214.171.124.in-addr.arpa.
255.2.0.192.in-addr.arpa. IN CNAME 255.130/126.96.36.199.in-addr.arpa.
Thus you will have to fill your hosts into the zone 128/188.8.131.52.in-addr.arpa. and the PTRs will have to look like
138.128/184.108.40.206.in-addr.arpa. IN PTR my-server.domain.tld.
254.128/220.127.116.11.in-addr.arpa. IN PTR my-other-server.domain.tld.
Eventually I'd suggest to allow people to add a "PTR-Template" to their subnet configuration where you have variables for the dotted quad, the reversed dotted quad and every byte of the dotted quad.
A template for the above might look like "<% @ip4 %>.128/18.104.22.168.in-addr.arpa" and would be configured on subnet 192.0.2.128
#3 Updated by Andreas Rogge almost 6 years ago
I had a look at what needs to be done to implement this.
AFAICT the following changes are required:
- we need a new optional field `ptr_template` in `Subnet`
- subnet html template needs to be changed to allow to edit the ptr template
- `Subnet` needs a new function `to_arpa(ip)` that renders the ptr according to the template provided if any or otherwise just call `IPAddr.new(ip).reverse` / `IPAddr.new(ip).ip6_arpa`
- `to_arpa()` in `Net::DNS::PTR4Record#to_arpa` and `Net::DNS::PTR6Record#to_arpa` need to be patched to call `Subnet.subnet_for(ip).to_arpa(ip)` to determine the ptr
I'm somewhat unsure when it comes to calling Subnet.subnet_for(ip) as the function looks rather expensive. Maybe it is better to pass down the subnet object down, but I have absolutely no idea how to do that.