This documentation relates to an earlier version of OpenDNSSEC.
The documentation for the latest release is available at the current documentation home.

Skip to end of metadata
Go to start of metadata

There are xml files for each of the zones that the system is configured to sign. These define the API between the Enforcer and the Signer Engine. The Enforcer creates these files while implementing the policies and key management and the Signer Engine reads them when signing zones.

 

These files are should not be created or modified by users. However inspection of the content can be useful to troubleshoot problems.

 

The location of these files can be found in zonelist.xml, but we refer to signconf.xml if we speak about the general signer configuration file. The actual location of these files can be found in zonelist.xml.

Date/time durations are as specified here.

On this Page

Signer Configuration File

Preamble
<?xml version="1.0" encoding="UTF-8"?>
<!-- $Id: signconf.xml.in 3061 2010-03-16 19:23:51Z jakob $ -->

Each XML file starts with a standard element "<?xml...". As with any XML file, comments are included between the delimiters "<!--"

and "-->".

Configuration per zone
<SignerConfiguration>

The enclosing element of the XML file is the element <SignerConfiguration?> which, with the closing element </SignerConfiguration>, brackets one signer configuration.

...
	<Zone name="opendnssec.org">

Each zone is included in the <Zone>...</Zone> elements. Each zone has a "name" attribute giving the name of the zone.

Signatures

The next section of the file is the Signatures section, which lists the parameters for the signatures created using the policy. This is directly copied from the KASP policy file.

...
		<Signatures>
			<Resign>PT2H</Resign>
			<Refresh>P3D</Refresh>
			<Validity>
				<Default>P7D</Default>
				<Denial>P7D</Denial>
			</Validity>
			<Jitter>PT12H</Jitter>
			<InceptionOffset>PT300S</InceptionOffset>
		</Signatures>

For more information on the meaning of the elements and their elements, take a look at  KASP policy file.

Authenticated Denial of Existence

Authenticated denial of existence - proving that domain names do not exist in the zone - is handled by the <Denial> section, as shown below:

...

		<Denial>
			<NSEC3>
				<TTL>PT3600S</TTL>
				<OptOut/>
				<Resalt>P100D</Resalt>
				<Hash>
					<Algorithm>1</Algorithm>
					<Iterations>5</Iterations>
					<Salt length="8"/>
				</Hash>
			</NSEC3>
		</Denial>

<Denial> includes one element, either <NSEC3> (as shown above) or <NSEC>.

NSEC3

  • <NSEC3> tells the signer to implement NSEC3 scheme for authenticated denial of existence (described in RFC 5155). The elements are:
  • <TTL> - if present, use this duration for NSEC3PARAM TTL. If not present, PT0S (0) will be used as TTL (included since version 1.3.16).

    This will only affect the time-to-live value for the NSEC3PARAM resource records. The time-to-live value for NSEC3 records is set to the value of the SOA <Minimum>.

  • <OptOut/> - if present, enable "opt out". This is an optimisation that means that NSEC3 records are only created for authoritative data or for secure delegations; insecure delegations have no NSEC3 records. For zones where a majority of the entries are delegations that are not signed - typically TLDs during the take-up phase of DNSSEC - this reduces the number of DNSSEC records in the zone.

  • <Resalt> is the interval between generating new salt values for the hashing algorithm.
  • <Algorithm>, <Iterations> and <Salt> are parameters to the hash algorithm, described in RFC 5155.

NSEC

Should, instead, NSEC be used as the authenticated denial of existence scheme, the <Denial> element will contain the single element <NSEC/> - there are no other parameters.

Key Information

Parameters relating to keys can be found in the <Keys> section.

...
		<Keys>

Common Parameters
The section starts with a common parameter, TTL:

...
			<TTL>PT3600S</TTL>

<TTL> is the time-to-live value for the DNSKEY resource records.

Keys

Each key has a number of elements so the signer knows how the keyset should be used and published.

Those are held in the <Key> section:

...
			<Key>
				<Flags>257</Flags>
				<Algorithm>5</Algorithm>
				<Locator>DFE7265B783F418685380AA784C2F31D</Locator>
				<Publish/>
				<KSK/>
				<ZSK/>
			</Key>
  • <Flags> tells the signer what value it should set on this key when publishing the corresponding DNSKEY resource record.
  • <Algorithm> determines the algorithm used for the key (the numbers reserved for each algorithm can be found in the appropriate  IANA registry).
  • <Locator> stores the CKA_ID of the key, e.g. the location of the physical key.
  • <KSK/> - if present, use key as KSK. If a key is used as KSK, it must sign the DNSKEY RRset. It should not sign other RRsets, unless the <ZSK/> element is also present.
  • <ZSK/> - if present, use key as ZSK. If a key is used as ZSK, it must sign all other RRsets. It should not sign the DNSKEY RRset, unless the <KSK/> element is also present.
  • <Publish/> - if present, publish the corresponding DNSKEY resource record in the zone. The Public Key RDATA should be retrieved from the HSM using the CKA_ID (<Locator>).

The keyset is closed with the tag:

...
		</Keys>
Source of Authority

When automating DNSSEC, the SOA record needs to be adjusted from time to time. The necessary parameters can be found in the <SOA> section:

...
		<SOA>
			<TTL>PT3600S</TTL>
			<Minimum>PT3600S</Minimum>
			<Serial>unixtime</Serial>
		</SOA>

These values will override values set for the SOA record in the input zone file.

The values are:

  • <TTL> - TTL of the SOA record.
  • <Minimum> - value for the SOA's MINIMUM RDATA element.
  • <Serial> - the format of the serial number in the signed zone. This is one of:
    • counter - use an increasing counter (but use the serial from the unsigned zone if possible)
    • datecounter - use increasing counter in YYYYMMDDxx format (xx is incremented within each day)
    • unixtime - the serial number is set to the "Unix time" (seconds since 00:00 on 1 January 1970 (UTC)) at which the signer is run.
    • keep - keep the serial from the unsigned zone (do not resign unless it has been incremented)

Auditing

The zone will be audited before it is written to the signed directory, if the following tag is included.

...
		<Audit />

This is the last section of the signconf specification, so the next element is the zone closing tag:

...
	</Zone>

and the file is ended by closing the <SignerConfiguration> tag:

</SignerConfiguration>
  • No labels