Reverse Zone/subZone delegation

[Fredrich P. S. Maney]

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

[...]

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

Well, that's what I get for trying to dummy up records late at night to
keep the security types happy. Thanks for catching that NS/PTR screwup.

> $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.

That makes more sense.

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

Because the nameservers at the "root" are nameservers for all of the
zones. i.e. ns1.domain.org and ns2.domain.org are the nameservers for
all of the domain.org namespace and all of the 192.168.x.x IP space.

[...]

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

That is what I was thinking, but I wanted to verify it.

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

In the example I had the expiration set to one day (because I had just 
changed it to that), but it was set to more than 5 weeks. Should I wait
until that time has expired before making the changes?

fpsm
-- 
Fredrich Patterson Sebastian Maney
w: http://www.maney.org/fred/
e: maney at maney.org

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