☰

Vincular alteração de DDNS recebendo `falha na atualização: NOTAUTH`, como corrigir esse problema de autorização?

tag-icon • tag-icon domain-name-system bind ddns
Vincular alteração de DDNS recebendo `falha na atualização: NOTAUTH`, como corrigir esse problema de autorização?

Eu tenho a seguinte definição 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;
};

Conforme mostrado, espera-se que eu possa adicionar e remover subdomínios (também conhecidos como foo.example.com) usando nsupdate. Tentei o seguinte, mas estou recebendo um NOTAUTHerro:

$ 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, o sendcomando falha com um arquivo NOTAUTH.

Eu sei que a local-ddnschave foi carregada com sucesso, pois quando tento, sudorecebo o seguinte erro:

$ 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

Olhando para o arquivo, parece uma chave válida. Exatamente como esperado.

Além disso, as letsencryptalterações em um campo TXT funcionam conforme o esperado. Então, o que há de errado em:

grant local-ddns zonesub any

Observação:

Conforme mostrado na definição da zona, o arquivo .zone está em /var/lib/bind. E o diretório pertence a root:bindcom permissões -rwxrwxr-x. O próprio arquivo tem permissões -rw-------. Então named(que roda como bind) tem acesso aos arquivos.

Responder1

Encontrei uma solução para o meu problema.

Eu reiniciei named.

Não tenho muita certeza do que está acontecendo. Parece que está em execução:

$ 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

Mas não consigo acessar nada. Levei um pouco de tempo para perceber que o sistema estava realmentemorto.

Quando eu testo usando dig @ns1.example.com www.example.comele falha quando está nesse estado. No entanto, a porta UDP está aberta e, como mostrado acima, o status diz OK (o marcador está verde no meu console).

Espero que isso ajude alguém porque é um estado estranho.

informação relacionada