splitting reverse-zone-file

[Kevin Darcy]

Holger Honert wrote:

>Hi all,
>
>actually we have a reverse zone-file (class B) such as
>19.172.in-addr.arpa which contains multiple (ca. 24) class C-networks.
>
Pet peeve. 172.19.*/24 (where * is any legal value) is not a "class 
C-network[]". Class C networks have a first octet in the 191 through 223 
range. These are plain old /24 subnets of a /16, which just happens to 
be a Class B.

I don't know why folks still refer to network classes any more. But if 
they do they should at least refer to them _correctly_.

>Everything is working fine with ms 2003 and 2k Server in an Active
>Directory environment but the registration of the famous [;-)] ILO
>(inside light out) boards do fail.
>
>They want to add their PTR-Records in the /24 domain and no where else,
>so they get NOT AUTH.
>
>Nevertheless our sysadmins requested me to split the domains in /24 zones.
>
>So my question is how to split the zone? Has someone developed a script
>(perl or shell) to do so? Is there maybe an alternative way?
>
With Perl and the Net::DNS module you could do a zone transfer of 
19.172.in-addr.arpa, munge up the contents in memory, and spit out a 
bunch of nsupdate commands into two files that would a) manipulate the 
19.172.in-addr.arpa zone to delete the leaf node records and add the 
delegation records for the subzones, and b) populate the subzones with 
the leaf nodes that were previously deleted from the 19.172.in-addr.arpa 
zone. In between those nsupdate runs, you'd reconfig/reload the 
nameserver with the new subzone definitions. Make sure to use nsupdate's 
"zone" and "server" directives: not only will that speed things up, 
since nsupdate won't have to do any lookups to determine zone identity 
and master, but it will also prevent zone identity confusion with 
respect to the zone cut (i.e. adding the new delegation records). While 
you're doing all of this, of course, you might want to limit query 
access to the nameserver, so that DNS clients don't get completely 
confused by the transient state of the database. Ditto for zone 
transfers -- disable those until everything is completely updated.

If you want to get really fancy, I suppose you could even use the 
Dynamic Update capabilities of the Net::DNS module to pre-compose a 
bunch of Dynamic Update packets which could then be thrown at the master 
server in quick succession (or even in parallel), to save some time. But 
I haven't gone quite that far with the Net::DNS module, so I can't speak 
from experience on such a technique.

                                                                         
                                                   - Kevin