IXFR & manually edited zone files
David Coulthart
davec at columbia.edu
Mon Mar 7 17:24:10 UTC 2011
On Mar 7, 2011, at 11:42 AM, Chris Thompson wrote:
> On Mar 7 2011, David Coulthart wrote:
>> BIND Version: 9.7.3 on Solaris 9 & 10 (locally compiled)
>>
>> Our current workflow for managing DNS involves generating master zone
>> files from a database, pushing the new files to a hidden master nameserver
>> & then running "rndc reload" on that nameserver.
>>
>> Based on the ARM & a posting to bind-users[1], I enabled "ixfr-from-differences
>> master;" on the hidden master expecting the master nameserver would generate
>> a "diff" from the previous zone file in memory and the new one being loaded
>> so it could send an IXFR to the slaves. However, every time the slave
>> requests an IXFR, it gets a non-incremental response & has to perform a
>> full AXFR. I've configured this in a test environment with a single zone
>> file so I know the slave has the first version of the zone file before
>> loading the second version on the master & it still results in a AXFR-style
>> IXFR. I've explicitly stated the options allow-query & allow-transfer
>> in the config, but I do not have allow-updates configured, relying on
>> the implicit default of denying all updates.
>>
>> Is there something I'm missing to get this working?
>
> Have you tested that the ixfr-from-differences is working at all at
> the hidden master? E.g. by
>
> dig ixfr=[some-old-serial] [zone-name] @[hidden-master]
>
> from the slaves (or indeed elsewhere).
In my initial testing I enabled debug level 3 on both the master & slave. In the slave's log I saw the following:
transfer of 'example.com/IN' from 128.59.59.124#53: requesting IXFR for serial 2011030701
transfer of 'example.com/IN' from 128.59.59.124#53: sent request length prefix
transfer of 'example.com/IN' from 128.59.59.124#53: sent request data
transfer of 'example.com/IN' from 128.59.59.124#53: got nonincremental response
I just tested again using dig as you described above and still got a full AXFR even when specifying the serial # that was in the zone file before the reload. From the master's log:
client 127.0.0.1#34246: zone transfer 'example.com/IXFR/IN' approved
client 127.0.0.1#34246: transfer of 'example.com/IN': AXFR-style IXFR started
client 127.0.0.1#34246: transfer of 'example.com/IN': AXFR-style IXFR ended
> There is also a named-journalprint utility which you can apply to the
> journal file on the master to check it contains what you hope for.
I don't see a journal file being created on the master after I do the reload. The only messages in the master's log about a journal are on initial startup:
zone example.com/IN: starting load
zone example.com/IN: number of nodes in database: 256
no journal file, but that's OK
zone example.com/IN: journal rollforward completed successfully: no journal
zone example.com/IN: loaded
decrement_reference: delete from rbt: 2468d0 example.com
zone_settimer: zone example.com/IN: enter
zone example.com/IN: loaded serial 2011030701
On rndc reload, I don't see any mention of a journal being created or destroyed:
zone example.com/IN: starting load
dns_zone_maintenance: zone example.com/IN: enter
zone_settimer: zone example.com/IN: enter
zone_loaddone: zone example.com/IN: enter
zone example.com/IN: number of nodes in database: 766
zone example.com/IN: loadeddecrement_reference: delete from rbt: 246ed0 example.com
replacing zone database
calling free_rbtdb(example.com)
adjust_quantum -> 325
zone_settimer: zone example.com/IN: enter
zone example.com/IN: loaded serial 2011030702
done free_rbtdb(example.com)
Based on the description of ixfr-from-differences in the ARM, I think a journal file should be created. I have named running as user named, but I've checked permissions on the directory & zone file & confirmed that named can create files in the directory containing the zone file.
> If those look OK, then it's something else in the configuration of
> either master or slaves. I take it you aren't doing anything as
> obvious as specifying "request-ixfr no" or "provide-ixfr no" in
> server statements.
I do not explicitly set these options in my config, relying on them defaulting to yes.
Thanks for your help Chris.
Dave Coulthart
More information about the bind-users
mailing list