Breaking up RFC 1918 reverse space

[Karl Auer]

On Sun, 2011-07-24 at 01:01 +0000, Laws, Peter C. wrote:
> Decloaking to ask for pointers to some help regarding RFC 1918 zone
> delegation.  
> 
> We use 10/8 space extensively over multiple campuses.  We need to
> delegate at the 10/ essentially, the 10/16 level.  Is there a better
> way to do it than

Maybe this is an overly naive approach, but can't you set up one zone
for 10.0.0.0/8 and delegate as necessary from that single zone file?
Anything that you don't have an answer for will get NXDOMAIN, which is
presumably what you want.

So:

   zone "10.IN-ADDR.ARPA" {
           type master;
           file "internal/db.10.rev";
           allow-query { network_internal; };
   };

Then in the zone file internal/db.0.rev:

   $ORIGIN 10.in-addr.arpa.
   [...]
   0 3600 IN NS ns00.mydomain.
   1 3600 IN NS ns01.mydomain.
   ... etc

Your forward zone for mydomain would need entries for the ns00, ns01
etc.
   
ns00, ns01 etc are the nameservers to which 0.10.in-addr.arpa,
1.10.in-addr.arpa etc are delegated. Those servers will then have conf
entries like:

   zone "0.10.IN-ADDR.ARPA" {
           type master;
           file "internal/db.10.0.rev";
           allow-query { network_internal; };
   };

and in the zone file internal/db.10.0.rev on ns00, for example, entries
for the subnet:

   $ORIGIN 0.10.in-addr.arpa.
   [...]
   @ 3600 IN NS ns00.mydomain.
   ...
   1.1 3600 IN PTR gw.mydomain.
   2.1 3600 IN PTR somehost.mydomain.
   ... etc

The other delegated nameservers would have zone files like db.10.1.rev,
db.10.2.rev etc with the appropriate zone data for those /16 subnets of
10.0.0.0/8.

In short, all the delegations are in one zone file. You do still need
one delegation per delegated subnet, there's no way around that.

All this is off the top of my head, so treat with great caution :-)

Regards, K.




> zone "1.10.IN-ADDR.ARPA" {
>         type master;
>         file "internal/db.10.rev";
>         allow-query { network_internal; };
> };
> 
> zone "2.10.IN-ADDR.ARPA" {
>         type master;
>         file "internal/db.10.rev";
>         allow-query { network_internal; };
> };
> 
> et cetera, ad nauseum and then putting in NS records as necessary?
> 
> A little less than half of the zones would remain with us with the other half-and-a-bit delegated away.  
> 
> I'm afraid of the answer since I fear I'm stuck with making 256 zones ...
> 
> BIND 9.3 as hacked by Red Hat, though now that we found the bind97 packages in the supported repo, we may go with that.  
> 
> --
> Peter Laws / N5UWY
> National Weather Center / Network Operations Center 
> University of Oklahoma Information Technology
> plaws at ou.edu (Remote)
> _______________________________________________
> Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list
> 
> bind-users mailing list
> bind-users at lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users

-- 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Karl Auer (kauer at biplane.com.au)                   +61-2-64957160 (h)
http://www.biplane.com.au/kauer/                   +61-428-957160 (mob)

GPG fingerprint: DA41 51B1 1481 16E1 F7E2 B2E9 3007 14ED 5736 F687
Old fingerprint: B386 7819 B227 2961 8301 C5A9 2EBC 754B CD97 0156
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20110724/36c15bc5/attachment.bin>