4 Pro
2025
4 Pro
'25
12:13
Hi, I'm having issues with ACL's and DNS updates and multiple DNS servers.
I use DNS-01 for TLS letsencrypt and AXFR between the servers, but for some reason acme.sh
is not working for a new server with "NOTAUTH" failures.
(I give acme.sh export KNOT_SERVER='souseiseki.middlendian.com' so that it uses
the master and that works fine on the master and another server, but for some reason on
the new one there is an ACL
related failure?);
[Thu 04 Dec 2025 21:53:49 AEDT] Adding _acme-challenge.middlendian.com. 60 TXT
"<snip>"
;; ->>HEADER<<- opcode: UPDATE; status: NOTAUTH; id: 42945
;; Flags: qr; ZONE: 1; PREREQ: 0; UPDATE: 0; ADDITIONAL: 1
;; ZONE SECTION:
;; middlendian.com. IN SOA
;; ADDITIONAL DATA:
;; TSIG PSEUDOSECTION:
acme_key. 0 ANY TSIG hmac-sha512. 1764845629 300 64
<snip> 42945 NOERROR 0
;; ERROR: update failed with error 'NOTAUTH'
knsupdate works with the set key to the master;
knsupdate
knsupdate> server souseiseki.middlendian.com
knsupdate> key hmac-sha512:acme_key:<snip>
knsupdate> zone middlendian.com.
knsupdate> add test.middlendian.com. 300 TXT test
knsupdate> send
knsupdate> answer
But, the ACL seems to have problems, as DNS updates fail if attempted via any secondary
server?;
knsupdate
knsupdate> server hinaichigo.middlendian.com
knsupdate> key hmac-sha512:acme_key:<snip>
knsupdate> zone middlendian.com.
knsupdate> del test.middlendian.com TXT
knsupdate> send
;; ->>HEADER<<- opcode: UPDATE; status: NOTAUTH; id: 14970
;; Flags: qr; ZONE: 1; PREREQ: 0; UPDATE: 0; ADDITIONAL: 1
;; ZONE SECTION:
;; middlendian.com. IN SOA
;; ADDITIONAL DATA:
;; TSIG PSEUDOSECTION:
acme_key. 0 ANY TSIG hmac-sha512. 1764844872 300 64
<snip> 14970 NOERROR 0
;; ERROR: update failed with error 'NOTAUTH'
Knot on souseiseki outputs an error to syslog; "ACL, denied, action update, remote
125.63.60.124@38966 TCP"
but that isn't helpful debug output, as it does not say why the ACL was denied.
IP address related matching could be a problem, but reviewing the documentation, it seems
to state that IP addresses are not considered in ACL's unless listed in the ACL?
Does anyone know what the issue is and otherwise how do I debug it?
All the servers have the same ACL key set;
/etc/knot/acme.key;
key:
- id: acme_key
algorithm: hmac-sha512
secret: <snip>
souseiseki (master);
remote:
- id: suigintou
address: [ 180.150.27.133@53, 2403:5806:e8d0::dead:beef:cafe@53 ]
- id: hinaichigo
address: 125.63.60.124@53
include: "/etc/knot/acme.key"
acl:
- id: acme_acl
key: acme_key
action: update
zone:
- domain: middlendian.com
dnssec-signing: on
acl: acme_acl
notify: [ suigintou, hinaichigo ]
hinaichigo (secondary);
remote:
- id: master
address: 144.6.197.157@53
acl:
- id: acme_acl
key: acme_key
action: [update, notify]
zone:
- domain: middlendian.com
master: master
acl: acme_acl
--
Kind Regards, DiffieHellman
4 Pro
4 Pro
12:45
Hello!
On 12/4/25 12:13, DiffieHellman via knot-dns-users wrote:
Hi, I'm having issues with ACL's and DNS
updates and multiple DNS servers.
I use DNS-01 for TLS letsencrypt and AXFR between the servers, but for some reason
acme.sh is not working for a new server with "NOTAUTH" failures.
(I give acme.sh export KNOT_SERVER='souseiseki.middlendian.com' so that it uses
the master and that works fine on the master and another server, but for some reason on
the new one there is an ACL
related failure?);
[Thu 04 Dec 2025 21:53:49 AEDT] Adding _acme-challenge.middlendian.com. 60 TXT
"<snip>"
;; ->>HEADER<<- opcode: UPDATE; status: NOTAUTH; id: 42945
;; Flags: qr; ZONE: 1; PREREQ: 0; UPDATE: 0; ADDITIONAL: 1
;; ZONE SECTION:
;; middlendian.com. IN SOA
;; ADDITIONAL DATA:
;; TSIG PSEUDOSECTION:
acme_key. 0 ANY TSIG hmac-sha512. 1764845629 300 64
<snip> 42945 NOERROR 0
;; ERROR: update failed with error 'NOTAUTH'
knsupdate works with the set key to the master;
knsupdate
knsupdate> server souseiseki.middlendian.com
knsupdate> key hmac-sha512:acme_key:<snip>
knsupdate> zone middlendian.com.
knsupdate> add test.middlendian.com. 300 TXT test
knsupdate> send
knsupdate> answer
But, the ACL seems to have problems, as DNS updates fail if attempted via any secondary
server?;
knsupdate
knsupdate> server hinaichigo.middlendian.com
knsupdate> key hmac-sha512:acme_key:<snip>
knsupdate> zone middlendian.com.
knsupdate> del test.middlendian.com TXT
knsupdate> send
;; ->>HEADER<<- opcode: UPDATE; status: NOTAUTH; id: 14970
;; Flags: qr; ZONE: 1; PREREQ: 0; UPDATE: 0; ADDITIONAL: 1
;; ZONE SECTION:
;; middlendian.com. IN SOA
;; ADDITIONAL DATA:
;; TSIG PSEUDOSECTION:
acme_key. 0 ANY TSIG hmac-sha512. 1764844872 300 64
<snip> 14970 NOERROR 0
;; ERROR: update failed with error 'NOTAUTH'
Knot on souseiseki outputs an error to syslog; "ACL, denied, action update, remote
125.63.60.124@38966 TCP"
but that isn't helpful debug output, as it does not say why the ACL was denied.
It seems that a TSIG is missing. It would be mentioned there otherwise. Compare with the
master that works.
IP address related matching could be a problem, but reviewing the documentation, it seems
to state that IP addresses are not considered in ACL's unless listed in the ACL?
Correct, IP addresses are optional.
Does anyone know what the issue is and otherwise how do I debug it?
All the servers have the same ACL key set;
/etc/knot/acme.key;
key:
- id: acme_key
algorithm: hmac-sha512
secret: <snip>
souseiseki (master);
remote:
- id: suigintou
address: [ 180.150.27.133@53, 2403:5806:e8d0::dead:beef:cafe@53 ]
- id: hinaichigo
address: 125.63.60.124@53
include: "/etc/knot/acme.key"
acl:
- id: acme_acl
key: acme_key
action: update
zone:
- domain: middlendian.com
dnssec-signing: on
acl: acme_acl
notify: [ suigintou, hinaichigo ]
hinaichigo (secondary);
remote:
- id: master
address: 144.6.197.157@53
acl:
- id: acme_acl
key: acme_key
action: [update, notify]
zone:
- domain: middlendian.com
master: master
acl: acme_acl
What is you Knot version?
Daniel
13:41
Hi Daniel,
3.4.7 on both souseiseki & hinaichigo.
I can upgrade to 3.5.1.
--
Kind Regards, DiffieHellman
15:06
Hi Daniel,
I'm not sure what I'm looking for - the logs do not report anything to do with key
specification and both use the exact same key declaration.
Trying again and looking at the logs;
hinaichigo:
knot[21982]: debug: [middlendian.com.] ACL, allowed, action update, remote
2403:5806:e8d0:1:3f07:e29c:c1c8:8c09@59341 UDP, key acme_key.
knot[21982]: info: [middlendian.com.] DDNS, forwarding 1 updates
knot[21982]: info: [middlendian.com.] DDNS, updates forwarded to the master
souseiseki:
knot[26464]: debug: [middlendian.com.] ACL, denied, action update, remote
125.63.60.124@48970 TCP
--
Kind Regards, DiffieHellman
15:14
Hi,
On 12/4/25 15:06, DiffieHellman wrote:
Hi Daniel,
I'm not sure what I'm looking for - the logs do not report anything to do with
key specification and both use the exact same key declaration.
Trying again and looking at the logs;
hinaichigo:
knot[21982]: debug: [middlendian.com.] ACL, allowed, action update, remote
2403:5806:e8d0:1:3f07:e29c:c1c8:8c09@59341 UDP, key acme_key.
knot[21982]: info: [middlendian.com.] DDNS, forwarding 1 updates
knot[21982]: info: [middlendian.com.] DDNS, updates forwarded to the master
souseiseki:
knot[26464]: debug: [middlendian.com.] ACL, denied, action update, remote
125.63.60.124@48970 TCP
This part `key acme_key` is what I'm looking for. So yes, the update doesn't
contain TSIG in the case of souseiseki.
15:51
Hi Daniel,
The issue was that acme.sh was ignoring my KNOT_SERVER choice and was using the option
saved into account.conf instead.
Now I've adjusted it to use souseiseki, it works (as direct update works).
So yes, the update doesn't contain TSIG in the case
of souseiseki.
Is it possible for the update to contain TSIG when forwarding an
update?
--
Kind Regards, DiffieHellman
21:21
Hi,
On 12/4/25 15:51, DiffieHellman wrote:
Hi Daniel,
The issue was that acme.sh was ignoring my KNOT_SERVER choice and was using the option
saved into account.conf instead.
Now I've adjusted it to use souseiseki, it works (as direct update works).
It depends on your configuration. Knot should be compliant with
https://www.rfc-editor.org/rfc/rfc8945.html#name-special-considerations-for-
So yes, the update doesn't contain TSIG in
the case of souseiseki.
Is it possible for the update to contain TSIG when
forwarding an update?
2
days inactive
2
days old
7 comments
2 participants
participants (2)
-
Daniel Salzman -
DiffieHellman