☰

Bind-DDNS-Änderung empfängt „Update fehlgeschlagen: NOTAUTH“. Wie behebt man dieses Autorisierungsproblem?

tag-icon • tag-icon domain-name-system bind ddns
Bind-DDNS-Änderung empfängt „Update fehlgeschlagen: NOTAUTH“. Wie behebt man dieses Autorisierungsproblem?

Ich habe folgende Zonendefinition:

zone "madetoorder.software" {
  type master;
  file "/var/lib/bind/example.com.zone";
  allow-transfer { trusted-servers; };
  check-names warn;
  update-policy {
    grant local-ddns zonesub any;
    grant letsencrypt_wildcard. name _acme-challenge.example.com. txt;
  };
  max-journal-size 2M;
};

Wie gezeigt, sollte es mir möglich sein, Subdomains (auch bekannt als foo.example.com) mit hinzuzufügen und zu entfernen nsupdate. Ich habe Folgendes versucht, aber ich erhalte eine NOTAUTHFehlermeldung:

$ sudo nsupdate
> local 165.232.146.181
> zone madetoorder.software
> update delete ve-vlc.madetoorder.software.
> send
NOTAUTH
> update add ve-vlc.madetoorder.software. 60 A 165.232.146.181
> send
NOTAUTH
> quit

Wie wir sehen können, sendschlägt der Befehl mit einem fehl NOTAUTH.

Ich weiß, dass der local-ddnsSchlüssel erfolgreich geladen wurde, da ich beim Versuch ohne den Schlüssel sudodie folgende Fehlermeldung erhalte:

$ nsupdate -l
19-Apr-2022 21:50:16.831 open: //run/named/session.key: permission denied
can't read key from //run/named/session.key: permission denied

Wenn man sich die Datei ansieht, sieht es tatsächlich wie ein gültiger Schlüssel aus. Genau wie erwartet.

Auch die letsencryptÄnderungen an einem TXT-Feld funktionieren wie erwartet. Was ist also falsch an:

grant local-ddns zonesub any

Notiz:

Wie in der Zonendefinition gezeigt, befindet sich die .zone-Datei unter /var/lib/bind. Und das Verzeichnis gehört root:bindmit Berechtigungen -rwxrwxr-x. Die Datei selbst hat Berechtigungen -rw-------. Daher hat named(das als ausgeführt wird bind) Zugriff auf die Dateien.

Antwort1

Ich habe eine Lösung für mein Problem gefunden.

Ich habe neu gestartet named.

Ich bin nicht ganz sicher, was passiert. Es sieht so aus, als ob es läuft:

$ systemctl status named
● named.service - BIND Domain Name Server
     Loaded: loaded (/lib/systemd/system/named.service; enabled; vendor preset: enabled)
     Active: active (running) since Wed 2022-04-20 14:25:48 UTC; 9h ago
       Docs: man:named(8)
   Main PID: 2334296 (named)
      Tasks: 14 (limit: 9508)
     Memory: 44.3M
     CGroup: /system.slice/named.service
             └─2334296 /usr/sbin/named -f -u bind

Aber ich kann auf nichts zugreifen. Es dauerte eine Weile, bis ich merkte, dass das System tatsächlichtot.

Wenn ich es teste, dig @ns1.example.com www.example.comschlägt es in diesem Zustand fehl. Der UDP-Port ist jedoch geöffnet und wie oben gezeigt lautet der Status OKAY (der Aufzählungspunkt ist in meiner Konsole grün).

Ich hoffe, dass dies jemand anderem hilft, denn es ist ein seltsamer Zustand.

verwandte Informationen