[Opendnssec-user] OpenBSD porting questions regarding 2.x

[Berry A.W. van Halderen]

On 09/04/2016 01:26 PM, Patrik Lundin wrote:
> Hello again,
> 
> Another question that popped up when digging around: I am not entirely
> certain of the role of /var/opendnssec/enforcer/zones.xml.
> 
>>From what I can tell from the migration steps it is used by the signer
> and is supposed to be initally created by copying the old
> /etc/opendnssec/zonelist.xml there.

First of all, the zones.xml and zonelist.xml are two completely
different beasts.  They have a relation, but never mix them up.

1.4 did not have a zones.xml file, but (inappropriately) used the
zonelist.xml.  In order to migrate, it is fine to copy the zonelist.xml
to zones.xml as this will get you into the fist state.

I think it will get more clear when I describe the purpose of the two
files as it stands currently.

As for the zones.xml;  The signer needs to know which zones need to be
processed.  It needs to get this information from the enforcer, because
the enforcer first needs to handle a zone, if to be done properly.
There are a number of reasons why to pass this information not directly
into the signer, but through the enforcer.
The enforcer produces the zones.xml file upon changes.  It is not
intended to be manipulated from the outside.

The zonelist.xml;  There are basically two ways people like to use
OpenDNSSEC.  There are people that want the list of zones in use
to be in a file, edit the file themselves and let OpenDNSSEC use
this file as a source.  When items are added or deleted from the file,
then OpenDNSSEC should take the actions to add or remove the zones
from further down the pipeline.

This entails more than just drop the zone, and this is immediately a
drawback.  You cannot add a zone in a specific state, or drop a zone
and keep the files (or not).  For bootstrapping, it is nice though.

Another set of people just want commands (CLI) to add or delete a zone,
with options and control.

These two modes are not easily mixed.  When you add a zone using the CLI
and also adding or removing zones from the zonelist.xml you have two
conflicting sources of truth.  In 1.4 it was tried to marriage the two
believes, resulting in sometimes zones to be removed automatically from
your system, when you did not intend this.  When adding a zone though
the CLI, the zonelist.xml would be updated automatically, but the
existing zonelist.xml might actually not be in sync with the list of
zones in the enforcer database.

> It is then stated that zonelist.xml is no longer updated automatically,
> meaning the enforcer database is the authoritative source of information
> rather than that file. As stated in the example zonelist.xml:
> ===
> As a result in 2.0 the contents of the enforcer database should be considered
> the 'master' for the list of currently configured zones, not the zonelist.xml
> file as the file can easily become out of sync with the database.
> ===

Because of possible conflicts with the CLI and the zonelist.xml import,
and to be clear that there is one list of zones, we declare that the
list of zones as in use by the enforcer is authoritative.  To enable
the use case of the zonelist.xml editing, there are import, export and
flags to the zone add/del to synchronize the zonelist.xml and enforcer
zone listing.  The import and export commands in fact always existed and
needed to be called in the 1.4 usage also.  So in fact, only when trying
to mix both cases (which is tricky) it changed a bit.

Both use cases (CLI and file based) are valid and need to be supported,
however we want to advice not to mix them in normal use-cases.

> Instead I notice that /var/opendnssec/enforcer/zones.xml will be created or
> appended to when a zone is added with "ods-enforcer zone add --zone example.com".
> Why has this file been introduced? Doesn't the "can easily become out of sync
> with the database" hold true for this file as well?

Any change to existence of zones causes the zones.xml to be re-written.
 As adding or deleting zones in a normal setup is done through the
enforcer, only the failure to write the file or an outside
process manipulating the file (putting back a backup) could be the cause
of this.  We can't really fight those cases though.

Previously, mixing CLI and file based zonelist.xml manipulation could
mix up the understanding of the one true zone listing.

>>From my perspective there are now two files: zones.xml which is (hopefully)
> always in sync with the database, and zonelist.xml which _may_ be in sync with
> the database based on operational procedures (running "ods-enforcer zonelist
> export" from time to time or adding zones with --xml like "ods-enforcer zone
> add --zone example.com --xml".
> 
> If the goal is to not have two places that may get out of sync, why not have
> the signer fetch information directly from the database?

The zones.xml solution is not holy.  And the current solution is very
much under discussion.  There are some drawbacks.  The current signer
does not need to know anything about the enforcer datastructures and
operation.  Synchronization between enforcer and signer is explicit,
so the enforcer 'tells' the signer when there are updates and the signer
does not need to monitor for changes.
Our database transactions can not be real simple, since there is only
one process doing changes.

It is possible to run signer and enforcer on different systems, without
shared filesystem.  It is not unthinkable to make it possible to split
the signing over multiple machines in future.

That said, the interaction between enforcer and signer is now too much
of a mixed back.  Not just the zones.xml, but there are other processes.
I personally think this could be better.

> Finally, what is the appropriate thing to do with zones.xml on a fresh install?
> I notice an error is thrown since it is missing (not created by
> ods-enforcer-db-setup):
> ===
> Sep  4 12:31:22 obsd-amd64-t01 ods-signerd: [file] unable to stat file /var/opendnssec/enforcer/zones.xml: ods_fopen() failed
> ===
> 
> Is it standard operating procedure to get that error on a fresh install, and
> then making the system happy with the addition of the first zone?
> 

I think that is a proper procedure for now.  Maybe it would be better
for the default "make install" to create the zones.xml?  I think
most people still just ignore this message.  In many use cases the
zonelist.xml (whether empty or not) is immediately imported and at
this time the zones.xml is created.  For pure CLI use, a human will
start with the first zone.  But it would be better that no warning
was generated here in this case.

With kind regards,
Berry van Halderen