Is there an incompatibility between 9.16.37/9.18.11 and 9.9 when doing HMAC-MD5 AXFR?

[Greg Choules]

Hi Patrik. 9.9? Classic! :D
I don't believe there should be any incompatibilities. Are you perhaps
falling foul of this? From Cricket's book, chapter 11

It’s important that the name of the key—not just the binary data the key
points to— be identical on both ends of the transaction. If it’s not, the
recipient tries to verify the TSIG record and finds it doesn’t know the key
that the TSIG record says was used to compute the hash value. That causes
errors such as the following:

Jan 4 16:05:35 wormhole named[86705]: client 192.249.249.1#4666: request
has invalid signature: TSIG tsig-key.movie.edu: tsig verify failure
(BADKEY)

I'd take packet captures of both cases and compare them, see what the
differences are.
Hope that helps.
Greg

On Tue, 21 Feb 2023 at 16:06, Patrik.Graser--- via bind-users <
bind-users at lists.isc.org> wrote:

> Hi all
>
>
>
> Due to circumstances beyond my control a remote partner needs to use a
> 9.9.9 version of bind and we are required to use HMAC-MD5 for zone
> transfers. There is no (big) security concern since the networks are
> isolated and not exposed to the larger Internet.
>
>
>
> When the secondary requests an AXFR I see:
>
> client @0xxxxxxxxxxxxx nnn.nnn.nnn.nnn#xxxxxx: request has invalid
> signature: TSIG <KEY>: tsig verify failure (BADSIG)
>
>
>
> Doing a dig directly (with the same key) I get the zone:
>
> client @0xxxxxxxxxxxxx nnn.nnn.nnn.nnn#xxxxxx /key <KEY> (zone.tld):
> transfer of ‘zone.tld/IN': AXFR started: TSIG <KEY> (serial nnnn)
>
>
>
> Is there any known incompatibilities – preferably with workarounds :) -
> that anyone knows about?
>
>
>
> I apologize in advance if the info is lacking but here are, what I
> consider, the relevant parts from named.conf:
>
>
>
> key "<KEY>." {
>
>         algorithm hmac-md5;
>
>         secret "XXXXXXXXXXXXXXXXXXXXXX";
>
> };
>
>
>
> acl servers {
>
>         nnn.nnn.nnn.nnn;
>
>         nnn.nnn.nnn.nnn;
>
>         nnn.nnn.nnn.nnn;
>
> };
>
>
>
> acl transfer {
>
>         !servers;
>
>         !localhost;
>
>         !nnn.nnn.nnn.nnn;
>
>         any;
>
> };
>
>
>
> zone "zone.tld." IN {
>
>         type master;
>
>         file "/etc/bind/zones/zone.file";
>
>         allow-transfer { !transfer; key <KEY>.; };
>
> };
>
>
>
> Again – sorry if this is insufficient information.
>
> It could be as simple as the remote not having everything in order but
> they swear up and down that they have checked, doublechecked and enlisted
> multiple persons in doing the checks.
>
>
>
> I would appreciate any and all hints even if they are farfetched.
>
>
>
> Best Regards
>
> Patrik Graeser
> --
> Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
> from this list
>
> ISC funds the development of this software with paid support
> subscriptions. Contact us at https://www.isc.org/contact/ for more
> information.
>
>
> bind-users mailing list
> bind-users at lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20230221/e0b52c69/attachment.htm>