☰

Vincular el cambio de DDNS al recibir "actualización fallida: NOTAUTH", ¿cómo solucionar ese problema de autorización?

tag-icon • tag-icon domain-name-system bind ddns
Vincular el cambio de DDNS al recibir "actualización fallida: NOTAUTH", ¿cómo solucionar ese problema de autorización?

Tengo la siguiente definición de zona:

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;
};

Como se muestra, se espera que me permita agregar y eliminar subdominios (también conocidos como foo.example.com) usando nsupdate. Intenté lo siguiente pero aparece un NOTAUTHerror:

$ 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

Como podemos ver, el sendcomando falla con un archivo NOTAUTH.

Sé que la local-ddnsclave se cargó correctamente ya que cuando lo intento sin sudoaparece el siguiente error:

$ 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

Al mirar el archivo, parece una clave válida. Tal como se esperaba.

Además, los letsencryptcambios en un campo TXT funcionan como se esperaba. Entonces, ¿qué hay de malo en:

grant local-ddns zonesub any

Nota:

Como se muestra en la definición de zona, el archivo .zone está bajo /var/lib/bind. Y el directorio es propiedad root:bindde permisos -rwxrwxr-x. El archivo en sí tiene permisos -rw-------. Entonces named(que se ejecuta como bind) tiene acceso a los archivos.

Respuesta1

Encontré una solución a mi problema.

Reinicié named.

No estoy muy seguro de lo que está pasando. Parece que se está ejecutando:

$ 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

Pero no puedo acceder a nada. Me tomó un poco de tiempo darme cuenta de que el sistema estaba realmentemuerto.

Cuando lo pruebo, dig @ns1.example.com www.example.comfalla cuando está en ese estado. Sin embargo, el puerto UDP está abierto y, como se muestra arriba, el estado dice OK (la viñeta es verde en mi consola).

Espero que esto ayude a alguien más porque es un estado extraño.

información relacionada