Reverse Zone/subZone delegation
phn at icke-reklam.ipsec.nu
phn at icke-reklam.ipsec.nu
Sun Mar 7 10:03:40 UTC 2004
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.
More information about the bind-users
mailing list