XFRIN/TSIG fails from NSD (primary) server: TSIG verify fail: FORMERR
JINMEI Tatuya / 神明達哉
jinmei at isc.org
Sun Sep 2 09:13:13 UTC 2012
At Sat, 01 Sep 2012 19:33:40 +0200,
"Christian 'wiwi' Wittenhorst" <wiwi at progon.net> wrote:
> > If it's an experimental setup, I'd first try to remove the TSIG
> > configuration and see if it works. I'd also check whether there's any
> > TSIG related error logged at the primary (NSD) side.
>
> Works fine without TSIG. BUT: other zones (as "as34288.ch." or
> "32.234.46.in-addr.arpa.") WORK FINE on the same server WITH TSIG
> ENABLED (same source, identical setup).
>
> There are no log entries on the NSD side.
Okay, I wasn't aware of it but apparently NSD skips TSIG in some of
the intermediate messages of the AXFR response as documented in
Section 4.4 of RFC2845:
#define AXFR_TSIG_SIGN_EVERY_NTH 96 /* tsig sign every N packets. */
/* check if it needs tsig signatures */
if(query->tsig.status == TSIG_OK) {
if(query->tsig.updates_since_last_prepare >= AXFR_TSIG_SIGN_EVERY_NTH) {
query->tsig_sign_it = 1;
}
}
In the other two cases the responses were small enough that they fit
in a single DNS message, which is why it worked.
We are aware of this missing feature:
http://bind10.isc.org/ticket/1357
but have been leaving it open as a lower priority task so far. Now
that we know it causes interoperability problems with at least two
different implementations, we should probably raise the priority.
In the mean time, if it's acceptable, the only workaround seems to
disable TSIG (it doesn't seem to be configurable at NSD) for this
particular zone. Sorry for your inconvenience, hopefully we can fix
it soon enough.
---
JINMEI, Tatuya
Internet Systems Consortium, Inc.
More information about the bind10-users
mailing list