Keep non-DNSSEC RRs in a separate file

In order for this to work we need:

• automatic serial handling (i.e. ignore serials in the 'original' zone file)
• option to set the serial format (managed/unmanaged, date, unixtime)
• proper serial arithmetic from RFC 1982 #165 (closed)

mentioned in issue #159 (closed)

Related to #120 (closed) and #158 (closed).

mentioned in issue #120 (closed)

Reassigned to @lslovak

I would take this one step further also include any DDNS records (i.e., learned from RFC 2136) along with the DNSSEC records.

My use case here is to be able to use Knot in a deployment where the zone files are static and produced by other provisioning tools. Therefore, Knot cannot rewrite the zone files whenever it changes (e.g., due to DNSSEC signing, receipt of a DDNS update, and so on). If it did, the provisioning tool would just come along and overwrite the zone file again, nuking all the DNSSEC signatures and dynamic records. In short, Knot needs to consider the "master" zone files themselves as read-only (something I could even enforce this using file system permissions).

Knot 2.0 comes close to solving the use case with the use of zonefile-sync: -1 plus the journal. However, there's a problem - the journal is cumulative, and will keep on growing, seemingly forever, or at least until the journal is full. This does however strike me as somewhat unnecessary, as one update will often cancel out a previous one, so there should be no need to store all updates since the dawn of time - only the last/current one for any given record.

So I'd like to propose a new feature which could be described as a «delta zone file». The delta zone file would be rewritten by Knot whenever the zone changed, and would then contain the changes between the (read-only) master zone file, in particular things like DNSSEC signatures, actual SOA serial, any records added using DDNS, and possibly records present in the master zone file but which have been deleted using DDNS.

When Knot starts up and/or reloads the zone, it can simply apply the delta zone file on top of the master zone file, in order to create a complete zone file (in memory). There would probably need to be some kind of conflict resolution algorithm (my preference would be for records in the master zone file to always take precedence). Bonus points if the delta zone file is a plain text file, so it for example could be fed into, say, Git to generate a easily searchable history of changes. Also, having it as a plain text file would make it easy for any junior sysadmin to quickly get rid of any unwanted/problematic entries from the delta file if necessary.

Reassigned to @jvcelak

Status changed to closed

Continued in #450 (closed)

mentioned in issue #450 (closed)

removed milestone