Master <--> slave named.conf "auto-generation"

[Kevin Darcy]

% dig _index axfr

; <<>> DiG 9.3.2 <<>> _index axfr
; (1 server found)
;; global options:  printcmd
_index.                 86400   IN      SOA     ns1.chysler.com. 
dnsadm.chrysler.com. 221 21600 3600 3600000 3600
_index.                 3600    IN      NS      ns1.chrysler.com.
_index.                 3600    IN      NS      ns2.chrysler.com.
_index.                 3600    IN      PTR     .
_index.                 3600    IN      PTR     chrysler.com.
_index.                 3600    IN      PTR     abc.chrysler.com.
_index.                 3600    IN      PTR     xyz.chrysler.com.
_index.                 3600    IN      PTR     in-addr.arpa.
_index.                 3600    IN      PTR     172.in-addr.arpa.
_index.                 3600    IN      PTR     16.172.in-addr.arpa.
_index.                 3600    IN      PTR     17.172.in-addr.arpa.
...

(Just an anonymized example, of course, but you get the idea).

The reason for using PTRs instead of TXT RRs is that they benefit from 
label compression.

                                                                         
                        - Kevin

Baird, Josh wrote:
> Kevin,
>  
> Could you elaborate on your "index" zone?  Sorry, but I'm a bit confused here.
>  
> Thanks,
>  
> Josh
> ________________________________
>
> From: bind-users-bounce at isc.org on behalf of Kevin Darcy
> Sent: Thu 3/13/2008 6:43 PM
> To: bind-users at isc.org
> Subject: Re: Master <--> slave named.conf "auto-generation"
>
>
>
> bsd wrote:
>   
>> Hello,
>>
>> I would like to know if there is a way, whenever a new zone definition 
>> is added to the primary master server, to have the slaves 
>> automatically configure themselves with matching slave-zone definitions?
>>
>> If not - what are people currently using to acomplish this task?
>>
>> Have you got any good script that could help me achieve that in an 
>> "elegant" way?
>>
>> What are the best path to achieve this knowing that I could have 
>> master and slave file generated on one server (the master), how would 
>> you handle the propagation of the named.conf (slave) file and signal 
>> (rndc reload) and the slave?
>>
>>
>> Any other advise / experience / experiment are welcome.
>>
>>
>>  
>>     
> We have a homegrown script that runs on all of our slaves (we have
> dozens of them) nightly and looks at an "index" zone -- a zone with one
> record per zone to be slaved. If the "index" zone has changed, it
> rebuilds the named.conf based on the contents of the "index" zone and
> does a reload. The big assumption of the script is that all of these
> "automatic" zone definitions on all of the slaves are identical (with
> the exception of "masters" and/or "also-notify"), but that's only a
> _default_ assumption, since there is a provision for overriding the
> "automatic" zone defintion with a "customized" version for any given
> zone on any given slave. Also, since we have multiple levels of slaves,
> there's a fairly elaborate "replication topology" subsystem for
> determining the respective contents of the "masters" and "also-notify"
> clauses on the various slaves.
>
>                                                                         
>                         - Kevin
>
>
>
>
>
>
>
>
>