Reverse zone with subnet larger than Class C

[Joe Greco]

> 
> 
> > > 	RFC 2317 is a good fit for /25 - /32.  It was never intended for
> > > 	shorter prefixes.  It removes the one zone per PTR record
> > > 	management headache.
> > 
> > Right, I understand, I was there.  :-)  I remember the "resolvers will
> > not handle this properly" debates all too clearly.
> > 
> > > 	Normal delegation gives you 256 PTR records per zone for /24s which
> > > 	IMHO is a reasonable trade off.  4 zones for 1024 PTR records.
> > > 
> > > 	You need to create 1024 CNAME records in the /16 zone to handle
> > > 	a /22.
> > > 
> > > 	0/22.168.192.IN-ADDR.ARPA NS NS1.EXAMPLE.NET
> > > 	0/22.168.192.IN-ADDR.ARPA NS NS2.EXAMPLE.NET
> > > 	0.0.168.192.IN-ADDR.ARPA CNAME 0.0.0/22.168.192.IN-ADDR.ARPA
> > > 	...
> > > 	255.0.168.192.IN-ADDR.ARPA CNAME 255.0.0/22.168.192.IN-ADDR.ARPA
> > > 	0.1.168.192.IN-ADDR.ARPA CNAME 0.1.0/22.168.192.IN-ADDR.ARPA
> > > 	...
> > > 	255.1.168.192.IN-ADDR.ARPA CNAME 255.1.0/22.168.192.IN-ADDR.ARPA
> > > 	...
> > > 	255.3.168.192.IN-ADDR.ARPA CNAME 255.3.0/22.168.192.IN-ADDR.ARPA
> > > 
> > > 	32768 CNAME records for /17.
> > > 
> > > 	No sane /16 (/8) administator will do that.
> > 
> > And here I thought that was the magic of $GENERATE...
> 
> 	$GENERATE (a BINDism) only has one counter.  The above needs two
> 	counters.
> 
> $GENERATE 0-255 $.0.168.192.IN-ADDR.ARPA CNAME $.0.0/22.168.192.IN-ADDR.ARPA
> $GENERATE 0-255 $.1.168.192.IN-ADDR.ARPA CNAME $.1.0/22.168.192.IN-ADDR.ARPA
> $GENERATE 0-255 $.2.168.192.IN-ADDR.ARPA CNAME $.2.0/22.168.192.IN-ADDR.ARPA
> $GENERATE 0-255 $.3.168.192.IN-ADDR.ARPA CNAME $.3.0/22.168.192.IN-ADDR.ARPA
> 0/22.168.192.IN-ADDR.ARPA NS NS1.EXAMPLE.NET
> 0/22.168.192.IN-ADDR.ARPA NS NS2.EXAMPLE.NET
> 	
> 	vs
> 
> $GENERATE 0-3 $.168.192.IN-ADDR.ARPA NS NS1.EXAMPLE.NET
> $GENERATE 0-3 $.168.192.IN-ADDR.ARPA NS NS2.EXAMPLE.NET

It doesn't _have_ to have two counters.  It would merely be damn nice if
it did.  Looking at this as an exercise in configuration complexity, the
above *looks* pretty nifty until you realize that there's a significant
difference on the delegated servers.

That difference is the difference between one and four zones.  This isn't
a huge issue at this scale, but errors creep in readily enough, especially
on the delegated server.

Now consider the following /17 delegation:

$GENERATE 0-255 $.0.168.192.IN-ADDR.ARPA CNAME $.0.0/17.168.192.IN-ADDR.ARPA
$GENERATE 0-255 $.1.168.192.IN-ADDR.ARPA CNAME $.1.0/17.168.192.IN-ADDR.ARPA
$GENERATE 0-255 $.2.168.192.IN-ADDR.ARPA CNAME $.2.0/17.168.192.IN-ADDR.ARPA
$GENERATE 0-255 $.3.168.192.IN-ADDR.ARPA CNAME $.3.0/17.168.192.IN-ADDR.ARPA
$GENERATE 0-255 $.4.168.192.IN-ADDR.ARPA CNAME $.4.0/17.168.192.IN-ADDR.ARPA
$GENERATE 0-255 $.5.168.192.IN-ADDR.ARPA CNAME $.5.0/17.168.192.IN-ADDR.ARPA
[...]
$GENERATE 0-255 $.124.168.192.IN-ADDR.ARPA CNAME $.124.0/17.168.192.IN-ADDR.ARPA
$GENERATE 0-255 $.125.168.192.IN-ADDR.ARPA CNAME $.125.0/17.168.192.IN-ADDR.ARPA
$GENERATE 0-255 $.126.168.192.IN-ADDR.ARPA CNAME $.126.0/17.168.192.IN-ADDR.ARPA
$GENERATE 0-255 $.127.168.192.IN-ADDR.ARPA CNAME $.127.0/17.168.192.IN-ADDR.ARPA
0/17.168.192.IN-ADDR.ARPA NS NS1.EXAMPLE.NET
0/17.168.192.IN-ADDR.ARPA NS NS2.EXAMPLE.NET
	
	vs

$GENERATE 0-127 $.168.192.IN-ADDR.ARPA NS NS1.EXAMPLE.NET
$GENERATE 0-127 $.168.192.IN-ADDR.ARPA NS NS2.EXAMPLE.NET

Clearly, on the delegating server, the first is a more complex
configuration.  That doesn't seem desirable.

But here's where it wins:  you have to remember that NS2 will likely be
slaved from NS1, and in the second case, the configuration on NS1 is
complex to begin with.

On NS1, you have the configuration complexity of setting up master for
128 zones in the named.conf, PLUS getting 128 zone files properly set
up, PLUS getting the $ORIGIN in each of those zone files numbered
properly, and boy I hope you wrote three scripts to make sure each one
of those was done properly, otherwise you're statistically likely to
make a goofup.

Over on NS2, you need a fourth script to generate the named.conf section.

These are all big configs, 128x more complex than the single zone file
solution.  More potential stuff to break in the future through fat
fingering or other random problems.

The first example is a lot cooler in that there's a single delegation, a
single zone to configure on the delegated servers, and the only person
who needs to write a script is the guy doing the delegating, and that
script is fairly simple.

Sadly, there is no way to avoid the configuration complexity of the first
example on the delegating server.  There would be if BIND had a multilevel
$GENERATE though.  ;-)

However, the first example would lead to further messiness and possible
brokenness in the face of further 2317 subdelegations.

But it's still got a certain cleanness to it from the configuration
complexity point of view.

> > But really, experience says that mistakes are more likely to happen when
> > you're dealing with multiple zones.  Delegating a significant chunk out
> > of a /16 would be a PITA, I would think.
> 
> 	Not really and I'm talking from experience as I used to
> 	administer 130.155.0.0/16 which was further delegated to
> 	about 20 or so other divisions within the organisation some
> 	which were sharing the same broadcast network with other
> 	divisions so one division might get 1 /24 and the other 3
> 	/24s.

Mmm hmm.  You're not the only person to have administered a /16.

... JG
-- 
Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net
"We call it the 'one bite at the apple' rule. Give me one chance [and] then I
won't contact you again." - Direct Marketing Ass'n position on e-mail spam(CNN)
With 24 million small businesses in the US alone, that's way too many apples.