Reverse zone with subnet larger than Class C
Joe Greco
jgreco at ns.sol.net
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.
More information about the bind-users
mailing list