Discussion:
Reverse zone with subnet larger than Class C
(too old to reply)
Torkel Mathisen
2006-02-28 17:07:56 UTC
Permalink
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?

Regards,
Torkel
Mark Andrews
2006-03-01 07:51:40 UTC
Permalink
Post by Torkel Mathisen
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?
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?
Regards,
Torkel
Just delegate the sets of 4 zones.

Mark
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ***@isc.org
Torkel Mathisen
2006-03-01 08:50:29 UTC
Permalink
Post by Mark Andrews
Post by Torkel Mathisen
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?
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?
Regards,
Torkel
Just delegate the sets of 4 zones.
How?

I only got 1 domain so the domain will still be "test.com". I just want
more reverse zones.

So how to delegate reverse zones like 192.168.0.0/22, 192.168.4.0/22 ..
192.168.44.0/22

But I was hoping that I would be able to add 12 /22 zones rather than 48
Class C reverse zones..

Regards,
Torkel
Joe Greco
2006-03-01 19:10:04 UTC
Permalink
Post by Mark Andrews
Post by Torkel Mathisen
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?
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. :-)

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(CNN)
With 24 million small businesses in the US alone, that's way too many apples.
Mark Andrews
2006-03-01 23:04:59 UTC
Permalink
Post by Joe Greco
Post by Mark Andrews
Post by Torkel Mathisen
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?
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
Post by Joe Greco
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: ***@isc.org
Joe Greco
2006-03-01 23:53:15 UTC
Permalink
Post by Mark Andrews
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.
Post by Mark Andrews
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.
And here I thought that was the magic of $GENERATE...

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.
Post by Mark Andrews
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(CNN)
With 24 million small businesses in the US alone, that's way too many apples.
Mark Andrews
2006-03-02 00:53:59 UTC
Permalink
Post by Joe Greco
Post by Mark Andrews
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.
Post by Mark Andrews
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
Post by Joe Greco
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
Post by Joe Greco
Post by Mark Andrews
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: ***@isc.org
Mark Andrews
2006-03-02 02:35:09 UTC
Permalink
Post by Torkel Mathisen
Post by Mark Andrews
Post by Torkel Mathisen
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?
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?
Regards,
Torkel
Just delegate the sets of 4 zones.
How?
0.168.192.IN-ADDR.ARPA NS NS1.site1.example.net.
0.168.192.IN-ADDR.ARPA NS NS2.site1.example.net.
1.168.192.IN-ADDR.ARPA NS NS1.site1.example.net.
1.168.192.IN-ADDR.ARPA NS NS2.site1.example.net.
2.168.192.IN-ADDR.ARPA NS NS1.site1.example.net.
2.168.192.IN-ADDR.ARPA NS NS2.site1.example.net.
3.168.192.IN-ADDR.ARPA NS NS1.site1.example.net.
3.168.192.IN-ADDR.ARPA NS NS2.site1.example.net.

4.168.192.IN-ADDR.ARPA NS NS1.site2.example.net.
4.168.192.IN-ADDR.ARPA NS NS2.site2.example.net.
5.168.192.IN-ADDR.ARPA NS NS1.site2.example.net.
5.168.192.IN-ADDR.ARPA NS NS2.site2.example.net.
6.168.192.IN-ADDR.ARPA NS NS1.site2.example.net.
6.168.192.IN-ADDR.ARPA NS NS2.site2.example.net.
7.168.192.IN-ADDR.ARPA NS NS1.site2.example.net.
7.168.192.IN-ADDR.ARPA NS NS2.site2.example.net.
Post by Torkel Mathisen
I only got 1 domain so the domain will still be "test.com". I just want
more reverse zones.
So how to delegate reverse zones like 192.168.0.0/22, 192.168.4.0/22 ..
192.168.44.0/22
But I was hoping that I would be able to add 12 /22 zones rather than 48
Class C reverse zones..
Regards,
Torkel
IN-ADDR.ARPA is octet aligned and it followed the original
address assignment rules which were also octet aligned.
Modern address assignemnt is bit aligned.

We looked at doing bit aligned delegations for IPv6 and
gave them up as a bad idea. IPv6 uses nibble alignment
under IP6.ARPA. While address assignment for IPv6 is bit
aligned I suspect that most assignments will end up being
nibble aligned. For the off nibble assignments there will
be multiple sets of delegations.

In reality you have most probably spent more time trying
to find a alternate mechanism than it would have cost you
to just do it. In addition to that you won't have do deal
with a common problem of /16 delegations which is forgetting
to reverse the last two octets.

Mark
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ***@isc.org
Joe Greco
2006-03-02 14:33:11 UTC
Permalink
Post by Mark Andrews
Post by Joe Greco
Post by Mark Andrews
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.
Post by Mark Andrews
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
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.ARPA
$GENERATE 0-255 $.125.168.192.IN-ADDR.ARPA CNAME $.125.0/17.168.192.IN-ADDR.ARPA
$GENERATE 0-255 $.126.168.192.IN-ADDR.ARPA CNAME $.126.0/17.168.192.IN-ADDR.ARPA
$GENERATE 0-255 $.127.168.192.IN-ADDR.ARPA CNAME $.127.0/17.168.192.IN-ADDR.ARPA
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.

Over on NS2, you need a fourth script to generate the named.conf section.

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.

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.
Post by Mark Andrews
Post by Joe Greco
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(CNN)
With 24 million small businesses in the US alone, that's way too many apples.
Mark Andrews
2006-03-02 21:32:10 UTC
Permalink
Post by Joe Greco
Post by Mark Andrews
Post by Joe Greco
Post by Mark Andrews
RFC 2317 is a good fit for /25 - /32. It was never intended fo
r
Post by Mark Andrews
Post by Joe Greco
Post by Mark Andrews
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.
Post by Mark Andrews
Normal delegation gives you 256 PTR records per zone for /24s w
hich
Post by Mark Andrews
Post by Joe Greco
Post by Mark Andrews
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
Post by Mark Andrews
Post by Joe Greco
Post by Mark Andrews
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
Post by Mark Andrews
Post by Joe Greco
Post by Mark Andrews
...
255.3.168.192.IN-ADDR.ARPA CNAME 255.3.0/22.168.192.IN-ADDR.ARP
A
Post by Mark Andrews
Post by Joe Greco
Post by Mark Andrews
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
Post by Mark Andrews
$GENERATE 0-255 $.1.168.192.IN-ADDR.ARPA CNAME $.1.0/22.168.192.IN-ADDR.ARP
A
Post by Mark Andrews
$GENERATE 0-255 $.2.168.192.IN-ADDR.ARPA CNAME $.2.0/22.168.192.IN-ADDR.ARP
A
Post by Mark Andrews
$GENERATE 0-255 $.3.168.192.IN-ADDR.ARPA CNAME $.3.0/22.168.192.IN-ADDR.ARP
A
Post by Mark Andrews
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.
$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.
Post by Joe Greco
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.
Post by Joe Greco
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.
Post by Joe Greco
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.
Post by Joe Greco
Post by Mark Andrews
Post by Joe Greco
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: ***@isc.org
Joe Greco
2006-03-02 21:40:55 UTC
Permalink
Post by Mark Andrews
Post by Joe Greco
Post by Mark Andrews
Post by Joe Greco
Post by Mark Andrews
RFC 2317 is a good fit for /25 - /32. It was never intended fo
r
Post by Mark Andrews
Post by Joe Greco
Post by Mark Andrews
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.
Post by Mark Andrews
Normal delegation gives you 256 PTR records per zone for /24s w
hich
Post by Mark Andrews
Post by Joe Greco
Post by Mark Andrews
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
Post by Mark Andrews
Post by Joe Greco
Post by Mark Andrews
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
Post by Mark Andrews
Post by Joe Greco
Post by Mark Andrews
...
255.3.168.192.IN-ADDR.ARPA CNAME 255.3.0/22.168.192.IN-ADDR.ARP
A
Post by Mark Andrews
Post by Joe Greco
Post by Mark Andrews
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
Post by Mark Andrews
$GENERATE 0-255 $.1.168.192.IN-ADDR.ARPA CNAME $.1.0/22.168.192.IN-ADDR.ARP
A
Post by Mark Andrews
$GENERATE 0-255 $.2.168.192.IN-ADDR.ARPA CNAME $.2.0/22.168.192.IN-ADDR.ARP
A
Post by Mark Andrews
$GENERATE 0-255 $.3.168.192.IN-ADDR.ARPA CNAME $.3.0/22.168.192.IN-ADDR.ARP
A
Post by Mark Andrews
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.
$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.
Post by Mark Andrews
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...
Post by Mark Andrews
It only the examples
in the RFC's to give context. It's not required in most
cases.
Post by Joe Greco
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.
Post by Mark Andrews
Post by Joe Greco
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.
Post by Mark Andrews
Post by Joe Greco
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.
Post by Mark Andrews
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.
Loading...