Reverse Zone/subZone delegation

[Barry Margolin]

In article <c2edko$1mk7$1 at sf1.isc.org>,
 "Fredrich P. S. Maney" <maney at maney.org> wrote:

> I've posted this to both bind9-users and bind-users, hope that's ok.
> I've also fudged the IPs and domains to protect the guilty and keep
> the security weenies off my back.
> 
> I've been tasked with handing DNS administration off to a different
> group that doesn't really know Unix or command line interfaces. So I
> have been trying to clean everything up and make maintenance of the
> zone files as simple as possible. Part of that is putting each subnet
> (192.168.0.0/24) in our class B (192.168.0.0/16) into it's own zonefile
> (but only for the reverse zones since the entire class B is in one
> namespace -- so the forward zone is one big file).
> 
> I believe that I know the answer to this question (thanks to a very
> fine response that I stumbled across in the bind9-users archive from
> 2001-07-25 by Jim Reid), but since his response dealt with forward
> zones, I'd like to verify it before I implement it in a production
> environment.
> 
> I think I need something similiar to the following in the "root" class
> B zone file:
> ================= Class B Reverse Zonefile ===========================
> $ORIGIN .
> $TTL 3600       ; 1 hour
> 168.192.in-addr.arpa.   IN SOA  domain.org. dns.admin\@domain.org. (
>                                  2004030600 ; serial
>                                  900        ; refresh (15 minutes)
>                                  300        ; retry (5 minutes)
>                                  86400      ; expire (1 day)
>                                  3600       ; minimum (1 hour)
>                                  )
>                          NS      ns1.domain.org.
>                          NS      ns2.domain.org.
> $ORIGIN 1.168.192.in-addr.arpa.
> 1                       PTR     ns1.domain.org.
> 2                       PTR     ns2.domain.org.
> $ORIGIN 2.168.192.in-addr.arpa.
> 1                       PTR     ns1.domain.org.
> 2                       PTR     ns2.domain.org.
> $ORIGIN 3.168.192.in-addr.arpa.
> 1                       PTR     ns1.domain.org.
> 2                       PTR     ns2.domain.org.
> ================= Class B Reverse Zonefile ===========================

This doesn't look right at all.  If you're delegating the subzones, you 
should have NS records in the parent zone, not PTR records.  The parent 
zone should contain:

$ORIGIN 168.192.in-addr.arpa.
1   NS  ns1.domain.org.
    NS  ns2.domain.org.
2   NS  ns1.domain.org.
    NS  ns2.domain.org.
and so on.

And why do all your PTR records point to the same two hostnames?

> And then in each of the "delegated" class C zonefiles, I need something
> similiar to the following:

Maybe the fact that you put "quotes" around "delegated" is a clue to the 
fact that you're not trying to do ordinary delegation?  But if so, 
nothing in your original post suggests the special nature of it.  
There's nothing special about delegation in reverse zones when it 
happens at octet boundaries (you only have to use special tricks like 
RFC 2317 when delegating smaller blocks).

> ================= Delegated Class C Reverse Zonefile =================
> $ORIGIN .
> $TTL 3600       ; 1 hour
> 1.168.192.in-addr.arpa.   IN SOA  domain.org. dns.admin\@domain.org. (
>                                  2004030600 ; serial
>                                  900        ; refresh (15 minutes)
>                                  300        ; retry (5 minutes)
>                                  86400      ; expire (1 day)
>                                  3600       ; minimum (1 hour)
>                                  )
>                          NS      ns1.domain.org.
>                          NS      ns2.domain.org.
> $ORIGIN 1.168.192.in-addr.arpa.
> 1                       PTR     ns1.domain.org.
> 2                       PTR     ns2.domain.org.
> ================= Delegated Class C Reverse Zonefile =================
> 
> Does that look correct? Does anyone see any gotchas that I should look
> out for? Do I need to create stanzas and zone files for all possible
> networks in the class B, or just the ones that we are using? What about

You only need the subnets that you're actually using, although you may 
be able to make things simpler for the clueless admins by setting up the 
whole structure ahead of time.  Mostly-empty zones don't cost much.

> for name servers outside our control that may be caching or secondarying
> our zones. Anything to worry about there?

Caching servers shouldn't need any changes, they'll just follow the 
delegations.  Slave servers may need to be updated; if you want them to 
slave the subzones, they'll need statements for each of them.

-- 
Barry Margolin, barmar at alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***