splitting reverse-zone-file
Kevin Darcy
kcd at daimlerchrysler.com
Tue Mar 7 23:27:10 UTC 2006
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
More information about the bind-users
mailing list