TSIG for the Xfrin module?

[Spain, Dr. Jeffry A.]

> Hmm, did I really suggest an ACL for xfrin?  Maybe I confused you, but no, ACL is not required for xfrin; in fact it doesn't make sense because xfrin is a "client" (ACLs are generally for "servers").

> Also, I suspect you don't have to specify the global tsig_keys/keys for this purpose (you'll need it for TSIG + xfrout), although it should be harmless.

> These TSIG key names must be identical.  If you specify "nstest.key" in one configuration, you should specify the same name for the other, not (e.g.) "nstest-bind10.jaspain.net", or vice versa.

>> Also despite logging being set to DEBUG level 40 on bind10, there were no log entries recorded in relation to this failed update. I'm not sure what is going on there. The last log entries are from 4 hours ago when I configured the keys.

>Hmm, that's strange.  At least according to the source code, it should be logged with the ID XFRIN_XFR_TRANSFER_FAILURE at the log level of "error".

Based on your recommendations above, I altered the bind9 key name as follows:
key nstest-bind10 {
        algorithm hmac-sha256;
        secret "WGKBvYaFKyxfVTddV+EE43uXN9BKoxpBuIHmFelzoN0=";
};

server 2001:4870:20ca:158:14ff:7695:9632:e9ec {
        keys { nstest-bind10; };
};

I altered the bind10 configuration as follows, omitting the global tsig_keys/keys and changing the key name to match bind9:
> config show Zonemgr/secondary_zones
Zonemgr/secondary_zones[0]/class        "IN"    string
Zonemgr/secondary_zones[0]/name "jaspain.net"   string
> config show Xfrin/zones
Xfrin/zones[0]/name     "jaspain.net"   string
Xfrin/zones[0]/class    "IN"    string  (default)
Xfrin/zones[0]/master_addr      "2001:4870:20ca:158:4423:f19d:4ead:5c20"        string
Xfrin/zones[0]/master_port      53      integer (default)
Xfrin/zones[0]/tsig_key "nstest-bind10:WGKBvYaFKyxfVTddV+EE43uXN9BKoxpBuIHmFelzoN0=:hmac-sha256"        string
Xfrin/zones[0]/use_ixfr false   boolean (default)

The zone did not load immediately. I think this is because I entered the Zonemgr configuration before the Xfrin configuration. This resulted in a log message:
2011-12-08 22:03:05.335 ERROR [b10-xfrin.xfrin] XFRIN_COMMAND_ERROR error while executing command 'refresh_from_zonemgr': Master address not given or configured for jaspain.net.

I restarted bind10, and then the zone did load. The bind9 log showed the TSIG key being used:
Dec  8 21:51:34 nstest named[807]: client 2001:4870:20ca:158:14ff:7695:9632:e9ec#48301/key nstest-bind10 (jaspain.net): transfer of 'jaspain.net/IN': AXFR started: TSIG nstest-bind10
Dec  8 21:51:34 nstest named[807]: client 2001:4870:20ca:158:14ff:7695:9632:e9ec#48301/key nstest-bind10 (jaspain.net): transfer of 'jaspain.net/IN': AXFR ended

The bind10 log also showed the zone transfer, but no mention of TSIG being used:
2011-12-08 22:05:49.002 INFO  [b10-xfrin.xfrin] XFRIN_XFR_TRANSFER_STARTED AXFR transfer of zone jaspain.net/IN started
2011-12-08 22:05:49.049 DEBUG [b10-xfrin.xfrin] XFRIN_GOT_NONINCREMENTAL_RESP got nonincremental response for jaspain.net/IN
2011-12-08 22:05:49.050 DEBUG [b10-xfrin.datasrc] DATASRC_SQLITE_NEWCONN SQLite3Database is being initialized
2011-12-08 22:05:49.050 DEBUG [b10-xfrin.datasrc] DATASRC_SQLITE_CONNOPEN Opening sqlite database file '/var/bind10-devel/zone.sqlite3'
2011-12-08 22:05:49.050 WARN  [b10-xfrin.libxfrin] LIBXFRIN_DIFFERENT_TTL multiple data with different TTLs (0, 3600) on %3/%4. Adjusting 3600 -> 0.
2011-12-08 22:05:49.059 DEBUG [b10-xfrin.datasrc] DATASRC_SQLITE_DROPCONN SQLite3Database is being deinitialized
2011-12-08 22:05:49.059 DEBUG [b10-xfrin.datasrc] DATASRC_SQLITE_CONNCLOSE Closing sqlite database
2011-12-08 22:05:49.059 INFO  [b10-xfrin.xfrin] XFRIN_XFR_TRANSFER_SUCCESS AXFR transfer of zone jaspain.net/IN succeeded

Next I did an 'rndc reload' on the bind9 master to see how a notify query would behave. Once again I got the "Bad key (17)" error in the response from bind10. Just as in my previous test there were no bind10 log messages relating to this. This seems like it may be a bug, since the TSIG key is being used successfully in the initial zone transfer, but it fails with the notify. I have attached tcpdump.zip containing files initial_load.cap and notify.cap demonstrating this behavior. I'm not sure what to try next to get around the notify problem, and would be grateful for your suggestions. Thanks. Jeff.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: tcpdump.zip
Type: application/x-zip-compressed
Size: 5248 bytes
Desc: tcpdump.zip
URL: <https://lists.isc.org/pipermail/bind10-users/attachments/20111209/9b608955/attachment.bin>