BIND 9's nsupdate dyndns update gives: "tsig verify failure (BADKEY)"

Question

I've scoured through so many HOWTO pages on DDNS to try and fix this... I'm at a loss.

WorkstationX = CentOS 6.2 x64 ServerX = Ubuntu 12.04 LTS x64

I don't understand why it's not working... I'm literally out of ideas. I have regenerated and reconfigured everything several times.

I've made sure:

Running NTPD on both hosts, I have verified NTP is working
TZ is correct for both nodes (Hardware is UTC)
I've followed these guides:

Some of them have varying ways of generating the key, but the rest is the same... and still, when I try nsupdate - even on the server where dnssec-keygen was run (and where bind is), I get the same log entries:

Aug 14 11:20:38 vps named[31247]: 14-Aug-2013 11:20:38.032 security: error: client 127.0.0.1#29403: view public: request has invalid signature: TSIG domain2.com.au.: tsig verify failure (BADKEY)

from this nsupdate:

nsupdate -k Kdomain2.com.au.+157+35454.key
server localhost
zone domain2.com.au.
update add test.domain2.com.au. 86400 IN A 10.20.30.40
show
send

What I gather is the CORRECT generated method:

dnssec-keygen -a HMAC-MD5 -b 512 -n HOST domain2.com.au.

named.conf (IPs have been changed for privacy):

acl ipv4                { 0.0.0.0/0; };
acl ipv6                { 2000::/3; ::1; fe80::/10; fec0::/10; };
acl safehosts           { 127.0.0.0/8; 3.2.2.40; 44.44.14.12; };

include "/etc/bind/rndc.key";

controls {
        inet * port 953
        allow { safehosts; } keys { "rndc-key"; };
};

options
{
        auth-nxdomain           yes;
        empty-zones-enable      no;
        zone-statistics         yes;
        dnssec-enable           yes;
        listen-on               { any; };
        listen-on-v6            { any; };
        directory               "/etc/bind/db";
        managed-keys-directory  "/etc/bind/keys";
        memstatistics-file      "/etc/bind/data/bind.memstats";
        statistics-file         "/etc/bind/data/bind.qstats";
};

logging
{
## CUT ##
};

view "public"
{
    recursion           yes;
    allow-query-cache   { safehosts; };
    allow-recursion     { safehosts; };

zone "." IN {
    type            hint;
    file            "root.zone";
};

zone "0.0.127.in-addr.arpa" {
    type            master;
    allow-update    { none; };
    allow-transfer  { none; };
    file            "0.0.127.in-addr.arpa.zone";
};

zone "localhost" {
    type            master;
    allow-update    { none; };
    allow-transfer  { none; };
    file            "localhost.zone";
};

zone "3.2.2.in-addr.arpa" {
    type            master;
    allow-update    { none; };
    allow-transfer  { none; };
    file            "3.2.2.in-addr.arpa.zone";
};

zone "domain1.com.au" {
    type            master;
    notify          yes;
    allow-update    { key "rndc-key"; };
    allow-transfer  { key "rndc-key"; };
    file            "domain1.com.au.zone";
};

zone "domain2.com.au" {
    type            master;
    notify          yes;
    allow-update    { key "rndc-key"; };
    allow-transfer  { key "rndc-key"; };
    file            "doomain2.com.au.zone";
};
};

/etc/bind/rndc.key:

key "rndc-key" {
    algorithm hmac-md5;
    secret "vZwCYBx4OAOsBrbdlooUfBaQx+kwEi2eLDXdr+JMs4ykrwXKQTtDSg/jp7eHnw39IehVLMtuVECTqfOwhXBm0A==";
};

Kdomain1.com.au.+157+35454.private

Private-key-format: v1.3
Algorithm: 157 (HMAC_MD5)
Key: vZwCYBx4OAOsBrbdlooUfBaQx+kwEi2eLDXdr+JMs4ykrwXKQTtDSg/jp7eHnw39IehVLMtuVECTqfOwhXBm0A==
Bits: AAA=
Created: 20130814144733
Publish: 20130814144733
Activate: 20130814144733

Looks right at a glance; keys are symmetric. If you run `cat -e` on your .private file, do all of the lines end in `$` (LF), or is there a CR mixed in there as well? This could possibly confuse things. — Andrew B, Aug 15 '13 at 03:23
What looks interesting is that key activation time is later than error message in logs you provided. It might be timezone confusing me, but can you check the time on all of your servers? — DukeLion, Aug 15 '13 at 04:51

score 3 · Accepted Answer · answered Aug 15 '13 at 08:33

3

nsupdate has some quirks and assumes some naming convention when called with -k. From the man page, I think your key name might somehow be called domain2.com.au.

Could you try the following?

nsupdate -y \
  'rndc-key:vZwCYBx4OAOsBrbdlooUfBaQx+kwEi2eLDXdr+JMs4ykrwXKQTtDSg/jp7eHnw39IehVLMtuVECTqfOwhXBm0A=='

answered Aug 15 '13 at 08:33

Wil Tan

396
2
3

no worries, you're most welcome :) – Wil Tan Aug 15 '13 at 11:42

score 3 · Answer 2 · answered Jun 27 '19 at 18:20

3

You have to use the key name you created the key with as the name in the config. From what I can see, you have to use:

key "domain2.com.au" {
   [...]
}

From the BIND documentation:

to verify that incoming requests have been signed with a key matching this name, algorithm, and secret.

answered Jun 27 '19 at 18:20

neingeist

191
1
5

Yup. The *name* of the key is part of the package. Cannot rename at any point. – Jari Turkia Oct 18 '19 at 07:00

score 0 · Answer 3 · answered Aug 15 '13 at 04:22

0

You have allow-update { key "rndc-key"; }; and not the key you've generated. You should have a key statement somewhere: key "ddns_key" { algorithm hmac-md5; secret "vZwCYBx4OAOsBrbdlooUfBaQx+kwEi2eLDXdr+JMs4ykrwXKQTtDSg/jp7eHnw39IehVLMtuVECTqfOwhXBm0A=="; };.You should then add the allow-update { key "ddns_key" };

answered Aug 15 '13 at 04:22

Richard Salts

755
3
17

he did have `include "/etc/bind/rndc.key";` in his `named.conf` – Wil Tan Aug 15 '13 at 08:26
Hi Richard, I've tried that (separate rndc key and generated a specific ddns key for the allow-update clause) - same result. – Litch Aug 15 '13 at 09:56

BIND 9's nsupdate dyndns update gives: "tsig verify failure (BADKEY)"

3 Answers3

Linked