IP (not zone) delegation

[Mark Damrose]

"Kevin Darcy" <kcd at daimlerchrysler.com> wrote in message
news:am83p0$v9$1 at isrv4.isc.org...
>
> "Smith, John" wrote:
>
> > All,
> >
> >         Background: We are in the process of installing DNS internally.
> > Based on a consultant's design suggestions we are configuring the zones
as
> > follows (I will use test.net as the *example* zone):
> >
> >         ------------
> >         | test.net | (All non-Windows boxes are in this zone.  This will
be
> > a Bind server.)
> >         ------------
> >               |
> >               | delegation
> >               |
> >         ---------------
> >         | ms.test.net | (All Windows boxes are in this subzone.  This
will
> > be a Windows 2000 DNS server.)
> >         ---------------
> >
> >         The question I have is how to handle in-addr.arpa delegations.
One
> > side of our router has 172.16.111.0/24 addresses that contain a mixture
of
> > Windows and non-Windows systems.  The other side of our router has
> > 172.16.112.0/24 addresses that are primarily Windows boxes but have a
small
> > percentage of 'others'.
> >
> >         Given this set up how should or can we handle in-addr.arpa
> > delegations, or is another design 'better' and why?
>
> Assuming everything stays static, you should be able to use the RFC 2317
> technique (basically just aliasing the PTR records) to permit the PTRs in
the
> "mixed" reverse zone to resolve from the MS-DNS server.

Why?  The forward zone is irrelevant.  The in-addr zones fall on byte
boundaries.  Create 2 zones 111.16.172.in-addr.arpa. and
112.16.172.in-addr.arpa.  populate them - either static or dynamic.  Better
yet, set it up on both.  Then no matter which your clients use as a
resolver, it has authoritive data.  It also keeps you from having to set up
special cases to keep the private IP resolution from trying the public
servers.

>
> However, if you want to implement Dynamic Update of reverse entries,
you're
> probably SOL, since last I heard, Win2K's Dynamic Update implementation
wasn't
> RFC 2317 aware...
>
>
> - Kevin
>
>
>
>