Reverse zone with subnet larger than Class C

[Mark Andrews]

> > > Hi,
> > > 
> > > I trying to add some more reverse zones in bind 9.3.1. 
> > > 
> > > The problem is that I would like to add zones like 192.168.0.0/22,
> > > 192.168.4.0/22 and so on.
> > > 
> > > Is that possible with BIND?
> > > 
> > > I've tried several configs:
> > > 
> > > named.conf:
> > > 
> > > zone "0-22.168.192.IN-ADDR.ARPA" in {
> > > 	type master;
> > > 	file "rev/192.168.0-22.rev.db";
> > > };
> > > 
> > > or
> > > 
> > > zone "0/22.168.192.IN-ADDR.ARPA" in {
> > > 	type master;
> > > 	file "rev/192.168.0-22.rev.db";
> > > };
> > > 
> > > But none of those worked.
> > > 
> > > My reverse zone file works because if I only add it as Class C it
> > > works.
> > > 
> > > Anyone know how to do it if possible?
> > 
> > 	Just delegate the sets of 4 zones.
> 
> Using RFC2317-style techniques if you'd prefer a single delegation makes
> a certain amount of sense...  which appears to be what OP is trying for.
> It should be possible, and it might be clean.  For only four zones,
> delegation works fairly well too, but if it was a larger number, the 2317
> stuff could be a good fit.  Potentially problematic if there are further
> subdelegations though.  :-)

	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.

	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.255.168.192.IN-ADDR.ARPA CNAME 255.255.0/22.168.192.IN-ADDR.ARPA

	32768 CNAME records for /17.

	No sane /16 (/8) administator will do that.

	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.

	Mark

> The usual problem with RFC2317 is wrapping your head around the details.
> 
> It isn't clear what the OP's setup actually is.  Who is delegating those
> zones to you?  You have to make sure that they are implementing the CNAME
> stuff to map stuff to you.
> 
> Stepping through things, step by step, with dig or whatever is a real
> important step in doing 2317 properly.  I occasionally take people down
> the 2317-debugging road and invariably the problem is that someone
> is staring at the files and not the results.  Remember that DNS gets
> messy in the case where you drop a dot or some other unexpected thing 
> is happening, and using dig or host or whatever you prefer to check 
> the actual records at each step vs the expected records is very 
> important.
> 
> ... 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