RFC 2317 Delegations for IPv4 Blocks Less Than /24
Copyright © 2012 by Douglas Barton, dougb@dougbarton.us, All Rights Reserved.The Problem
Delegating IPv4 reverse DNS zones on octet boundaries is easy. This is due to a convenient alignment of how the dot is used both to separate octet boundaries in IPv4 addresses, and as a DNS zone separator. The problem comes when you need to delegate responsibility for a reverse zone that is smaller than a /24. If you provision the full /24 zone the clients that use the name servers it is provisioned on will be able to resolve the records for the relevant octets, but any addresses outside of that range will not resolve correctly.
Possible Solutions
One possible solution is for the parent zone to delegate a sub-zone for every octet in the range. Let's assume that the parent block is 192.168.1/24, so the relevant zone is 1.168.192.in-addr.arpa. The operator of 192.168.1/24 wants to delegate responsibility for 192.168.1.104/29 to a local office whose name servers are ns1.local.example.com and ns2.local.example.com. The 1.168.192.in-addr.arpa zone would need entries like this:
104 NS ns1.local.example.com. NS ns2.local.example.com. 105 NS ns1.local.example.com. NS ns2.local.example.com. ... 111 NS ns1.local.example.com. NS ns2.local.example.com.On the child name servers you would then configure individual zones for each octet that look like this, using 104 as an example:
zone "104.1.168.192.in-addr.arpa" {
type master;
file "/etc/namedb/master/104.1.168.192.in-addr.arpa";
};
$TTL 3h
@ SOA ns1.local.example.com. hostmaster.local.example.com. (
42 ; Serial
1h ; Refresh
15m ; Retry
1w ; Expire
3m ; Negative cache TTL
)
NS ns1.local.example.com.
NS ns2.local.example.com.
PTR host-104.local.example.com.
While not very elegant, this method actually works Ok for smaller blocks,
and has the benefit of being both simple and easy to understand.
RFC 2317
RFC 2317 suggests 2 other methods. The method described in Section 4 is creative, and uses a delegated sub-zone to handle assigning the responsibility to the child administrator. The individual octets in the parent zone are then CNAME'd to hostnames in the child's sub-zone. However it uses a / character for the delegated zone, which is inconvenient because on a Unix file system that character designates a directory boundary. This can make it difficult to provision the zones in the first place, and often makes it harder to duplicate provisioning on slave systems. It is worth noting that the last sentence of that section recommends using a different character, which is advice that has unfortunately been ignored.
Some organizations have chosen to fix this problem by simply removing the slash and the bits after it. In our example above that would mean delegating the 104.1.168.192.in-addr.arpa zone, which works. However that makes it impossible to create a PTR record for that first octet due to the "CNAME and other data" rule.
Another commonly used method is to change the slash character to a hyphen, such as 104-29.1.168.192.in-addr.arpa. This works, and its meaning is clear when the first octet is larger numerically than the CIDR boundary. But a zone like 0-27.1.168.192.in-addr.arpa can be confusing.
Section 5 suggests some other alternatives using names for the delegated sub-zones that do not necessarily correspond directly with the name of the related in-addr.arpa zone. This method also works, but it can be difficult to construct names that are easy to identify without being too long or too clunky.
Best of Both Worlds
In order to create a name for the delegated sub-zone that is related to the /24 zone, but not too inconvenient; and also avoid the problem of not being able to have a PTR for the first octet, we use a simple technique that utilizes the first and last octet of the range to create the name. So using the 192.168.1.104/29 example above we would use the following configuration in the 1.168.192.in-addr.arpa zone:
104-111 NS ns1.local.example.com. NS ns2.local.example.com. 104 CNAME 104.104-111 105 CNAME 105.104-111 ... 111 CNAME 111.104-111If you are using BIND you can use the $GENERATE directive to make creation of the CNAMEs easier:
$GENERATE 104-111 $ CNAME $.104-111You can then create the 104-111.1.168.192.in-addr.arpa zone on the child name servers just like you would any other zone, and populate it with PTR entries for the octets in that range in the same way you would if you were operating the full /24 in-addr.arpa zone.
This method has several advantages:
- It is easy to see what octets should be included in the zone
- It is easy to script
- It avoids the problems described above
Making it Work Locally
Now that the rest of the world can resolve your PTR records it's time to make them work at your site. If you have your authoritative name servers set up without recursion (which you should) then when you ask it for 105.1.168.192.in-addr.arpa it's not going to know the answer. Why? Because it is not authoritative for that zone, it's authoritative for the 104-111.1.168.192.in-addr.arpa zone, and it has no way to know that there is a path from the CNAMEs in the /24 zone to the PTRs in your delegated subzone.
The best way to solve this problem is to ask your ISP to allow you to slave the /24 zone. That way you will have an up to date copy of the zone locally, which will include the delegation to your subzone. If slaving the zone is not allowed you can set up a stub zone for the /24 so that your authoritative name servers know where to get the answers for the parent zone, and can then return the answers that it has locally in your delegated zone.
If you have any suggestions, questions or comments please do not hesitate to contact me at the e-mail address above.