[knot-dns-users] question about unixtime

i have had a fun day chasing diags of the form ``` 2024-06-22T18:32:57.305472+00:00 ns knotd[24354]: info: [foo.com.] control, received command 'zone-reload' 2024-06-22T18:32:57.307532+00:00 ns knotd[24354]: info: [foo.com.] zone file parsed, serial 1719081134 2024-06-22T18:32:57.307669+00:00 ns knotd[24354]: warning: [foo.com.] zone file changed with decreased SOA serial 2024-06-22T18:32:57.307828+00:00 ns knotd[24354]: error: [foo.com.] zone event 'load' failed (value is out of range) ``` i have the following hypothesis: - `serial-policy: unixtime` is configured in `/etc/knot/knot.conf`. - emacs dns-mode sets the SOA serial to the current unixtime when one saves the zone file - a few seconds later, i do `knotc zone sign` and `knotc zone-reload` - knot then says "you have manually specified a new serial, but it is less than the current unixtime; i.e. you are trying to go backward. bad geek!" - i.e. knot did not like me mucking with the SOA serial in the zone file when `serial-policy: unixtime` was configured. i tested this hypothesis by putting the serial from the server's current SOA in the zone file and doing sign & reload. it succeeded, and the new zone in all servers is the unixtime of the signing, not of the zone file. my current conclusion is: do not have both emacs dns-mode with `serial-policy: unixtime`; use only one or t'other. especially if doing RFC 1982 serial stepping, remember to first turn off `serial-policy: unixtime` and `knotc reload`. does this make sense? randy