dnssec SERIAL handling

The SERIAL handling is DNSSEC signed zones is little bit awkward at the moment.

We need to be able to select the SERIAL handling (default and per zone) from:

a) increment b) unixtime c) no touching

possibly with some form of autodetection, so this won't happen:

2013-11-18T16:02:14 [warning] Zone file for 'sury.cz.' changed, but serial didn't - won't create changesets.

The default should be 'auto' that would default to unixtime unless the current SERIAL is bigger and in form of YYYYMMDDXX in which case it should fall back to increment.

Also in case the user forgets to bump the SERIAL (in not-yet-flushed zone), but the zone needs resigning we should increment starting with the current SERIAL in the journal and not the value in the zone file. That is if the SERIAL hasn't changed from last time.

Results of our internal discussion:

• Serial number in zone file should be ignored when reading the zone file.
• Serial number should be always managed by Knot on master.
• We will use timestamps (instead of/in addition to) serial numbers in journal.
• When zone reload is requested, timestamps in journal and zone mtime will be used to determine order of operations.
• If there are unflushed DDNS changes in journal older than zone mtime, reload will be refused. Administrator should flush the journal before doing manual changes in the zone file. Otherwise, zone can be safely reloaded. (Bind style without freeze/thaw.)
• If the zone is stopped, there are unflushed changes in the journal, and zone file is modified, journal will be backed up and recreated. We cannot apply changes on top of unknown zone content.

Small correction:

Knot should always flush each change to zone file by default (zonefile-sync: 0s). Thus the administrator may edit the zone file in any moment. Most of the time there will be no problem after reload. The only collision may occur if the server receives an UPDATE while the admin is editing the zone file. In this case, as the changes in the server will be immediately flushed, the zone file changes on the disk and the text editor notifies the admin when he tries to save the edited zone file.

Right. Anyway, this is still valid for large zones where zonefile-sync is intentionally set to high value by administrator:

• If there are unflushed DDNS changes in journal older than zone mtime, reload will be refused. Administrator should flush the journal before doing manual changes in the zone file. Otherwise, zone can be safely reloaded. (Bind style without freeze/thaw.)

Right, sorry. You could have just un-scratched it in your previous comment ;-)

the text editor notifies the admin when he tries to save the edited zone file

Urg. I think it may be a mistake to tie the sanity of the resulting zone to a requirement that the administrator uses a sane text editor.

In general I doubt that it is possible to design this in a way that always allows manual edit without "BIND style freeze/thaw". With a steady stream of updates the attempts to reload the result of the manual edit will be starved. But I have not thought a lot about it.

I haven't seen anything other than the written thread re: #158 (closed), so I may well be missing stuff. I understand that this is primarily for the case where Knot manages signing. But I still get heebie-jeebies when I read:

Serial number in zone file should be ignored when reading the zone file. Serial number should be always managed by Knot on master.

and I think that we don't look at this in quite the same way. The way I look at this is:

1. If Knot is not responsible for signing the zone, then hands off, don't touch anything. Probably not a controversial position.
2. If Knot is responsible for signing, then there are two zones: the inbound zone and the outbound zone. Inbound zone: don't touch (see above). Outbound zone: modify as needed according to given policy for serial management.

I admit that I have not yet had time to play with the signing support in Knot (sorry, all of November lost to travel), but I will argue that the destination you want to arrive at is the bump-on-the-wire design, regardless of whether the inbound zone arrives via a zone load from file or via a zone transfer from wherever the unsigned zone is generated. Hence you want to look at this as two separate zone files, with two separate serials.

Thanks for your suggestions Johan, always appreciated.

• As for 1. - the problem has little to do with automatic DNSSEC, the combination of two inputs (DDNS + reload) into zone is what's causing the trouble. Automatic DNSSEC is just one more thing updating the zone, but the user should not have any desire to modify created RRs - they could even stay binary and never be flushed into the actual zone file (I'm not saying we'll implement it like this).
• 2.) We could keep track of the serial number in the zone file, but the behavior with enabled DDNS would be just as confusing - the user increments the serial, but Knot serves the zone using some other (higher) serial.

You're probably right about need for freeze/thaw, but we'd like to avoid doing what BIND does if at all possible. Alternatively, we could allow both reload and DDNS until there's no collision (so virtually, we'd have two mutually exclusive zones). In case of modification of the same RR using both reload and DDNS, we'd tell the use to freeze and sync the zone and the rest would be identical to BIND. But I highly doubt that this solution reflects anyone's current workflow.

Final result of discussion - solution to 1.4.0

1. Set default zonefile sync interval to 0s + add warning about this to manual and to sample config file. Consider also creating separate sample config files for small and large zones. Serial policy remains as it is (increment).
2. : Allow user to configure serial policy in the config file. Options: increment (same as now), unixtime (always set to current time).
3. (possibly to 1.4.0) Add support for BIND-style freeze/thaw per zone. (Freeze disables incoming DDNS and postpones resign, thaw enables DDNS and resign.)

'keep' serial policy and other fancy stuff (automatic detection of proper policy based on serial format) postponed after 1.4.0

mentioned in merge request !132 (merged)

Status changed to closed

mentioned in issue #162 (closed)

mentioned in issue #164 (closed)

mentioned in issue #120 (closed)