Reverse Zone/subZone delegation

[phn at icke-reklam.ipsec.nu]

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:

No you don't. Adjust your SOA record ( remove the "\@" combination and replace 
with "."


> ================= 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 ===========================

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

> ================= 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
> for name servers outside our control that may be caching or secondarying
> our zones. Anything to worry about there?

You really shoule have NS records cache longer then 1 hour, likewize
you should have corresponding "A" records with a longer lifetime.
Simularily you don't wont a zone to expire after one day, and you 
are probably "polling "to often ( which is of less concern)

You must also make shure this zonefile for 168.192.in-addr.arpa is
found for every nameserver in your organization, either by using
internal root's or via replication to all servers or a forwarding
scheme.



> In case it matters, we are using 9.2.3.

> Any help would be greatly appreciated. Thanks!

> fpsm
> -- 
> Fredrich Patterson Sebastian Maney

>     "The man who trades freedom for security does not deserve nor will
>     he ever receive either." - Benjamin Franklin



-- 
Peter Håkanson         
        IPSec  Sverige      ( At Gothenburg Riverside )
           Sorry about my e-mail address, but i'm trying to keep spam out,
	   remove "icke-reklam" if you feel for mailing me. Thanx.