Das nsupdate dyndns-Update von BIND 9 enthält: "tsig verify error (BADKEY)"

8

Ich habe so viele HOWTO-Seiten auf DDNS durchsucht, um dies zu beheben ... Ich bin ratlos.

WorkstationX = CentOS 6.2 x64 ServerX = Ubuntu 12.04 LTS x64

Ich verstehe nicht, warum es nicht funktioniert ... Ich habe buchstäblich keine Ideen mehr. Ich habe alles mehrmals neu generiert und konfiguriert.

Ich habe dafür gesorgt:

Wenn ich NTPD auf beiden Hosts ausführe, habe ich überprüft, ob NTP funktioniert
TZ ist für beide Knoten korrekt (Hardware ist UTC)
Ich habe diese Anleitungen befolgt:

Einige von ihnen haben unterschiedliche Möglichkeiten, den Schlüssel zu generieren, aber der Rest ist derselbe ... und dennoch, wenn ich nsupdate versuche - selbst auf dem Server, auf dem dnssec-keygen ausgeführt wurde (und auf dem bind ist), erhalte ich dasselbe Protokoll Einträge:

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)

von diesem 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

Was ich sammle, ist die von CORRECT generierte Methode:

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

named.conf (IPs wurden aus Datenschutzgründen geändert):

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

— Litch
quelle

Sieht auf einen Blick richtig aus; Tasten sind symmetrisch. Wenn Sie cat -emit Ihrer .private-Datei arbeiten, enden alle Zeilen mit $(LF), oder ist dort auch eine CR gemischt? Dies könnte möglicherweise die Dinge verwirren.

— Andrew B

1

Interessant ist, dass die Aktivierung des Schlüssels später als die Fehlermeldung in den von Ihnen angegebenen Protokollen erfolgt. Es mag mich verwirren, aber können Sie die Zeit auf all Ihren Servern überprüfen?

— DukeLion

nsupdate -dIn solchen Situationen ist es, Sie Freund

— Fluss

3

nsupdatehat einige Macken und nimmt eine Namenskonvention an, wenn mit aufgerufen wird -k. Auf der Manpage denke ich, dass Ihr Schlüsselname irgendwie genannt werden könnte domain2.com.au.

Könnten Sie Folgendes versuchen?

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

— Wil Tan
quelle

Keine Sorge, du bist herzlich willkommen :)

— Wil Tan

2

Sie müssen den Schlüsselnamen, mit dem Sie den Schlüssel erstellt haben, als Namen in der Konfiguration verwenden. Soweit ich sehen kann, müssen Sie Folgendes verwenden:

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

Aus der BIND-Dokumentation :

um zu überprüfen, ob eingehende Anforderungen mit einem Schlüssel signiert wurden, der diesem Namen , Algorithmus und Geheimnis entspricht .

— Neingeist
quelle

Jep. Der Name des Schlüssels ist Teil des Pakets. Kann zu keinem Zeitpunkt umbenannt werden.

— Jari Turkia

0

Sie haben allow-update {key "rndc-key"; }; und nicht der Schlüssel, den Sie generiert haben. Sie sollten irgendwo eine Schlüsselanweisung haben: key "ddns_key" { algorithm hmac-md5; secret "vZwCYBx4OAOsBrbdlooUfBaQx+kwEi2eLDXdr+JMs4ykrwXKQTtDSg/jp7eHnw39IehVLMtuVECTqfOwhXBm0A=="; };Sie sollten dann das Zulassungs-Update hinzufügen{ key "ddns_key" };

— Richard Salts
quelle

er hatte include "/etc/bind/rndc.key";in seinemnamed.conf

— Wil Tan

Hallo Richard, ich habe das versucht (separater rndc-Schlüssel und generierte einen spezifischen ddns-Schlüssel für die allow-update-Klausel) - dasselbe Ergebnis.

— Litch