TSIG for the Xfrin module?

[Spain, Dr. Jeffry A.]

> Ah, that's because you removed the global TSIG config.  Notifies are parsed and process by b10-auth, not xfrin, and b10-auth refers to the global config for TSIGs, so to make notifies work you'll need to specify it again.

I tried it again with the global tsig_keys/keys added back to the configuration.

First of all, I can confirm that by configuring Xfrin/zones before Zonemgr/secondary_zones, the zone data gets transferred immediately after the secondary_zones configuration is committed. If I configure Zonemgr/secondary_zones before Xfrin/zones, then I have to restart bind10 to get the zone to load. There's probably a way to trigger the zone transfer request without restarting bind10 as a whole. What is that?

As you suggested, with the global tsig_keys/keys in place, there is no longer a bad key error in response to the notify query. However despite no change in the zone serial number, bind10 does an AXFR query again just after the notify. This seems like a bug, although I may not understand the situation completely. I captured this activity with tcpdump into initial_load.cap and notify.cap, which are included in the attached tcpdump.zip along with bind10.log.

By the way in bind10.log, there are a couple of messages of the form "WARN  [b10-xfrin.libxfrin] LIBXFRIN_DIFFERENT_TTL multiple data with different TTLs (0, 3600) on %3/%4. Adjusting 3600 -> 0." I'm not sure what that means, but suspect that "on %3/%4" may represent a failed parameter substitution in this particular call to your logging routine.

Thanks. Jeff.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: tcpdump.zip
Type: application/x-zip-compressed
Size: 10853 bytes
Desc: tcpdump.zip
URL: <https://lists.isc.org/pipermail/bind10-users/attachments/20111209/950877a7/attachment.bin>