Delayed Zone Transfers?

[Jiann-Ming Su]

> From: Jiann-Ming Su <su_js1 at yahoo.com>
> To: "bind-users at lists.isc.org" <bind-users at lists.isc.org>
> Cc: 
> Sent: Monday, August 6, 2012 12:33 PM
> Subject: Re: Delayed Zone Transfers?
> 
>>  From: Phil Mayers <p.mayers at imperial.ac.uk>
>>  To: bind-users at lists.isc.org
>>  Cc: 
>>  Sent: Monday, August 6, 2012 12:07 PM
>>  Subject: Re: Delayed Zone Transfers?
>> 
>>  On 06/08/12 17:03, Jiann-Ming Su wrote:
>> 
>>>   Here's an example of the zone file being updated, but BIND not 
> serving 
>>  out the new data.
>>> 
>>>   Running dig locally:
>>>   # dig @localhost myhost.uts-sa.mydomain.ddns
>> 
>>  I note from your other email that you are using views.
>> 
>>  Are you sure you are querying the right view? It seems that you may be 
> querying 
>>  the view in which the zone is not slaved, hence you get old, cached data.
> 
> 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 {
>         match-clients      { 192.168.0.0/16; 10.236.0.0/16; };
>         match-destinations { any; };
>         include "/etc/named.zones";
> 
>         zone "s7a1.psmtp.com" {
>                 type slave;
>                 file "db.postini-s7a1";
>                 masters { dnsmgr; };
>         };
>         zone "s7a2.psmtp.com" {
>                 type slave;
>                 file "db.postini-s7a2";
>                 masters { dnsmgr; };
>         };
>         zone "s7b1.psmtp.com" {
>                 type slave;
>                 file "db.postini-s7b1";
>                 masters { dnsmgr; };
>         };
>         zone "s7b2.psmtp.com" {
>                 type slave;
>                 file "db.postini-s7b2";
>                 masters { dnsmgr; };
>         };
> };
> 
> view all {
>         match-clients      { any; };
>         match-destinations { any; };
>         include "/etc/named.zones";
> };
> 
> 
> 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 have 
> been hit.  And even the "hc" view, the data would be the same as 
> we're only "spoofing" for the specific psmtp.com mail hosts.
> 

Interestingly, for the one secondary caching old data, it actually did an IXFR as soon as it was notified by the master that the zone had updated.  

Aug 06 11:20:35.067 notify: received notify for zone 'uts-sa.mydomain.ddns'
Aug 06 11:20:35.078 notify: zone uts-sa.mydomain.ddns/IN: sending notifies (serial 2010585437)
Aug 06 11:20:36.083 xfer-out: client 10.140.51.162#51088: transfer of 'uts-sa.mydomain.ddns/IN': IXFR started

However, I just did a "rndc reload" on that zone, and it did a full AXFR:

Aug 06 12:43:35.320 xfer-out: client 10.140.51.162#40496: transfer of 'uts-sa.emory.ddns/IN': AXFR-style IXFR started

After this, it is now serving out fresh data.