IP (not zone) delegation

[Kevin Darcy]

Mark Damrose wrote:

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

My understanding was that the original poster wanted to maintain all data about
PCs on the MS-DNS server, including the reverse entries. But, he probably
*doesn't* want to maintain non-PC data in MS-DNS, and he has mixtures of PC and
non-PC devices in both of his (private) /24 ranges. If so, then this is another
"split responsibility" issue like so-called "classless in-addr delegation", and
the same basic solution applies, i.e. alias individual names where necessary.
Sometimes I wish RFC 2317 wasn't written to be targeted so specifically at
CIDR issues, or even specifically at reverse DNS issues, since aliasing
techniques are useful for a much wider variety of situations.

Or, maybe I have misunderstood the requirements...


- Kevin