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
