$Id$ OpenDNSSEC 1.1.0 - Known Restrictions The following are the known problems and/or restrictions of release 1.1.0 of OpenDNSSEC. KSK rollover requires manual timing ----------------------------------- OpenDNSSEC rolls a key-signing key by the double-DS pre-publication method: the DS record for the new zone is extracted from OpenDNSSEC and sent to the parent zone. After a period of time, the KSK is changed and, after a further interval, the DS record for the old KSK is removed from the parent. The sending of the DS record to the parent zone necessarily involves manual intervention on your part, but version 1.0.0 of OpenDNSSEC also requires that you manually time two intervals: * The time between introducing the new KSK into the zone and sending the DS record to the parent. * Seeing the DS record in the parent zone and informing OpenDNSSEC of its presence. Future versions of the software will remove the need for tracking the time between these events. The KSK rollover procedure is described in the OpenDNSSEC documentation. Key rollover and reuse of signatures ------------------------------------ OpenDNSSEC makes use of reusing previously created signatures. A key that is in active state will be used for signing. When rolling keys, keys may become active or inactive. At these points in key rollover, all signatures that correspond to a previously active key (which just became inactive) need to be dropped and new signatures for the new, just activated key need to be created from scratch. OpenDNSSEC cannot handle a smooth transition between these states. Limitations on Number of Zones ------------------------------ Owing to contention in the key management database, performance is degraded if OpenDNSSEC is used to sign large numbers of zones that do not share common keys. The problem is worse if SQLite is used for the key and signature manager database. As a workaround, we suggest that either the same key is used for all zones, or that the number of zones be limited to about 5,000. This will be addressed in a future release of the software. Incompatibility in TSIG Key --------------------------- When setting up a TSIG key for the zone fetcher component, it should be noted that the SHA algorithm family used by OpenDNSSEC is incompatible with the BIND-9, due to a problem in the latter's cryptographic library. The problem is fixed in the upcoming BIND-9.7 release; in the meantime, avoid using TSIG authentication between the zone fetcher and the upstream nameserver. Possible Issue between enforcer and signer ------------------------------------------ We have seen, but only on centOS, an issue where when the enforcer signals the signer that a signer configuration file has changed the return value indicates an error. This happens even when the signer is running and has correctly processed the message. The result is that the enforcer does not message the signer about any more changes in that run. So, if any other zones change, they will not be seen until the next time the signer runs. If you are affected by this issue then you will see messages like this in your log: ods-enforcerd: Could not call signer engine ods-enforcerd: Will continue: call 'ods-signer update' to manually update zones Issue with sharing keys and adding zones ---------------------------------------- Due to a limitation in the way we keep track of key states, adding zones to a system that shares keys results in the new zone not getting copies of the standby KSKs. In general when sharing keys the user must be aware that any key will be in the same state for all zones. Issue with rolling from one algorithm to another ------------------------------------------------ The current version will handle key rollovers that also change algorithm just the same as any other key rollover. This is not sufficient; and so rolling between algorithms is broken and should not be done with the current system. Quicksorter does not allow certain owner names ------------------------------------------------ If a RR owner name looks like a directive, e.g., \$ORIGIN or $TTLexample, the quicksorter filters them away as being incorrect directives. It will crash on owner names like \$ORIGIN. Enforcer unit tests require environment variables ------------------------------------------------- In order to run the unit tests for the enforcer the following environment variables need to be set when configure is run: For a sqlite build: DB_NAME points to the file to be used during the unit tests. N.B. it will be deleted and recreated during the tests. For a mysql build: DB_USERNAME user to connect as DB_PASSWORD password for that user DB_HOST machine to connect to DB_NAME the schema to use, N.B. this schema will be torn down and recreated during the tests.