TSIG for the Xfrin module?

[JINMEI Tatuya / 神明達哉]

At Fri, 9 Dec 2011 14:35:34 +0000,
"Spain, Dr. Jeffry A." <spainj at countryday.net> wrote:

> 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?

My guess is that in the case of configuring Zonemgr then Xfrin, Xfrin
first rejects the refresh request due to the lack of config.  I
suspect Zonemgr will retry after some "retry" period.  If you need to
invoke the transfer immediately, bindctl retransfer would be an
option.  I believe Zonemgr will subsequently keep track of zone's
status and refresh it.

> 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.

Yes, it's a known problem at the point of the previous release.  It
was fixed in the latest git version, and the fix will appear in the
next release:

338.	[bug]		jinmei
	b10-xfrin didn't check SOA serials of SOA and IXFR responses,
	which resulted in unnecessary transfer or unexpected IXFR
	timeouts (these issues were not overlooked but deferred to be
	fixed until #1278 was completed).  Validation on responses to SOA
	queries were tightened, too.
	(Trac #1299, git 6ff03bb9d631023175df99248e8cc0cda586c30a)

> 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.

Yes, that's another known bug.  But that aside, this seems strange to
me...I thought it couldn't happen for a transfer from a BIND 9
master.  It might be a bug in BIND 10.  If you can reproduce it, can
you apply the patch (which will fix the log format error) and see
which RR causes the log?

---
JINMEI, Tatuya
Internet Systems Consortium, Inc.

diff --git a/src/lib/python/isc/xfrin/diff.py b/src/lib/python/isc/xfrin/diff.py
index 38b7f39..5f49332 100644
--- a/src/lib/python/isc/xfrin/diff.py
+++ b/src/lib/python/isc/xfrin/diff.py
@@ -174,7 +174,8 @@ class Diff:
                                               rrset.get_ttl())))
             if rrset.get_ttl() != buf[-1][1].get_ttl():
                 logger.warn(LIBXFRIN_DIFFERENT_TTL, rrset.get_ttl(),
-                            buf[-1][1].get_ttl())
+                            buf[-1][1].get_ttl(), rrset.get_name(),
+                            rrset.get_class())
             for rdatum in rrset.get_rdata():
                 buf[-1][1].add_rdata(rdatum)
         self.__buffer = buf