 |  |
9.5. Subdomains of in-addr.arpa Domains
Forward-mapping domains aren't the only domains that you can divide into subdomains and delegate. If your in-addr.arpa namespace is large enough, you may need to divide it, too. Typically, you divide the domain that corresponds to your network number into subdomains that correspond to your subnets. How that works depends on the type of network you have and on your network's subnet mask.9.5.1. Subnetting on an Octet Boundary
Since Movie U. has just three /24 (class C-sized) networks, one per segment, there's no particular need to subnet those networks. However, our sister university, Altered State, has a class B-sized network, 172.20/16. Their network is subnetted between the third and fourth octet of the IP address; that is, their subnet mask is 255.255.255.0. They've already created a number of subdomains of their domain, altered.edu, including fx.altered.edu (okay, we copied them), makeup.altered.edu, and foley.altered.edu. Since each of these departments also runs its own subnet (their Special Effects department runs subnet 172.20.2/24, Makeup runs 172.20.15/24, and Foley runs 172.20.25/24), they'd like to divvy up their in-addr.arpa namespace appropriately, too.Delegating in-addr.arpasubdomains is no different from delegating subdomains of forward-mapping domains. Within their db.172.20 zone data file, they need to add NS records like these:
delegating the subdomain that corresponds to each subnet to the correct name server in each subdomain.2 86400 IN NS gump.fx.altered.edu. 2 86400 IN NS toystory.fx.altered.edu. 15 86400 IN NS prettywoman.makeup.altered.edu. 15 86400 IN NS priscilla.makeup.altered.edu. 25 86400 IN NS blowup.foley.altered.edu. 25 86400 IN NS muppetmovie.foley.altered.edu.
A few important notes: the Altered States administrators could only use the third octet of the subnet in the owner name field because the default origin in this file is 20.172.in-addr.arpa. They needed to use the fully qualified domain names of the name servers in the right side of the NS records, though, to avoid having the origin appended. And they didn't need glue address records, since the names of the name servers they delegated the zone to didn't end in the domain name of the zone.
9.5.2. Subnetting on a Non-Octet Boundary
What do you do about networks that aren't subnetted neatly on octet boundaries, like subnetted /24 (class C-sized) networks? In these cases, you can't delegate along lines that match the subnets. This forces you into one of two situations: you have multiple subnets per in-addr.arpa zone, or you have multiple in-addr.arpa zones per subnet. Neither is particularly pleasing.9.5.2.1. Class A and B networks
Let's take the case of the /8 (class A-sized) network 15/8, subnetted with the subnet mask 255.255.248.0 (a 13-bit subnet field and an 11-bit host field, or 8192 subnets of 2048 hosts). In this case, the subnet 15.1.200.0, for example, extends from 15.1.200.0 to 15.1.207.255. Therefore, the delegation for that single subdomain in db.15, the zone data file for 15.in-addr.arpa, might look like this:
That's a lot of delegation for one subnet!200.1.15.in-addr.arpa. 86400 IN NS ns-1.cns.hp.com. 200.1.15.in-addr.arpa. 86400 IN NS ns-2.cns.hp.com. 201.1.15.in-addr.arpa. 86400 IN NS ns-1.cns.hp.com. 201.1.15.in-addr.arpa. 86400 IN NS ns-2.cns.hp.com. 202.1.15.in-addr.arpa. 86400 IN NS ns-1.cns.hp.com. 202.1.15.in-addr.arpa. 86400 IN NS ns-2.cns.hp.com. 203.1.15.in-addr.arpa. 86400 IN NS ns-1.cns.hp.com. 203.1.15.in-addr.arpa. 86400 IN NS ns-2.cns.hp.com. 204.1.15.in-addr.arpa. 86400 IN NS ns-1.cns.hp.com. 204.1.15.in-addr.arpa. 86400 IN NS ns-2.cns.hp.com. 205.1.15.in-addr.arpa. 86400 IN NS ns-1.cns.hp.com. 205.1.15.in-addr.arpa. 86400 IN NS ns-2.cns.hp.com. 206.1.15.in-addr.arpa. 86400 IN NS ns-1.cns.hp.com. 206.1.15.in-addr.arpa. 86400 IN NS ns-2.cns.hp.com. 207.1.15.in-addr.arpa. 86400 IN NS ns-1.cns.hp.com. 207.1.15.in-addr.arpa. 86400 IN NS ns-2.cns.hp.com.
Luckily, BIND 8.2 and later as well as BIND 9.1.0 and later name servers support a control statement called $GENERATE. $GENERATE lets you create a group of resource records that differ only by a numerical iterator. For example, you could create the 16 NS records just listed using these two $GENERATE control statements:
The syntax is fairly simple: when the name server reads the control statement, it iterates over the range specified as the first argument, replacing any dollar signs ($) in the template that follows the first argument with the current iterator.$GENERATE 200-207 $.1.15.in-addr.arpa. 86400 IN NS ns-1.cns.hp.com. $GENERATE 200-207 $.1.15.in-addr.arpa. 86400 IN NS ns-1.cns.hp.com.
9.5.2.2. Class C networks
Now let's look at the case of a subnetted /24 (class C-sized) network, say 192.253.254/24, subnetted with the mask 255.255.255.192. Here, you have a single in-addr.arpa zone, 254.253.192.in-addr.arpa, that corresponds to subnets 192.253.254.0/26, 192.253.254.64/26, 192.253.254.128/26, and 192.253.254.192/26. This can be a problem if you want to let different organizations manage the reverse-mapping information corresponding to each subnet. You can solve this in one of three ways, none of them pretty.9.5.2.2.1. Solution 1
The first solution is to administer the 254.253.192.in-addr.arpa zone as a single entity and not even try to delegate. This requires either cooperation between the administrators of the four subnets involved or the use of a tool like Webmin (http://www.webmin.com/webmin) to allow each of the four administrators to take care of his or her own data.
9.5.2.2.2. Solution 2
The second is to delegate at the fourth octet. That's even nastier than the /8 delegation we just showed you. You'll need at least a couple of NS records per IP addressin the file db.192.253.254, like this:
and so on, all the way down to 254.254.253.192.in-addr.arpa.1.254.253.192.in-addr.arpa. 86400 IN NS ns1.foo.com. 1.254.253.192.in-addr.arpa. 86400 IN NS ns2.foo.com. 2.254.253.192.in-addr.arpa. 86400 IN NS ns1.foo.com. 2.254.253.192.in-addr.arpa. 86400 IN NS ns2.foo.com. ... 65.254.253.192.in-addr.arpa. 86400 IN NS relay.bar.com. 65.254.253.192.in-addr.arpa. 86400 IN NS gw.bar.com. 66.254.253.192.in-addr.arpa. 86400 IN NS relay.bar.com. 66.254.253.192.in-addr.arpa. 86400 IN NS gw.bar.com. ... 129.254.253.192.in-addr.arpa. 86400 IN NS mail.baz.com. 129.254.253.192.in-addr.arpa. 86400 IN NS www.baz.com. 130.254.253.192.in-addr.arpa. 86400 IN NS mail.baz.com. 130.254.253.192.in-addr.arpa. 86400 IN NS www.baz.com.
You can pare that down substantially by using $GENERATE:
Of course, in ns1.foo.com's named.conf, you'd also expect to see:$GENERATE 0-63 $.254.253.192.in-addr.arpa 86400 IN NS ns1.foo.com. $GENERATE 0-63 $.254.253.192.in-addr.arpa 86400 IN NS ns2.foo.com. $GENERATE 64-127 $.254.253.192.in-addr.arpa. 86400 IN NS relay.bar.com. $GENERATE 64-127 $.254.253.192.in-addr.arpa. 86400 IN NS gw.bar.com. $GENERATE 128-191 $.254.253.192.in-addr.arpa. 86400 IN NS mail.baz.com. $GENERATE 128-191 $.254.253.192.in-addr.arpa. 86400 IN NS www.baz.com.
zone "1.254.253.192.in-addr.arpa" {
type master;
file "db.192.253.254.1";
};
zone "2.254.253.192.in-addr.arpa" {
type master;
file "db.192.253.254.2";
};
and in db.192.253.254.1, just the one PTR record:primary 1.254.253.192.in-addr.arpa db.192.253.254.1 primary 2.254.253.192.in-addr.arpa db.192.253.254.2
$TTL 1d
@ IN SOA ns1.foo.com. root.ns1.foo.com. (
1 ; Serial
3h ; Refresh
1h ; Retry
1w ; Expire
1h ; Negative caching TTL
IN NS ns1.foo.com.
IN NS ns2.foo.com.
IN PTR thereitis.foo.com.
9.5.2.2.3. Solution 3
Finally, there's a clever technique that obviates the need to maintain a separate zone data file for each IP address.[68] The organization responsible for the overall /24 network creates CNAME records for each of the domain names in the zone, pointing to domain names in new subdomains, which are then delegated to the proper servers. These new subdomains can be called just about anything, but names like 0-63, 64-127, 128-191, and 192-255 clearly indicate the range of addresses each subdomain will reverse map. Each subdomain then contains only the PTR records in the range the subdomain is named for.[68]We first saw this explained by Glen Herrmansfeldt of CalTech in the newsgroup comp.protocols.tcp-ip.domains. It's now codified as RFC 2317.Partial contents of file db.192.253.254:
Again, you can abbreviate this with $GENERATE:1.254.253.192.in-addr.arpa. IN CNAME 1.0-63.254.253.192.in-addr.arpa. 2.254.253.192.in-addr.arpa. IN CNAME 2.0-63.254.253.192.in-addr.arpa. ... 0-63.254.253.192.in-addr.arpa. 86400 IN NS ns1.foo.com. 0-63.254.253.192.in-addr.arpa. 86400 IN NS ns2.foo.com. 65.254.253.192.in-addr.arpa. IN CNAME 65.64-127.254.253.192.in-addr.arpa. 66.254.253.192.in-addr.arpa. IN CNAME 66.64-127.254.253.192.in-addr.arpa. ... 64-127.254.253.192.in-addr.arpa. 86400 IN NS relay.bar.com. 64-127.254.253.192.in-addr.arpa. 86400 IN NS gw.bar.com. 129.254.253.192.in-addr.arpa. IN CNAME 129.128-191.254.253.192.in-addr. arpa. 130.254.253.192.in-addr.arpa. IN CNAME 130.128-191.254.253.192.in-addr. arpa. ... 128-191.254.253.192.in-addr.arpa. 86400 IN NS mail.baz.com. 128-191.254.253.192.in-addr.arpa. 86400 IN NS www.baz.com.
The zone data file for 0-63.254.253.192.in-addr.arpa, db.192.253.254.0-63, can contain just PTR records for IP addresses 192.253.254.1 through 192.253.254.63.$GENERATE 1-63 $ IN CNAME $.0-63.254.253.192.in-addr.arpa. 0-63.254.253.192.in-addr.arpa. 86400 IN NS ns1.foo.com. 0-63.254.253.192.in-addr.arpa. 86400 IN NS ns2.foo.com. $GENERATE 65-127 $ IN CNAME $.64-127.254.253.192.in-addr.arpa. 64-127.254.253.192.in-addr.arpa. 86400 IN NS relay.bar.com. 64-127.254.253.192.in-addr.arpa. 86400 IN NS gw.bar.com.
Partial contents of file db.192.253.254.0-63:
The way this setup works is a little tricky, so let's go over it. A resolver requests the PTR record for 1.254.253.192.in-addr.arpa, causing its local name server to look that up. The local name server ends up asking a 254.253.192.in-addr.arpa name server, which responds with the CNAME record indicating that 1.254.253.192.in-addr.arpa is actually an alias for 1.0-63.254.253.192.in-addr.arpa and that the PTR record is attached to that name. The response will also include NS records telling the local name server that the authoritative name servers for 0-63.254.253.192.in-addr.arpa are ns1.foo.com and ns2.foo.com. The local name server then queries either ns1.foo.com or ns2.foo.com for the PTR record for 1.0-63.254.253.192.in-addr.arpa, and receives the PTR record.$TTL 1d @ IN SOA ns1.foo.com. root.ns1.foo.com. ( 1 ; Serial 3h ; Refresh 1h ; Retry 1w ; Expire 1h ) ; Negative caching TTL IN NS ns1.foo.com. IN NS ns2.foo.com. 1 IN PTR thereitis.foo.com. 2 IN PTR setter.foo.com. 3 IN PTR mouse.foo.com. ...
