[Chapter 9] 9.5 Subdomains of in-addr.arpa Domains

9.5 Subdomains of in-addr.arpa Domains

Forward mapping domains aren't the only domains you can divide into subdomains and delegate. If your in-addr.arpa name space is large enough, you may need to divide it, too. Typically, you divide the domain that corresponds to your network number into subdomains to 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. just has three /24 (class C-sized) network numbers, 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.0, makeup runs 172.20.15.0, and foley runs 172.20.25.0), they'd like to divvy up their in-addr.arpa namespace appropriately, too.

Delegating in-addr.arpa subdomains is no different from delegating subdomains of forward-mapping domains. Within their db.172.20 file, they need to add NS records like these:

  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    muppetshow.foley.altered.edu.

delegating the subdomain that corresponds to each subnet to the correct name server in each subdomain.

Two important reminders: the Altered States administrators needed to use the fully qualified domain names of the name servers in the NS records, because the default origin in this file is 20.172.in-addr.arpa , and they didn't need glue address records, since the names of the name servers they delegated the zone to weren't in 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 subdomain, or you have multiple in-addr.arpa subdomains 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.0.0.0, subnetted with the subnet mask 255.255.248.0 (a thirteen-bit subnet field and an eleven-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 database file for 15.in-addr.arpa , looks like this:

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.

That's a lot of delegation for one subnet!

9.5.2.2 /24 (class C-sized) networks

In the case of a subnetted /24 (class C-sized) network, say 192.253.254.0, subnetted with the mask 255.255.255.192, 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. You can solve this one of three ways, none of them pretty.

Solution 1

The first 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 MIT 's Web DNS ( http://hem.passagen.se/hno/webdns/ ) to allow each of the four administrators to take care of their own data.

Solution 2

The second is to delegate at the fourth octet. That's even nastier than the /8 delegation we just showed. You'll need at least a couple of NS records per IP address in the file db.192.253.254 , like this:

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.
130.254.253.192.in-addr.arpa.    86400    IN    NS    www.baz.com.

194.254.253.192.in-addr.arpa.    86400    IN    NS    mail.baz.com.
194.254.253.192.in-addr.arpa.    86400    IN    NS    www.baz.com.

and so on, all the way down to 254.254.253.192.in-addr.arpa . Of course, in ns1.foo.com 's named.conf , you'd also expect to see:

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";
};

Or, if ns1.foo.com were running BIND 4, you'd expect to see these directives in named.boot :

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

and in db.192.253.254.1 , just the one PTR record:

@    IN    SOA    ns1.foo.com.    root.ns1.foo.com.    (
                         1        ; Serial
                         10800    ; Refresh
                         3600     ; Retry
                         608400   ; Expire
                         86400    ; Default TTL

    IN    NS    ns1.foo.com.
    IN    NS    ns2.foo.com.

    IN    PTR    thereitis.foo.com.

Note that the PTR record is attached to the zone's domain name, since the zone's domain name corresponds to just one IP address. Now, when a 254.253.192.in-addr.arpa name server receives a query for the PTR record for 1.254.253.192.in-addr.arpa , it will refer the querier to ns1.foo.com and ns2.foo.com , which will respond with the one PTR record in the zone.

Solution 3

Finally, there's a clever technique that obviates the need to maintain a separate zone data file for each IP address.[3] 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, called 0-63 , 64-127 , 128-191 , and 192-255 , which are then delegated to the proper servers. Each subdomain will contain only the PTR records in the range the subdomain is named for.

[3] We first saw this explained by Glen Herrmansfeldt at CalTech in the newsgroup comp.protocols.tcp-ip.domains . It's now codified as RFC 2317.

Partial contents of file 254.253.192.in-addr.arpa.dns :

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 , 0-63.254.253.192.in-addr.arpa.dns , can contain just PTR records for IP addresses 192.253.254.1 through 192.253.254.63.

Partial contents of file 0-63.254.253.192.in-addr.arpa :

@    IN    soa    ns1.foo.com.    root.ns1.foo.com.    (
                          1       ; Serial
                          10800   ; Refresh
                          3600    ; Retry
                          608400  ; Expire
                          86400 ) ; Default 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.
...

When a resolver requests the PTR record for 1.254.253.192.in-addr.arpa , a 254.253.192.in-addr.arpa name server will transparently (to the resolver) map this to a request for the PTR record for 1.0-63.254.253.192.in-addr.arpa . This request will wind up at one of the 0-63.254.253.192.in-addr.arpa name servers, run by the organization that runs the low (addresses 0-63) subnet.