DNS TIMEOUT Resource Record
draft-pusateri-dnsop-update-timeout-01

Abstract

This specification defines a new DNS TIMEOUT resource record (RR) that associates a lifetime with one or more zone resource records with the same owner name, type, and class. It is intended to be used to transfer resource record lifetime state between a zone's primary and secondary servers and to store lifetime state during server software restarts.

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."

This Internet-Draft will expire on August 22, 2019.

Copyright Notice

Copyright (c) 2019 IETF Trust and the persons identified as the document authors. All rights reserved.

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.

Table of Contents

• 1. Introduction
• 2. Requirements Language
• 3. Sources of TIMEOUT Expiry Time
• 4. Resource Record Composition
• 4.1. Record Type
• 4.2. Hash Count
• 4.3. Hash Algorithm Index
• 4.4. Expiry Time
• 4.5. Cryptographic Hashes
• 5. Cryptographic Hash Requirements
• 5.1. REQUIRED Cryptographic Hash Algorithm
• 6. TIMEOUT RR RDATA Wire Format
• 7. Primary Server Behavior
• 8. Secondary Server Behavior
• 9. TIMEOUT RR RDATA Presentation Format
• 10. IANA Considerations
• 11. Security Considerations
• 12. Acknowledgments
• 13. References
• 13.1. Normative References
• 13.2. Informative References
• Appendix A. Example TIMEOUT resource records
• Authors' Addresses

1. Introduction

DNS Update [RFC2136] provides a mechanism to dynamically add/remove DNS resource records to/from a zone. When a resource record is dynamically added, it remains in the zone until it is removed manually or via a subsequent DNS Update. A zone administrator may want to enforce a default lifetime for dynamic updates (such as the DHCP lease lifetime) or the DNS Update may contain a lifetime using an EDNS(0) Update Lease option [I-D.sekar-dns-ul]. However, this lease lifetime is not communicated to secondary servers and will not endure through server software restarts. Therefore, this specification defines a new DNS TIMEOUT resource record that associates a lifetime with one or more resource records with the same owner name, type, and class that can be transferred to secondary servers through normal AXFR [RFC5936], IXFR [RFC1995] transfer mechanisms.

2. Requirements Language

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. These words may also appear in this document in lower case as plain English words, absent their normative meanings.

3. Sources of TIMEOUT Expiry Time

The expire time may come from many different sources. A few are listed here however, this list is not considered complete.

1. Via DHCP Dynamic Lease Lifetime communicated out of band.
2. Via EDNS(0) Update Lease option [I-D.sekar-dns-ul] communicated in DNS Update.
3. Via an administrative default server value such as one day (86400 seconds).

4. Resource Record Composition

The TIMEOUT resource record provides expiry times for a mixed variety of resource record types with the same owner name, type, and class. Since there could exist multiple records of the same record type with the same owner name and class, the TIMEOUT resource record must be able to identify each of these records individually with only different RDATA. As an example, PTR records for service discovery provide a level of indirection to SRV and TXT records by instance name. The instance name is stored in the PTR RDATA and multiple PTR records with the same owner name but only differing RDATA often exist.

In order to distinguish each individual record with potentially different expiry times, the TIMEOUT resource record is made up of multiple lists of hashes of the records for which they are applicable. Each list has an expiry time associated with it and each hash corresponds to a resource record for which that expiry time applies. Each resource record represented by a hash in the list uses the same expiry time associated with the list. There is also a hash algorithm index associated with each list. All hashes in the list MUST use the same hash algorithm.

Since each TIMEOUT resource record is actually a collection of state from different sources over different time periods, there is a potential for default algorithm changes to occur on a single server or due to unavailability of an UPDATE server for a period of time to merge records between failover servers with different default algorithms. Therefore, the ability to have different hash algorithms in the same TIMEOUT resource record is accounted for. While this won't be a common scenario, it could occur during failure and restart scenarios. All hashes for the same expiry time MUST use the same hash algorithm. This is not likely to cause any problems with merging since the same server will be using the same default hash algorithm at a particular second resolution in time.

Within the TIMEOUT resource record there can exist an arbitrary number of combinations of applicable Record Type, Hash Algorithm Index, Hash Count, Expiry Time, and list of zero or more cryptographic hashes. The specific fields and their values are defined as:

4.1. Record Type

A 16-bit field containing the resource record type to which the TIMEOUT record applies. Multiple TIMEOUT records for the same owner name can exist (one for each record type, class combination).

4.2. Hash Count

The Hash Count is a 8-bit value that specifies the number of hash values for the instance. All hashes within the instance MUST use the same Hash Algorithm specified by the Hash Algorithm Index.

A Hash Count of 0 indicates that no hashes are contained in the list. This is a shortcut notation meaning all resource records with the same owner name, record type, and class use the same Expiry Time. There MUST be only one instance of Hash Count and Hash Algorithm Index in this case. When the Hash Count is 0, the Hash Algorithm Index is set to NOHASH (0) on transmission and ignored on reception.

In the unlikely event that the Hash Count exceeds 255 which is the largest number representable in 8 bits, multiple instances of the same Expiry Time can exist.

4.3. Hash Algorithm Index

The Hash Algorithm Index is a 8-bit value that specifies an identifier for the hash algorithm used. The indexes are declared in a registry maintained by IANA for the purpose of listing acceptable hash algorithms for this purpose. In addition to the algorithm and the index, the registry will contain the output length in bits of the algorithm to be used. It is conceivable, though not likely, that the same algorithm could be used with different output lengths. In this case, each output length would require a different index in the registry. Additions to this registry will be approved with additional documentation under expert review. At the time that the registry is created by IANA, a group of expert reviewers will be established.

The Hash Algorithm Index of 0 is defined as NOHASH and MUST NOT be used if any hash values are present in the instance. The index value of 0 is to be included in the IANA registry of Hash Algorithm Index values.

4.4. Expiry Time

The expiry time is a 64-bit number expressed as the number of seconds since the UNIX epoch (00:00:00 UTC on January 1, 1970). This value is an absolute time at which the record will expire. Lease times must be converted to an absolute expiry time when received.

4.5. Cryptographic Hashes

The hash of each resource record is calculated using the entire length of the resource record as input. The output value of the hash is always a fixed pre-defined length specified with the hash algorithm. Any names contained in a resource record MUST be hashed in an uncompressed form.

5. Cryptographic Hash Requirements

The cryptographic hash algorithm used SHOULD provide the following properties:

1. Well known algorithm with implementations easily available.
2. Trusted algorithm with resistance to collision attacks.
3. Minimize output length for efficient storage in the TIMEOUT resource record.

While computational complexity is always a consideration when selecting algorithms, the frequency of this calculation is intended to be low volume and, therefore, this property is of reduced importance.

5.1. REQUIRED Cryptographic Hash Algorithm

The initial algorithm selected to meet this criteria is SHAKE128. It is part of the SHA-3 [SHA3] family of cryptographic hash algorithms. The output length of the hash used is 128 bits or 16 bytes. SHAKE128 is implemented in the OpenSSL Library version 1.1.1 [OPENSSL]. In order to be in compliance with this specification, the SHAKE128 algorithm MUST be implemented. SHAKE128 is to be assigned an algorithm index of 1 in the IANA registry.

Additional algorithms may be defined in the future that can be used in place of SHAKE128.

6. TIMEOUT RR RDATA Wire Format

The TIMEOUT resource record follows the same pattern as other DNS resource records as defined in Section 3.2.1 of [RFC1035].

The RDATA section of the resource record is illustrated in Figure 1:

        
 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|             RR Type           |  Count A (n)  |  Algorithm A  |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                      Expiry Time A (64-bit)                   |
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
.                                                               .
.                            Hash A-1                           .
.                                                               .
.                                                               .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
.                                                               .
.                            Hash A-n                           .
.                                                               .
.                                                               .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|             RR Type           |  Count B (m)  |  Algorithm B  |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                      Expiry Time B (64-bit)                   |
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
.                                                               .
.                            Hash B-1                           .
.                                                               .
.                                                               .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
.                                                               .
.                            Hash B-m                           .
.                                                               .
.                                                               .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        
        

Figure 1: RDATA Wire Format

Figure 1 represents an arbitrary number of combinations of applicable Record Type, Hash Count, Hash Algorithm Index, Expiry Time, and list of zero or more cryptographic hashes. The figure entries containing "A" in the name represent one instance while the figure entries containing "B" in the name represent a second instance. There can be an arbitrary number of instances whose byte counts are accumulated by the RDLEN field in the resource record header.

The letter "n" represents the Hash Count in the first instance where there exists 0..n cryptographic hashes in the list. The letter "m" represents the Hash Count in the second instance where there exists 0..m cryptographic hashes in the second list. Either "n" or "m" could be zero.

7. Primary Server Behavior

A TIMEOUT resource record MUST be removed when the last resource record it covers has been removed. This may be due to the record expiring (reaching the expiry time) or due to a subsequent DNS Update or administrative action.

Upon receiving any DNS UPDATE deleting resource records that might have been covered by a TIMEOUT RR, a primary server MUST go through all instances within the TIMEOUT RR and delete all hashes matching the relevant resource records.

As a reminder from Section 3.3.13 of [RFC1035], the MINIMUM field of the SOA for the zone is used as a lower bound of the TTL for all records in the zone. Therefore, even if the TIMEOUT record will expire in less time than the MINIMUM, the TTL is still set to the MINIMUM for records covered by the TIMEOUT record and the TIMEOUT record itself when a response is returned by an authoritative server. The TIMEOUT RR is mostly for the benefit of the authoritative server to know when to remove the records. The fact that some records might live longer in the cache of a resolver is no different than other records that might get removed while still in a remote resolver cache.

8. Secondary Server Behavior

A secondary server may or may not understand TIMEOUT resource records. If a secondary server does not understand them, they are treated like any other resource record that the server may not understand [RFC3597].

A secondary server MUST NOT expire the records in a zone it maintains covered by the TIMEOUT resource record and it MUST NOT expire the TIMEOUT resource record itself when the last record it covers has expired. The secondary server MUST always wait for the records to be removed or updated by the primary server.

9. TIMEOUT RR RDATA Presentation Format

Record Type:

resource record type mnemonics. When the mnemonic is unknown, the TYPE representation described in Section 5 of [RFC3597]

Hash Count:

unsigned decimal integer

Hash Algorithm index:

unsigned decimal integer

Expiry Time:

Internet Date/Time Format from [RFC3339] Section 5.6 profile of ISO 8601 basic notation

Hash:

Base64 encoding (whitespace allowed), Section 4 of [RFC4648]

10. IANA Considerations

This document defines a new DNS Resource Record Type named TIMEOUT to be exchanged between authoritative primary and secondary DNS servers. It is assigned out of the DNS Parameters Resource Record (RR) Type registry. The value for the TIMEOUT resource record type is TBA.

This document establishes a new registry of DNS TIMEOUT Resource Record Cryptographic Hash Algorithm Index values. The registry shall include an index, an index name, the name of the algorithm, and the length of the output function in bits. The index is to be used in the RDATA section of the TIMEOUT resource record.

11. Security Considerations

Vulnerabilities in cryptographic hash algorithms may become known over time. This specification only defines one well respected algorithm (SHAKE128) for hashing resource records to maximize interoperability. The IANA registry is defined for the future when vulnerabilities are found in this algorithm. Until that point, there likely will not exist a need to add new hash algorithms to the registry.

12. Acknowledgments

This idea was motivated through conversations with Mark Andrews. Thanks to Mark as well as Paul Vixie, Joe Abley, and Ted Lemon for their suggestions, review, and comments.

13. References

13.1. Normative References

13.2. Informative References

Appendix A. Example TIMEOUT resource records

The following example shows sample TIMEOUT resource records based on DNS UPDATEs containing A and AAAA address records plus the corresponding PTR records.

A host sending a name registration at time Tn for A and AAAA records with lease lifetime Ln would have a series of UPDATEs (one for each zone) that contain:

Next, consider the TIMEOUT resource records that would be generated for the records in Table 2. Notice that none of the 4 TIMEOUT records on the server would require a hash:

Next, assume there are two hosts advertising the same service type (different service types will have different owner names). We will use _ipp._tcp.example.com as an example.

Host A sends an UPDATE at time Ta with lease life La for PTR, SRV, A, AAAA, and TXT records. Host B sends an UPDATE at time Tb with lease life Lb for PTR, SRV, A, and TXT records.

For these printer registrations, the TIMEOUT records on the server would look like the following:

Authors' Addresses