Reverse zone with subnet larger than Class C

Thu Mar 2 21:32:10 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.  I don't know what this obsession with
	putting $ORIGIN into everything is.  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. 
 
> 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.
	
> 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.

	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.

> > > 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(CN
> N)
> With 24 million small businesses in the US alone, that's way too many apples.
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: Mark_Andrews at isc.org