Re: Splitting off a sub-zone atomically
On 05/11/2010 09:12 AM, Matus UHLAR - fantomas wrote: On 10.05.10 16:20, Phil Mayers wrote: 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. that's why you should push glue NS records for sub.example.com to example.com pointing to servers that will have those zones (at least some of them must already have them). The same set of NS records should be in sub.example.com of course. We run hidden master, so the (single) server which has the zone at creation time is not queriable. As per my original email, I realise that what I did was sub-optimal - I am asking about bind's behaviour in two slightly different alternatives. Essentially, I guess I'm talking about the requirements for priming the new zone onto the slaves before creating the zone cut, and was wondering what bind did between the rndc reconfig and the AXFR completing. Mark has answered that - it returns SERVFAIL - which is all I wanted to know. 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. creating proper delegation is much safer way to achieve that. It's difficult to see how that alone solves the problem along with a hidden master; you have to at the very least create the zone definition on the slaves first, else they'll NXDOMAIN queries rather than SERVFAIL them. Thanks for all the info. ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Splitting off a sub-zone atomically
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)?
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@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: Splitting off a sub-zone atomically
In message 4be82427.5060...@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@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: ma...@isc.org
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
