Delayed Zone Transfers?

Phil Mayers p.mayers at
Mon Aug 6 18:37:50 UTC 2012

On 08/06/2012 05:33 PM, Jiann-Ming Su wrote:

> Yeah, I've wondered about views.  We went to views to work around a
> MTA config issue.  The weird zone transfer performance seem to have
> coincided with our transition to views.  Here's my named.conf, FWIW:
> view hc { include "/etc/named.zones";
> view all { include "/etc/named.zones";

You are "include"ing a set of zone defintions in two different views
here. Since your example zone doesn't appear to be in the main file, I
assume it's in the included file?

If so, this won't work, and will cause the problem you're seeing.
Basically you've got two views trying to write two different zones to
the same file and journal, but with distinct ideas of the in-memory 
contents. Only one receives a notify and does IXFRs.

If you want a zone in two views, it must either be:

  1. A simple "type master" with no DDNS allowed, or
  2. Written to different files

In addition, NOTIFY is like any other DNS packet, and specifically it 
goes into a "view". This makes slaving a zone twice tricky - there is a 
recipie in the FAQ using TSIG keys for this.

> For the particular case I demonstrated in the previous email, I don't
> think views should have affected it as the default "all" view should

Yes. But as per your *other* message, the notify (and therefore the 
IXFR) happened in the "hc" view, so it's the one up-to-date:

06-Aug-2012 11:20:36.575 notify: client view hc: 
received notify for zone 'uts-sa.mydomain.ddns': TSIG ''

The "all" view will have to wait until the SOA refresh timer expires, 
which explains your delay in the zone updating.

> have been hit.  And even the "hc" view, the data would be the same as
> we're only "spoofing" for the specific mail hosts.

No. As above, this is not how views works with changing zone contents. 
You can't write to the same file from two zones I'm afraid.

More information about the bind-users mailing list