[Docs] [txt|pdf|xml] [Tracker] [WG] [Email] [Nits]
Versions: 00 01 02 03 04
draft-dnsop-update-timeout
Internet Engineering Task Force T. Pusateri
Internet-Draft T. Wattenberg
Intended status: Standards Track Unaffiliated
Expires: February 24, 2019 August 23, 2018
DNS TIMEOUT Resource Record
draft-pusateri-dnsop-update-timeout-00
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 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 February 24, 2019.
Copyright Notice
Copyright (c) 2018 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
Pusateri & Wattenberg Expires February 24, 2019 [Page 1]
Internet-Draft TIMEOUT Resource Record August 2018
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 2
2. TIMEOUT Resource Record Properties . . . . . . . . . . . . . 3
3. Secondary Server Behavior . . . . . . . . . . . . . . . . . . 3
4. Sources of TIMEOUT Expiry Time . . . . . . . . . . . . . . . 4
5. Resource Record Composition . . . . . . . . . . . . . . . . . 4
5.1. Hash Count . . . . . . . . . . . . . . . . . . . . . . . 5
5.2. Hash Algorithm Index . . . . . . . . . . . . . . . . . . 5
5.3. Expiry Time . . . . . . . . . . . . . . . . . . . . . . . 5
5.4. Cryptographic Hashes . . . . . . . . . . . . . . . . . . 6
6. Cryptographic Hash Requirements . . . . . . . . . . . . . . . 6
6.1. REQUIRED Cryptographic Hash Algorithm . . . . . . . . . . 6
7. TIMEOUT RR RDATA Wire Format . . . . . . . . . . . . . . . . 6
8. TIMEOUT RR RDATA Presentation Format . . . . . . . . . . . . 8
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
10. Security Considerations . . . . . . . . . . . . . . . . . . . 8
11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 9
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 9
12.1. Normative References . . . . . . . . . . . . . . . . . . 9
12.2. Informative References . . . . . . . . . . . . . . . . . 10
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10
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]. This lease
lifetime is not communicated to secondary servers and will not endure
through server software restarts. This specification defines a new
DNS TIMEOUT resource record that associates a lifetime with one or
more resource records with the same owner name and class that can be
transferred to secondary servers through normal AXFR [RFC5936], IXFR
[RFC1995] transfer mechanisms.
1.1. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119].
Pusateri & Wattenberg Expires February 24, 2019 [Page 2]
Internet-Draft TIMEOUT Resource Record August 2018
2. TIMEOUT Resource Record Properties
TIMEOUT resource records have different properties than normal DNS
resource records.
1. TIMEOUT resource records are only defined for CLASS IN.
2. TIMEOUT resource records are only for administrative use and they
cannot be directly queried via the normal DNS request/response
query mechanism. Valid requests for TIMEOUT resource record
types MUST return responses with an NOERROR RCODE and an ANSWER
COUNT of zero.
3. TIMEOUT resource records are not automatically sent in AXFR, IXFR
zone transfer requests. Both primary and secondary servers
should be configured on a per zone basis to transfer TIMEOUT
resource records to ensure they are supported.
4. TIMEOUT resource records are not considered for
DNSSEC/NSEC/NSEC3/NSEC5 record construction.
5. TIMEOUT resource records cannot be directly added, modified, or
deleted through DNS Update.
6. 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.
3. Secondary Server Behavior
A secondary server may or may not understand TIMEOUT resource
records. The primary server should not be configured to send TIMEOUT
resource records if the secondary server does not understand them.
However, if TIMEOUT resource records are mistakenly transferred to a
server that does not understand them, they are treated like any other
resource record that the server may not understand [RFC3597].
A secondary server that does understand the TIMEOUT resource records
it receives in a transfer MUST abide by the properties of the
resource record type defined in Section 2.
A secondary server will independently expire the records in a zone it
maintains covered by the TIMEOUT resource record as well as expire
the TIMEOUT resource record itself when the last record it covers has
expired in the same manner that a primary server would.
Pusateri & Wattenberg Expires February 24, 2019 [Page 3]
Internet-Draft TIMEOUT Resource Record August 2018
If a TIMEOUT resource record is removed from a subsequent zone
transfer, the secondary server MUST also remove it from its zone
database regardless of the expiry time.
4. 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).
5. Resource Record Composition
The TIMEOUT resource record must provide expiry times for a mixed
variety of resource record types with the same owner name 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
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
Pusateri & Wattenberg Expires February 24, 2019 [Page 4]
Internet-Draft TIMEOUT Resource Record August 2018
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 Hash Algorithm Index, Hash Count, Expiry
Time, and list of zero or more cryptographic hashes. The specific
fields and their values are defined as:
5.1. Hash Count
The Hash Count is a 16-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 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.
5.2. Hash Algorithm Index
The Hash Algorithm Index is a 16-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.
5.3. 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
Pusateri & Wattenberg Expires February 24, 2019 [Page 5]
Internet-Draft TIMEOUT Resource Record August 2018
is an absolute time at which the record will expire. Lease times
must be converted to an absolute expiry time when received.
5.4. 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.
6. 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.
6.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. Coordination between the primary and secondary
servers is required out of band to ensure both sides of a transfer
have implemented the particular algorithm.
7. 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].
Pusateri & Wattenberg Expires February 24, 2019 [Page 6]
Internet-Draft TIMEOUT Resource Record August 2018
When transferred to a secondary server, the TTL field of the TIMEOUT
resource record is set to 0. The TTL has no meaning since TIMEOUT
RR's are never directly queried.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Hash Count A (n) | Hash Algorithm Index A |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Expiry Time A (64-bit) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. Hash A-1 .
. .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. Hash A-n .
. .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Hash Count B (m) | Hash Algorithm Index 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 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
Pusateri & Wattenberg Expires February 24, 2019 [Page 7]
Internet-Draft TIMEOUT Resource Record August 2018
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.
8. TIMEOUT RR RDATA Presentation Format
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
Hash: Base64 encoding (whitespace allowed), Section 4 of [RFC4648]
9. 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.
+-------+----------+-----------+---------------+-------------+
| Index | Name | Algorithm | Length (bits) | Definition |
+-------+----------+-----------+---------------+-------------+
| 0 | NOHASH | | 0 | Section 5.2 |
| 1 | SHAKE128 | SHAKE128 | 128 | Section 6.1 |
+-------+----------+-----------+---------------+-------------+
Table 1: TIMEOUT RR Hash Algorithm Index values
10. Security Considerations
Secondary servers that have received TIMEOUT resource records in a
transfer but do not understand the record type will serve requests
for them like any other resource record type. This is a
Pusateri & Wattenberg Expires February 24, 2019 [Page 8]
Internet-Draft TIMEOUT Resource Record August 2018
configuration error and can reveal the time that other DNS resource
records will be present.
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.
11. Acknowledgments
This idea was motivated through conversations with Mark Andrews.
12. References
12.1. Normative References
[RFC1035] Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC 1035, DOI 10.17487/RFC1035,
November 1987, <https://www.rfc-editor.org/info/rfc1035>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC3339] Klyne, G. and C. Newman, "Date and Time on the Internet:
Timestamps", RFC 3339, DOI 10.17487/RFC3339, July 2002,
<https://www.rfc-editor.org/info/rfc3339>.
[RFC3597] Gustafsson, A., "Handling of Unknown DNS Resource Record
(RR) Types", RFC 3597, DOI 10.17487/RFC3597, September
2003, <https://www.rfc-editor.org/info/rfc3597>.
[RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data
Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006,
<https://www.rfc-editor.org/info/rfc4648>.
[SHA3] National Institute of Standards and Technology, "SHA-3
Standard - Permutation-Based Hash and Extendable-Output
Functions FIPS PUB 202", August 2015,
<https://www.nist.gov/publications/sha-3-standard-
permutation-based-hash-and-extendable-output-functions>.
Pusateri & Wattenberg Expires February 24, 2019 [Page 9]
Internet-Draft TIMEOUT Resource Record August 2018
12.2. Informative References
[I-D.sekar-dns-ul]
Cheshire, S. and T. Lemon, "Dynamic DNS Update Leases",
draft-sekar-dns-ul-02 (work in progress), August 2018.
[OPENSSL] OpenSSL Software Foundation, "OpenSSL: Cryptography and
SSL/TLS Toolkit", October 2017, <https://www.openssl.org>.
[RFC1995] Ohta, M., "Incremental Zone Transfer in DNS", RFC 1995,
DOI 10.17487/RFC1995, August 1996,
<https://www.rfc-editor.org/info/rfc1995>.
[RFC2136] Vixie, P., Ed., Thomson, S., Rekhter, Y., and J. Bound,
"Dynamic Updates in the Domain Name System (DNS UPDATE)",
RFC 2136, DOI 10.17487/RFC2136, April 1997,
<https://www.rfc-editor.org/info/rfc2136>.
[RFC5936] Lewis, E. and A. Hoenes, Ed., "DNS Zone Transfer Protocol
(AXFR)", RFC 5936, DOI 10.17487/RFC5936, June 2010,
<https://www.rfc-editor.org/info/rfc5936>.
Authors' Addresses
Tom Pusateri
Unaffiliated
Raleigh, NC
USA
Email: pusateri@bangj.com
Tim Wattenberg
Unaffiliated
Cologne
Germany
Email: mail@timwattenberg.de
Pusateri & Wattenberg Expires February 24, 2019 [Page 10]
Html markup produced by rfcmarkup 1.129d, available from
https://tools.ietf.org/tools/rfcmarkup/