Reverse zone with subnet larger than Class C

Thu Mar 2 21:40:55 UTC 2006

> 
> 
> > > > > 	RFC 2317 is a good fit for /25 - /32.  It was never intended fo
> > r
> > > > > 	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 w
> > hich
> > > > > 	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.ARP
> > A
> > > > > 	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.ARP
> > A
> > > > > 	...
> > > > > 	255.3.168.192.IN-ADDR.ARPA CNAME 255.3.0/22.168.192.IN-ADDR.ARP
> > A
> > > > > 
> > > > > 	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.ARP
> > A
> > > $GENERATE 0-255 $.1.168.192.IN-ADDR.ARPA CNAME $.1.0/22.168.192.IN-ADDR.ARP
> > A
> > > $GENERATE 0-255 $.2.168.192.IN-ADDR.ARPA CNAME $.2.0/22.168.192.IN-ADDR.ARP
> > A
> > > $GENERATE 0-255 $.3.168.192.IN-ADDR.ARPA CNAME $.3.0/22.168.192.IN-ADDR.ARP
> > A
> > > 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.A
> > RPA
> > $GENERATE 0-255 $.125.168.192.IN-ADDR.ARPA CNAME $.125.0/17.168.192.IN-ADDR.A
> > RPA
> > $GENERATE 0-255 $.126.168.192.IN-ADDR.ARPA CNAME $.126.0/17.168.192.IN-ADDR.A
> > RPA
> > $GENERATE 0-255 $.127.168.192.IN-ADDR.ARPA CNAME $.127.0/17.168.192.IN-ADDR.A
> > RPA
> > 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.
> 
> 	You just need to get the zones setup correctly.  Initially
> 	all the zones will have exactly the same content.  The
> 	SOA and NS RRsets. 

Yes.  But there's a lot of them.

>	I don't know what this obsession with
> 	putting $ORIGIN into everything is.  

I think something whines (or whined) at some point...  maybe not BIND
itself.  I know BIND whines about TTL ...  silliness...

>	It only the examples
> 	in the RFC's to give context.  It's not required in most
> 	cases.
> 
> > Over on NS2, you need a fourth script to generate the named.conf section.
> 
> 	Just do it by hand.  It really isn't that hard.  I've done it
> 	many times over the years. 

We've all done many of these things over the years.

> > 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.
> 
> 	No. A multi-level zone is actually more difficult to keep correct.
> 	I've tried both methods in the past.

Hmm, we do it for a lot of our 4LD's and in some cases for other deeper
zones.  It works fine if you're used to it.

> > 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.
> 
> 	Actually it not clean at all.  It introduces extra complexity
> 	into the resolution process.  It introduces extra complexity
> 	into the debugging process.  It introduces extra traffic.
> 	It introduces extra records that need to be cached.  It
> 	introduces extra records that need to be served.  And what
> 	for.  To save a few files.

And significant configuration complexity.

> 	There is a big win with the last octet.  You get a simple one level
> 	zone file that looks like a zone file that a /24 gets except for the
> 	name.  There isn't a big win further up the heirachy.

It's not as big, certainly, especially considering you have no other 
real *options* for /24 and beyond.  :-)

It's still interesting, and there may be some value in it to somebody.

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