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