Reverse zone with subnet larger than Class C

Mark Andrews Mark_Andrews at isc.org
Thu Mar 2 00:53:59 UTC 2006


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

	Mark
 
> > 	These days you could do
> > 
> > 	0.168.192.IN-ADDR.ARPA. DNAME 0.0/22.168.192.IN-ADDR.ARPA.
> > 	1.168.192.IN-ADDR.ARPA. DNAME 1.0/22.168.192.IN-ADDR.ARPA.
> > 	2.168.192.IN-ADDR.ARPA. DNAME 2.0/22.168.192.IN-ADDR.ARPA.
> > 	4.168.192.IN-ADDR.ARPA. DNAME 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
> > 
> > 	in the 168.192.IN-ADDR.ARPA zone but it also requires that
> > 	all the servers for 168.192.IN-ADDR.ARPA support DNAME.
> > 
> > 	It also increases the load on the 168.192.IN-ADDR.ARPA servers
> > 	as the synthesised CNAME have a zero TTL.
> 
> Yeah, that'd be bad.
> 
> ... 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



More information about the bind-users mailing list