Delayed Zone Transfers?
Jiann-Ming Su
su_js1 at yahoo.com
Mon Aug 6 16:51:15 UTC 2012
> 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.
More information about the bind-users
mailing list