[Kea-users] Failed to secure DDNS updates with TSIG between Kea and Bind

[Daniel Herrmann]

Hi Francis,

Thanks so much. The hint to check on the wire was helpful. As a network engineer I could have figured this out myself… sometimes it needs an extra pointer... :)

Anyway, turns out Kea is picking the key correctly, but Bind was not finding the key and thus was unable to verify. After some digging I found the problem: I’m using Ansible (specifically: this role https://github.com/bertvv/ansible-role-bind) to deploy bind and set the key like this:

 bind_dns_keys:
  - name: "{{ bind_kea_tsig_keyname }}"
    algorithm: "{{ bind_kea_tsig_algorithm }}"
    secret: "{{ bind_kea_tsig_secret }}”

Which wrote the key to /etc/named/auth_transfer.conf as defined by the Ansible module. I saw the key there and thought all was good. I missed though that I have to tell the Ansible Module to add an import statement to named.conf, I was somehow assuming its doing this automatically.

Adding the following host vars for the DNS server add the correct import statement.

bind_extra_include_files:
   - "{{ bind_auth_file }}”

That said, its a typical “don’t assume, RTFM! case”, as its actually documented in the Ansible module Readme. Thanks for your support!

Regards
Daniel


> On 20. Jun 2021, at 18:18, Francis Dupont <fdupont at isc.org> wrote:
> 
> BADKEY in general is related to a configuration error. I recommend to
> look at messages on the wire to understand if the error is on the
> bind/server side or Kea side.
> 
> In the case the error is on the Kea side the BADKEY error when verifying
> a signed response is a key name mismatch i.e. the configured key name is
> not the same as the TSIG RR name (another point easy to check with the
> message dump).
> 
> Note that key names are DNS names so you can use a FQDN e.g. a name in
> the server domain name (common practice) and of course they are case
> insensitive.
> 
> If the problem is on the bind 9 side perhaps it was reported in its logs?
> 
> Thanks
> 
> Francis Dupont <fdupont at isc.org>
> 
> PS: a secret mismatch gives BADSIG so IMHO this is around the key itself
> (name, algorithm, ...).
> PPS: looking the bind9 code for BADKEY you have:
> - key name mismatch
> - algorithm name mismatch (both logger as
>   "key name and algorithm do not match")
> - unknown key (logged as "unknown key")
> logs are at category dnssec module tsig level 2.