22 Bře
2021
22 Bře
'21
16:40
Hi André,
thank you for your report and the detailed information you provided.
I was able to reproduce your issue and it occurs to be a bug. We will
fix it for the next 3.0.x version.
You might use any of two possible workarounds:
1) after changing the configuration file by setting journal-content:
all, you can stop and cold-start knotd instead of reloading the
configuration.
2) before changing the configuration, you can stop the single affected
zone by `knotc -f purge +expire example.net.` and proceed with `knotc
reload`.
Cheers,
Libor
Dne 19. 03. 21 v 23:05 André Keller napsal(a):
Hi Libor
On 19.03.21 19:20, libor.peltan wrote:
However, I found rather little information.
I understand, I thought there might be some standard procedure that one
needs to follow when changing the journal-content setting that I missed.
Could you please provide some more info about you
configuration (at
least zonefile-sync and zonefile-load) and longer log snippets
uncovering what was going on after the configuration change?
I'm afraid the log is not much more verbose, I can try to reproduce the
issue with a higher log level if that would help.
So after the config change:
Mar 19 14:35:24 master1 knotd[1018]: info: reloading configuration file
'/etc/knot/knot.conf'
Mar 19 14:35:24 master1 knotd[1018]: info: configuration reloaded
Mar 19 14:35:24 master1 knotd[1018]: info: [example.net.] DNSSEC,
signing zone
Mar 19 14:35:24 master1 knotd[1018]: info: [example.net.] DNSSEC, key,
tag 9671, algorithm ECDSAP256SHA256, KSK, public, ready, active+
Mar 19 14:35:24 master1 knotd[1018]: info: [example.net.] DNSSEC, key,
tag 1496, algorithm ECDSAP256SHA256, public, active
Mar 19 14:35:24 master1 knotd[1018]: info: [example.net.] DNSSEC,
signing started
Mar 19 14:35:24 master1 knotd[1018]: info: [example.net.] DNSSEC, zone
is up-to-date
Mar 19 14:35:24 master1 knotd[1018]: info: [example.net.] DNSSEC, next
signing at 2021-03-23T14:29:04+0100
Then when adding a record to the zonefile:
Mar 19 14:44:34 master1 knotd[1018]: info: [example.net.] control,
received command 'zone-reload'
Mar 19 14:44:34 master1 knotd[1018]: info: [example.net.] zone file
parsed, serial corrected 1616161474 -> 1616161474
Mar 19 14:44:34 master1 knotd[1018]: info: [example.net.] zone stored to
journal, serial 1616161474
Mar 19 14:44:34 master1 knotd[1018]: info: [example.net.] DNSSEC, key,
tag 9671, algorithm ECDSAP256SHA256, KSK, public, ready, active+
Mar 19 14:44:34 master1 knotd[1018]: info: [example.net.] DNSSEC, key,
tag 1496, algorithm ECDSAP256SHA256, public, active
Mar 19 14:44:34 master1 knotd[1018]: info: [example.net.] DNSSEC,
signing started
Mar 19 14:44:34 master1 knotd[1018]: info: [example.net.] DNSSEC,
successfully signed
Mar 19 14:44:34 master1 knotd[1018]: error: [example.net.] zone event
'load' failed (semantic check)
Removing the entry again:
Mar 19 14:48:44 master1 knotd[1018]: info: [example.net.] control,
received command 'zone-reload'
Mar 19 14:48:44 master1 knotd[1018]: info: [example.net.] zone file
parsed, serial corrected 1616161723 -> 1616161724
Mar 19 14:48:44 master1 knotd[1018]: info: [example.net.] DNSSEC, key,
tag 9671, algorithm ECDSAP256SHA256, KSK, public, ready, active+
Mar 19 14:48:44 master1 knotd[1018]: info: [example.net.] DNSSEC, key,
tag 1496, algorithm ECDSAP256SHA256, public, active
Mar 19 14:48:44 master1 knotd[1018]: info: [example.net.] DNSSEC,
signing started
Mar 19 14:48:44 master1 knotd[1018]: info: [example.net.] DNSSEC,
successfully signed
Mar 19 14:48:44 master1 knotd[1018]: info: [example.net.] loaded, serial
1615901344 -> 1616161724 -> 1615901344, 2107 bytes
Mar 19 14:48:44 master1 knotd[1018]: info: [example.net.] DNSSEC, next
signing at 2021-03-23T14:29:04+0100
But me initial statement, that subsequent changes work was wrong. The
zone that loaded, was the original zone. If I now make changes to the
zone it always fail to load, if I revert the zone-file to the original
state and reload, the changes go through. So currently with the new
journat-content: all setting, I cannot make changes to this zone.
(And the change is syntactically correct, zone-check and named-checkzone
do not have any issue with the new zonefile)
Configuration (knotd (Knot DNS), version 3.0.4):
server:
user: knot:knot
listen: ["0.0.0.0@53", "::@53"]
version:
policy:
- id: default_ecdsa
algorithm: ecdsap256sha256
template:
- id: default
file: /var/lib/knot/zones/%s.zone
storage: /var/lib/knot
- id: master_default
acl: ["transfer_to_slaves"]
file: /var/lib/knot/zones/%s.zone
notify: ["slave1", "slave2", "slave3"]
serial-policy: unixtime
storage: /var/lib/knot
zonefile-load: difference
- id: master_dnssec
acl: ["transfer_to_slaves"]
dnssec-policy: default_ecdsa
dnssec-signing: on
file: /var/lib/knot/zones/%s.zone
journal-content: all
notify: ["slave1", "slave2", "slave3"]
serial-policy: unixtime
storage: /var/lib/knot
zonefile-load: difference-no-serial
zonefile-sync: -1
zone:
- domain: example.net
template: master_dnssec
Zonefile is rather simple for this zone:
$ORIGIN example.net.
$TTL 3600
@ IN SOA (
ns1.example.com.
dnsadmin.example.com.
1616161723
3600
600
1209600
3600
)
;
; Nameserver
;
@ IN NS ns1.example.com.
@ IN NS ns2.example.com.
@ IN NS ns3.example.com.
@ IN A 192.0.2.100
@ IN AAAA 2001:db8::100
www IN A 192.0.2.100
www IN AAAA 2001:db8::1010
I omitted the acl/remote/key section as well as the definition of the
other zones, as I do not think this is relevant information for the
issue at hand. Please let me know if you need this information.
-> journal-content: allin the master_dnssec template is the only change
I did. There was no journal-content configuration before. There are
other zones using this template that show the same behavior, zones using
using the master_default template work normally.
Does this information suffice or would you need to know anything else?
Regards
André