Probable bug with BIND9 tsig zone transfers

[Roberts-Thomson, James]

Hi,
I have discovered a probable bug with TSIG-based zone transfers between
a couple of different versions on BIND 9.  I can't explain what is going
on, and was hoping that someone could either confirm that this is a bug,
or provide a reasonable explaination for the behaviour.

A Primary (master) DNS server is setup with Bind 9.2.3 (I know this is
downrev slightly).  The named.conf for the primary server and zone files
for the two zones that exhibit the error are shown here:

Named.conf:
options { directory "/var/named"; pid-file "/var/run/named.pid";
recursion yes; };
controls { inet * allow { any; } keys { rndc_key;  }; };
key rndc_key { algorithm hmac-md5;  secret "qfg5z+8Ns4LVHhvFcKqG8w==";
};
key ninechars { algorithm hmac-md5; secret "IzaTyM4aNBoQ8G2taGmE0A==";
};
server 172.16.44.105 { keys { ninechars; }; };
server 192.168.28.27 {  keys { ninechars; }; };
zone "0.0.127.in-addr.arpa" { type master; file
"zones/0.0.127.in-addr.arpa.db"; };
zone "unix.nbnz.co.nz" { type master; allow-transfer { key ninechars; };
file "zones/unix.nbnz.co.nz.db"; };
zone "99.16.172.in-addr.arpa" { type master; notify yes; allow-update {
key ninechars; }; allow-transfer { key ninechars; };
 file "zones/99.16.172.in-addr.arpa.db"; };
zone "100.16.172.in-addr.arpa" { type master; notify yes; allow-update {
key ninechars; }; allow-transfer { key ninechars; };
 file "zones/100.16.172.in-addr.arpa.db";
};

99.16.172.in-addr.arpa.db:
$TTL 86400      ; 1 day
100.16.172.in-addr.arpa.    IN SOA  ns1.unix.nbnz.co.nz.
postmaster.unix.nbnz.co.nz. (
                                1         ; serial
                                7200       ; refresh (2 hours)
                                3600       ; retry (1 hour)
                                3600000    ; expire (5 weeks 6 days 16
hours)
                                86400      ; minimum (1 day)
                                )
                        NS      ns1.unix.nbnz.co.nz.
                        NS      ns2.unix.nbnz.co.nz.
$ORIGIN 100.16.172.in-addr.arpa.

100.16.172.in-addr.arpa.db:
$TTL 86400      ; 1 day
99.16.172.in-addr.arpa.    IN SOA  ns1.unix.nbnz.co.nz.
postmaster.unix.nbnz.co.nz. (
                                1         ; serial
                                7200       ; refresh (2 hours)
                                3600       ; retry (1 hour)
                                3600000    ; expire (5 weeks 6 days 16
hours)
                                86400      ; minimum (1 day)
                                )
                        NS      ns1.unix.nbnz.co.nz.
                        NS      ns2.unix.nbnz.co.nz.
$ORIGIN 99.16.172.in-addr.arpa.

The secondary DNS is running Bind 9.3.2, and is configured to transfer
the two zones via the same TSIG key.

The actual problem is that the 99.16.172.in-addr.arpa zone successfully
transfers, whereas the 100.16.172.in-addr.arpa zone doesn't.  Partial
log shown here:

03-Nov-2006 09:16:51.343 zone 0.0.127.in-addr.arpa/IN: loaded serial 1
03-Nov-2006 09:16:51.346 running
03-Nov-2006 09:16:51.364 zone 100.16.172.in-addr.arpa/IN: refresh:
failure trying master 156.13.44.105#53 (source 0.0.0.0#0): tsig verify
failure
03-Nov-2006 09:16:51.872 zone 99.16.172.in-addr.arpa/IN: Transfer
started.
03-Nov-2006 09:16:51.872 zone 10.16.172.in-addr.arpa/IN: Transfer
started.
03-Nov-2006 09:16:51.884 transfer of '99.16.172.in-addr.arpa/IN' from
156.13.44.105#53: connected using 214.5.28.27#38251
03-Nov-2006 09:16:51.884 transfer of '10.16.172.in-addr.arpa/IN' from
156.13.44.105#53: connected using 214.5.28.27#38252
03-Nov-2006 09:16:51.931 zone 99.16.172.in-addr.arpa/IN: transferred
serial 1: TSIG 'ninechars'
03-Nov-2006 09:16:51.931 transfer of '99.16.172.in-addr.arpa/IN' from
156.13.44.105#53: end of transfer
03-Nov-2006 09:16:51.932 zone 99.16.172.in-addr.arpa/IN: sending
notifies (serial 1)
03-Nov-2006 09:16:51.942 zone 10.16.172.in-addr.arpa/IN: transferred
serial 1: TSIG 'ninechars'
03-Nov-2006 09:16:51.943 transfer of '10.16.172.in-addr.arpa/IN' from
156.13.44.105#53: end of transfer
03-Nov-2006 09:16:51.943 zone 10.16.172.in-addr.arpa/IN: sending
notifies (serial 1)
03-Nov-2006 09:16:58.413 shutting down

Notice the "tsig verify failure" above.

Now this is the bit that I think clearly defines the bug.  You'll notice
the TSIG key name is "ninechars", which is 9 characters long.  If I
change the TSIG key NAME on both sides to something that is 8 characters
long (i.e. "ninechar"), then the whole thing works.  The actual key
doesn't change, just the name.

Additionally, if I leave the keyname at nine chars long, but alter the
zone file for the zone "unix.nbnz.co.nz" (which you'll notice is hosts
the NS records for the two reverse zones) to REMOVE the entry for "ns2",
then it works.

Also, any other reverse zone of xx.16.172.in-addr.arpa transfers OK,
whereas any zone of xxx.16.172.in-addr.arap doesn't.

Lastly, DIG works perfectly regardless.

This doesn't seem to be any logical reason for this as far as I can see,
hence my conclusion that it is a bug.

I have managed to replicate this issue in a test lab setup, but for
anyone wishing to try this, please be aware that zone name length and
key name length play a part in this bug, and therefore must be "right"
in order to hit the bug.

Thanks in advance for any help / advice.

James Roberts-Thomson
Senior Systems Engineer (Unix)
Project Delivery NZ
Infrastructure Management
ANZ National Bank Limited 
Tel: +64 4 494-4436

My apologies for the following automatic disclaimer:


"This communication is confidential and may contain privileged and/or copyright material. If you are not the intended recipient you must not use, disclose, copy or retain it. If you have received it in error please immediately notify me by return email, delete the emails and destroy any hard copies. ANZ National Bank Limited does not guarantee the integrity of this communication, or that it is free from errors, viruses or interference."