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 _______________________________________________ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
