Score:0

Bind DDNS change receiving `update failed: NOTAUTH`, how to fix that authorization issue?

cn flag

I have the following zone definition:

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

As shown, it is expected to allow me to add and remove sub-domains (a.k.a. foo.example.com) using nsupdate. I tried the following but I'm getting a NOTAUTH error:

$ 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

As we can see, the send command fails with a NOTAUTH.

I know the local-ddns key is loaded successfully since when I try without sudo I get the following 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

Looking at the file, it does look like a valid key. Just as expected.

Also, the letsencrypt changes to a TXT field work as expected. So what is wrong in:

grant local-ddns zonesub any

Note:

As shown in the zone definition, the .zone file is under /var/lib/bind. And the directory is owned by root:bind with permissions -rwxrwxr-x. The file itself has permissions -rw-------. So named (which runs as bind) has access to the files.

Patrick Mevzek avatar
cn flag
"So named (which runs as bind) has access to the files." It is the user under which you run `nsupdate` that can't read the file due to permissions. Plus it is a bit strange to put the key in`/run` as this is an ephemeral directory that will disapperar on reboot.
cn flag
@PatrickMevzek The `local-ddns` key is special in that it gets generated by named on startup. At least, that's how it works under Ubuntu. It works while running. If you restart named, it gets regenerated again. So it's not necessary to keep that key across boots and can therefore reside under `/run`.
Score:0
cn flag

I found a solution to my issue.

I restarted named.

I'm not too sure what is happening. It looks like it is running:

$ 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

But I can't access anything. It took me a little time to notice that the system was actually dead.

When I test using dig @ns1.example.com www.example.com it fails when it's in that state. Yet the UDP port is open and as shown above, the status says OKAY (the bullet point is green in my console).

I hope this helps someone else because it is a strange state.

mangohost

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.