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é

-- 
https://lists.nic.cz/mailman/listinfo/knot-dns-users

Reply via email to