Splitting off a sub-zone "atomically"

[Mark Andrews]

In message <4BE82427.5060804 at imperial.ac.uk>, Phil Mayers writes:
> We're doing some DNSSEC testing with sub-zones of our main zone, and I 
> had a little accident largely due to my own incompetence today where I 
> basically did this:
> 
> 1. Existing zone "example.com"; create new zone "sub.example.com"
> 
> 2. Run a SQL->DNS update; *.sub.example.com RRs are removed from 
> "example.com", and added to "sub.example.com"
> 
> 3. Slaves immediately get the NOTIFY for "example.com" and remove the 
> records via IXFR, but aren't yet configured for "sub.example.com" (cron 
> job hasn't yet run)
> 
> 4. Some time later, the cron job runs
> 
> 
> Obviously between 3 & 4 we weren't resolving "sub.example.com" on the 
> slaves. Tedious.
> 
> 
> This got me thinking. When I have this:
> 
> zone "example.com" {
>    type slave;
>    master 192.168.1.1;
>    file "zones/example.com";
> };
> 
> ...and I then append this:
> 
> zone "sub.example.com" {
>    ...
> };
> 
> ...and issue an "rndc reload", does bind NXDOMAIN any queries for 
> "sub.example.com" between the "reload" and the AXFR finishing? Or does 
> it wait until the zone is fully downloaded before inserting it into the 
> internal lookup "tree" (or whatever)?

It SERVFAILs the query as it doesn't have the data to respond to
it.  Iterative resolvers should move onto the next server on SERVFAIL.

> Obviously I can change my procedures to do:
> 
>   1. Create zone on master
>   2. For each slave:
>      a. axfr file from master
>      b. add zone into /etc/named.conf
>      c. rndc reload
>   3. On master, remove *.sub.example.com RRs from example.com
> 
> ...but I was just curious.
> 
> _______________________________________________
> bind-users mailing list
> bind-users at lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka at isc.org