DNSSEC has changed the world of the DNS operator in two key respects. First, it has transformed the DNS from a primarily administrative system into a much more complex cryptographic platform (NL) that can be used for a wide variety of new applications (NL). Second, DNSSEC has introduced absolute times to a system that previously used only relative times (TTLs). Furthermore, with DNSSEC, the two timing methods need to interact.
In this article, we consider the timing aspects of DNSSEC by reference to the settings in OpenDNSSEC (NL) (in the file /etc/opendnssec/kasp.xml). OpenDNSSEC is the most widely used DNSSEC solution for BIND named, (NL) which in turn is the most popular DNS server.
Most big registrars use PowerDNS (NL), because good support for DNSSEC is built in. However, the makers of PowerDNS work on the basis that as much as possible should be automated and kept out of the user's (i.e. DNS operator's) sight. In line with that philosophy, PowerDNS doesn't provide (or require) any timing settings. We'll return to that minimalistic approach at the end of the article.
Proper understanding of DNSSEC's timing settings is important mainly in relation to the signing of resource record sets (RRSETs), the execution of key rollovers and the transfer of DNSSEC-enabled domain names (which is in effect a key rollover coordinated between two registrars). Fortunately, the first two of those processes usually run automatically once the initial setup is complete (scripting/configuration). The expectation is that fully automated secure transfers (NL) will soon be possible.
Overview
Following the implementation of DNSSEC, the DNS infrastructure makes use of three distinct timing methods:
TTL values are
relative
timestamps that are used to state the (remaining) lifetime of a record. Caching name servers use TTL values to count down the validity periods of cached records, which are measured in seconds. As time elapses and a record moves further away from the authoritative name server in the cache hierarchy, the TTL value decreases, until the record is deleted from the cache.
TTL values were a feature of the DNS protocol prior to DNSSEC and most operators are therefore familiar with them.
As well as a digital signature, RRSIG and NSEC(3) records each contain two
absolute
date stamps specifying the start and end of the validity period. The resource records need to be re-signed well before the associated signature expires. Both the validity period and the re-signing period are determined by the
relative
timing settings in the DNSSEC system.
This timing method is specific to DNSSEC and therefore a new feature of the DNS.
The cryptographic key pairs for signing the resource records and validating the signatures have an
administrative
validity period only. They are used by the DNSSEC system for a specific period, after which they need to be rolled over. However, the usage period isn't strictly enforced; until a new key pair becomes available, the old pair remains in use. The DNSKEY and DS records themselves do not contain any timing information. Hence, their
relative
(remaining) validity period is determined entirely by the associated TTL values.
The key pair settings are specific to DNSSEC and therefore a new feature of the DNS.
A number of points are worth highlighting with regard to particular records, signing and rollovers:
Both the old DNS records and the new DNSSEC records have
relative
(remaining) lifetimes determined by their TTL values. An RRSIG record must have a TTL value equal to that of the corresponding resource record.
In addition, a digital signature has an
absolute
validity period specified in the RRSIG record.
DNSKEY and DS key records do not include timing information. Such records therefore serve merely as links in the chain of trust.
Re-signing the resource records and rolling over the keys are separate but interdependent processes.
Re-signing is triggered by any of the following three events:
A change to the zone file
Expiry of the existing digital signature
Rollover of the (ZSK) key pair
TTL values do not influence re-signing.
The trigger for the rollover of a key pair is always administrative: 'expiry', a security incident, transfer to another registrar or adoption of a new cryptographic algorithm. The timing of a rollover therefore depends on both re-signing (of the key records) and TTL settings (for flushing out old information).
The various aspects are considered in more detail below and illustrated by reference to OpenDNSSEC timing settings.
Time To Live
Every DNS record has its own Time To Live (TTL) value: a relative statement of the remaining number of seconds that the record is valid. The initial value is specified in the zone file, sometimes for each individual record, but usually for all records collectively ($TTL in the SOA record).
The TTL value is passed on by the authoritative name servers to querying resolvers. Local DNS caches and caching name servers then use the TTL — or, at least, should use it — to define the validity period of the incoming records in the cache. They then communicate the remaining TTLs to any resolvers that subsequently ask for the records. The further a DNS record moves away from the authoritative server in the various caches, the shorter the remaining TTL value becomes, therefore.
Waiting periods
The TTL value in the authoritative zone file is crucial for the DNS operator's administrative domain name management. That is because it determines how long records may be left before they are 'flushed out' of all the caches on the internet where they have been saved. When setting the TTL value, an operator needs to strike a balance between how quickly updates and corrections can be made and the DNS server load. With DNSSEC, the TTL values are also reflected in the waiting periods that apply in the transfer protocol for secure domain names (NL).
With the exception of the $TTL variable, the timing values in the SOA record are intended for use only by slaves (typically secondary name servers). They are not therefore considered further in this article. In a DNS infrastructure where the master does not send NOTIFY signals to its slaves to initiate zone refreshes, the delay in propagation from the master to the slaves (the refresh time) does, however, need to be factored into timing calculations.
That is certainly something to consider when configuring a bump-in-the-wire set-up (NL). In that context, a hidden administrative master forwards its zone files to an intermediate station for signing, from where the signed zones are then distributed to the public name servers. In OpenDNSSEC, you include the delay in the '<Zone> <PropagationDelay>' variable (default: 43200s = 12 hours).
Signatures
For DNSSEC timing, the validity period of the signatures (NL) is the first important factor. The RRSIG records each contain two absolute date stamps specifying the start and end of the validity period (where the start is the time that the signature was set, which is usually a little earlier).
example.nl. 86400 IN RRSIG NS 8 3 86400 20160111034747
20160104084049 56851 example.nl. ETXBKyEVFcCs...The period in question is derived from the '<Signatures> <Validity> <Default>' and '<Denial>' variables, which specify the validity periods for, respectively, the ordinary RRSIG records and the NSEC3 (NL) RRSIG records. The period is typically set at between one and four weeks (default: two weeks).
Re-signing
The '<Refresh>' variable indicates when the DNS records need to be re-signed. A typical setting is three (default) to seven days before expiry. The related '<Resign>' variable specifies how often the OpenDNSSEC Signer should be started to check whether anything needs to be done (default: every two hours). The latter setting must be at least one order of magnitude smaller than the '<Refresh>' value, so that the policy timings can be followed correctly.
Because a validating resolver checks both the signature itself and its validity, it is vital that the re-signing process is followed correctly, which implies without human involvement. That is because an expired signature also precludes use of the record set. Furthermore, warnings must be issued (and seen!) if anything goes wrong. The fact that top-level domain operators have allowed their signatures to expire (NL) on several occasions illustrates that all humans are prone to make mistakes.
Keys
The lifetime of the key pairs is specified in the '<Keys>' block. The two '<Lifetime>' variables determine the validity period of the KSK and ZSK pairs (NL) (default set at, respectively, one year and three months).
However, unlike signatures, keys do not have a hard validity period. As the following illustrates, a DNSKEY record (like a DS record) contains only a TTL (here 86400 = 24 hours).
example.nl. 86400 IN DNSKEY 257 3 8 AwEAAcD39n4p...
example.nl. 86400 IN DS 12345 8 3 5248DB0EAE4E3...
The validity period of a key pair, as derived from the associated '<Lifetime>' variable, is therefore a purely administrative value. If an operator allows a key pair to expire, the outside world will not notice. The signing of the record sets and the publication of the public key will continue as normal.
Only the period stated in the RRSIG record is decisive for the validity of a signature, therefore. At least the associated public key (DNSKEY and DS record) must be available as long as valid RRSIG records are in circulation. The key records therefore serve merely as links in the chain of trust (NL).
Rollover
Before the (administrative) expiry of a KSK pair, the operator receives a message (via the log) saying that a rollover is required. By that stage, a new key pair has already been generated and the associated DNSKEY record has been published long enough to be visible everywhere (double KSK, as described in RFC 6781, section 2.2). The '<RolloverNotification>' variable in the file /etc/opendnssec/conf.xml determines how far in advance the process needs to be set in motion (default: 14 days).
At that point, the new key pair's status is 'ready' (as defined in RFC 7583, section 3.1), implying that OpenDNSSEC is waiting to be told that it can actually start using the key pair. OpenDNSSEC waits because, before the new key pair can be used, the new public key has to be published in the parent zone as a DS record to close the chain of trust, and that is currently still a manual procedure.
Transition
As soon as the new DS record is visible — since last month within one hour in the .nl zone — the transition can be initiated. The operator tells OpenDNSSEC to start the transition by giving the command 'ods-ksmutil key ds-seen -z example.nl. -x 12345'.
The new key cannot be used to sign records until the old DS records have been flushed from the caches everywhere. The waiting period before the new key can be used depends on the TTL value set for the DS records by the parent zone. With OpenDNSSEC, that has to be specified in the '<Parent> <DS> <TTL>' variable.
Finally, once the old RRSIG records have gone from all the caches as well, the old DNSKEY and DS records can be deleted. Deletion of the DNSKEY record is automatic, but old DS records have to be deleted from the parent zone manually.
For details of the timing aspects of various rollover methods for ZSK and KSK pairs, see RFC 7583.
TTL values
RFC 4034, section 3, states that the TTL value of the RRSIG records must be the same as that of the corresponding RRset. The $TTL value is set for the whole signed zone (in the SOA record) using the '<Zone> <SOA> <TTL>' variable (default: 3600s = one hour).
www.example.nl. 3600 IN AAAA 2001:DB8::1:26
www.example.nl. 3600 IN RRSIG AAAA 8 3 3600 20160111034747
20160104084049 56851 example.nl. ETXBKyEVFcCs...The TTL for the DNSKEY records is set separately using the '<Keys> <TTL>' variable (default: 3600s = one hour). Similarly, the TTL value of the NSEC3PARAM records is set using the '<Denial> <NSEC3> <TTL>' variable. Unless there is a good reason to do otherwise, it is best to eliminate the possibility of confusion by making the values the same as the $TTL value defined in the original zone file.
It is worth noting that, for most domains, the use of higher TTL values will not give rise to problems, since higher TTLs reduce DNS server loads. The trend towards the use of increasingly short TTLs has been led by large on-line service providers, who use TTLs for load distribution, and by system suppliers, who have an interest in increasing the demand for hardware. However, for operators who don't need to make zone changes very often and don't need their changes to be effective very quickly, extremely short TTLs are usually unnecessary.
Nevertheless, it is advisable to keep TTLs short during migration procedures (secure transfers) and when implementing new technology (DNSSEC), so that changes can be effected quickly. Short TTLs also mean that it doesn't take an entire day for an error that has already been propagated across the internet to be flushed from all caches.
PowerDNS
This article considers only those timing variables that illustrate the various timing aspects of DNSSEC. OpenDNSSEC offers numerous other timing options, including separate timing settings for NSEC records and extra margins for coping with minor time differences between systems, daylight saving time and network problems. Several dozen additional variables are involved.
The makers of PowerDNS work from a very different philosophy. "We have exactly zero DNSSEC-specific timing settings," said Senior Engineer Peter van Dijk. "We believe in smart defaults that work well for most users. We also build for a specific target group: large hosting service providers. From that target group, there is little or no demand for additional settings. In terms of additional settings, OpenDNSSEC is more suitable for specific deployments such as within TLD registries."
With PowerDNS, signatures are re-generated every Thursday, with a forward validity period of two weeks. And that's it. Automatic key rollovers are not even supported. "Why would you give your operators so much rope with which to hang themselves? The only argument for repeated key rollovers is that the practice means you can perform a smooth rollover whenever the need arises."