Skip to end of banner Go to start of banner

signconf.xml

Skip to end of metadata

Created by Sara Dickinson, last modified by Matthijs Mekking on 2012-11-07

There are xml files for each of the zones that the user wants to sign. Those 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, this is the time-to-live value for the NSEC3PARAM resource records. If not present, PT0S (0) will be used as TTL (included since version 1.4.3).

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 the DNSKEY RRset requires a new signature, use this key to sign the DNSKEY RRset.
<ZSK/> - if present, use key as ZSK. If another RRset (non-DNSKEY) require a new signature, use this key to sign that RRset.
<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>).

If both <KSK/> and <ZSK/> are used on the same <Key/>, it will be used to generate new signatures for both DNSKEY and non-DNSKEY RRsets, effectively making it a Combined Signing Key (CSK).

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)

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