Zone Transfer (AXFR) TSIG Signing Changes
Summary
Upgrading from BIND 9.11.5-Debian
to BIND 9.16.37-Debian
causes changes undiagnosable change in HMAC generation for AXFR transfer.
BIND version used
BIND 9.16.37-Debian (Extended Support Version) <id:2b2afb2>
& BIND 9.11.5-P4-5.1+deb10u8-Debian (Extended Support Version) <id:998753c>
Steps to reproduce
For each version of bind (9.11 & 9.16) 0. Make sure that the OS clocks are properly synced and do not use HMAC truncation.
- Use
tsig-keygen
to generate a key (tsig-keygen -a hmac-sha256 my-key
)key "my-key" { algorithm hmac-sha256; secret "NFpecql0ttMve8aDTgQk0UcCnV0vxpBx7fQ8elRTTeU="; };
- Create an authoritative DNS server that allows zone transfer with the above key
zone "testdomain.com." IN { type master; file "/etc/bind/db.testdomain.com."; allow-transfer { key "my-key"; }; };
- Add a single A record
- Add a few records like so
$TTL 60
@ IN SOA ns.tester.com. dns.tester.com. 123 300 60 600 60
@ IN A 1.2.3.4
- Compute a MAC using the (1) Request MAC, (2) Response DNS Msg, (3) TSIG Variables (Fields from the TSIG RR Response)
- Compare the computed MAC and the MAC in the TSIG RR Response
What is the current bug behavior?
With Bind 9.11, the client successfully
- Opens a TCP socket & sends a DNS AXFR request to the bind9 server
- Correctly receives the contents of zone
- Computes the HMAC, and successfully compares the computed HMAC to the response HMAC using the procedure defined in RFC2845 (rfc2845 4.6) /RFC 8495.
After upgrading to Bind 9.16, the client successfully sends a DNS AXFR request to the bind9 server and correctly gets the contents of zone (we can confirm this using dig
). However, the HMAC my DNS client computes is different from the response HMAC (even though they should be the same as defined in RFC8945/RFC2845) - indicating the zone transfer has been tampered with (but it probably hasn't).
I should also note that the validation worked with earlier versions of Bind as well (circa Bind 9.9)
This HMAC signing change may be intentional, but I haven't been able to locate any documented artifacts about AXFR signing changes while reading through the changes from RFC2845 to RFC8945, commit history for tsig.cc, and commit history for xfrout.c
.
If this is the expected behavior - is there any relevant documents detailing the change in signing?
Relevant configuration files
/etc/bind/named.conf.options
options {
dnssec-validation no;
recursion no;
allow-query { any; };
listen-on port 53 { any; };
listen-on-v6 port 53 { any; };
};
/etc/bind/db.testdomain.com
$ORIGIN testdomain.com.
$TTL 60
@ IN SOA ns.tester.com. dns.tester.com. 123 300 60 600 60
@ IN A 1.2.3.4
/etc/bind/named.conf.local
zone "testdomain.com." IN {
type master;
file "/etc/bind/db.testdomain.com.";
allow-transfer {
key "my-key";
};
};
/etc/bind/named.conf.tsigkeys
key "my-key" {
algorithm hmac-sha256;
secret "NFpecql0ttMve8aDTgQk0UcCnV0vxpBx7fQ8elRTTeU=";
};
Relevant logs and/or screenshots
Jun 7 22:26:41 debian named[2456]: client @0x7f5b2c00c940 104.132.34.81#50825/key my-key (testdomain.com): transfer of 'testdomain.com/IN': AXFR started: TSIG my-key (serial 123)
Jun 7 22:26:41 debian named[2456]: client @0x7f5b2c00c940 104.132.34.81#50825/key my-key (testdomain.com): transfer of 'testdomain.com/IN': AXFR ended: 1 messages, 5 records, 319 bytes, 0.001 secs (319000 bytes/sec) (serial 123)
Jun 7 22:26:44 debian named[2456]: client @0x7f5b28a280f0 104.132.34.81#36954/key my-key (testdomain.com): transfer of 'testdomain.com/IN': AXFR started: TSIG my-key (serial 123)
Jun 7 22:26:44 debian named[2456]: client @0x7f5b28a280f0 104.132.34.81#36954/key my-key (testdomain.com): transfer of 'testdomain.com/IN': AXFR ended: 1 messages, 5 records, 319 bytes, 0.001 secs (319000 bytes/sec) (serial 123)