DHCP-driven DDNS updates fail with Fortigate 7.6.6 and BIND 9.20
So, I've got BIND9 running on Debian Trixie (which absolutely does DDNS updates because I can do them using the same key from other places on the network using `nsupdate`) and I've been trying to get a Fortigate (a 101F running 7.6.6) that's handling DHCP for the local network to push DDNS updates over to the thing, and it appears to fail with a NotAuth- message every time. This suggests rather strongly that there's something utterly undocumented with the way Fortigate handles the keys.
Steps performed:
1. BIND9 server set up and tested (obvs) but the configuration snippet is effectively this:|
key "test.key" { algorithm hmac-sha256; secret "P4Q4yPOnJXv/pithZ9wK/blCAFTo81oOSg5PtVzsOP8="; }; zone "test.company.tld" { type master; file "/var/lib/bind/test.company.tld.zone"; allow-update { key "test.key"; }; };
2. Over in the console of the Fortigate:
config system dhcp server edit 5 # because that's the one for the interface set ddns-server-ip 1.2.3.4 # obvs a placeholder set ddns-update enable set ddns-update-override enable set ddns-zone "test.company.tld" set ddns-auth tsig set ddns-keyname "test.key" set ddns-key "P4Q4yPOnJXv/pithZ9wK/blCAFTo81oOSg5PtVzsOP8=" next end
Now, I can actually issue updates using that key with nsupdate, so I know the BIND server is configured correctly and that the key is correct. However, what I see when I look with tcpdump (because the updates the Fortigate should be sending never actually appear in the zone) is this...
user@ns3$ sudo tcpdump -i enp1s0 -l -v -n port 53 and host 1.2.3.4 tcpdump: listening on enp1s0, link-type EN10MB (Ethernet), snapshot length 262144 bytes 11:21:49.335409 IP (tos 0x0, ttl 63, id 41914, offset 0, flags [none], proto UDP (17), length 224) 172.16.128.121.6981 > 1.2.3.4.53: 715 update [2n] [1au] SOA? test.company.tld. (196) 11:21:49.335778 IP (tos 0x0, ttl 64, id 49364, offset 0, flags [none], proto UDP (17), length 128) 1.2.3.4.53 > 172.16.128.121.6981: 715 update NotAuth- 0/0/1 (100) ^C
Now, I've seen the documentation which appears to be slightly out of date referring to HMAC-MD5 (which is deprecated and obsolete), but elsewhere it says that the Fortigate can handle HMAC-SHA256 (and there doesn't appear to be an option to set that explcitly so it must be able to "figger it out" on it's own or this is the piece the docs are missing), so this should be working.
I'm assuming someone else must have this working with modern/updated equipment. What magical thing is all the documentation leaving out that is necessary to make this work?
