Internet DRAFT - draft-dnsop-update-timeout
draft-dnsop-update-timeout
Internet Engineering Task Force T.J. Pusateri
Internet-Draft T. Wattenberg
Intended status: Standards Track Unaffiliated
Expires: 25 November 2020 24 May 2020
DNS TIMEOUT Resource Record
draft-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.
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 25 November 2020.
Copyright Notice
Copyright (c) 2020 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.
Pusateri & Wattenberg Expires 25 November 2020 [Page 1]
Internet-Draft TIMEOUT Resource Record May 2020
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3
3. Sources of TIMEOUT Expiry Time . . . . . . . . . . . . . . . 3
4. Common Usage Patterns . . . . . . . . . . . . . . . . . . . . 4
4.1. TIMEOUT records vs. Update Leases . . . . . . . . . . . . 5
4.2. Testing for TIMEOUT . . . . . . . . . . . . . . . . . . . 6
5. Resource Record Composition . . . . . . . . . . . . . . . . . 6
5.1. Represented Record Type . . . . . . . . . . . . . . . . . 6
5.2. Represented Record Count . . . . . . . . . . . . . . . . 7
5.3. Method Identifiers . . . . . . . . . . . . . . . . . . . 7
5.3.1. Method Identifier 0: NO METHOD . . . . . . . . . . . 8
5.3.2. Method Identifier 1: MD-SHA256-128 . . . . . . . . . 8
5.4. Expiry Time . . . . . . . . . . . . . . . . . . . . . . . 8
6. TIMEOUT RDATA Wire Format . . . . . . . . . . . . . . . . . . 9
7. Server Behavior . . . . . . . . . . . . . . . . . . . . . . . 10
7.1. Primary Server Behavior . . . . . . . . . . . . . . . . . 10
7.2. Secondary Server Behavior . . . . . . . . . . . . . . . . 11
8. TIMEOUT RDATA Presentation Format . . . . . . . . . . . . . . 11
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
10. Security Considerations . . . . . . . . . . . . . . . . . . . 13
11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 13
12.1. Normative References . . . . . . . . . . . . . . . . . . 13
12.2. Informative References . . . . . . . . . . . . . . . . . 14
Appendix A. Example TIMEOUT resource records . . . . . . . . . . 15
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17
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. The context of a dynamic
update may provide lifetime hints for the updated records (such as
the EDNS(0) Update Lease option [I-D.sekar-dns-ul]), however, this
lifetime is not communicated to secondary servers and will not
necessarily endure through server software restarts. This
specification defines a new DNS TIMEOUT resource record that
associates lifetimes 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.
An UPDATE lifetime could be stored in a proprietary database on an
authoritative primary server but there is an advantage to saving it
as a resource record: redundant master servers and secondary servers
Pusateri & Wattenberg Expires 25 November 2020 [Page 2]
Internet-Draft TIMEOUT Resource Record May 2020
capable of taking over as the primary server for a zone automatically
can benefit from the existing database synchronization of resource
records. In addition, primary and secondary servers from multiple
vendors can synchronize the lifetimes through the open format
provided by a resource record.
TIMEOUT records can be installed via policy by a primary server,
manually, or via an external UPDATE from a client. If TIMEOUT
records are being managed by an UPDATE client, the client should be
aware of server software policy with respect to TIMEOUT records to
prevent the TIMEOUT records from being rejected. The primary server
has ultimate responsibility for the records in the database and the
client must work within the restrictions of the policy of the primary
server.
TIMEOUT records can be thought of as a universal method for removing
stale dynamic DNS records. Clients such as DHCP servers who best
know the lease lifetimes can include individual TIMEOUT records in
the dynamic UPDATE messages specific for each lease lifetime. These
TIMEOUT records can be refreshed when the lease is refreshed and will
timeout the A, AAAA, and PTR records if they are not refreshed by the
DHCP server. Additional use cases include service discovery resource
records installed in unicast DNS servers via UPDATE described in
[RFC6763], Active Directory Controllers publishing SRV records, DNS
TXT resource records supporting ACME certificate management
challenges as described in [RFC8555], Section 8.4, and the limited
lifetime certificate representations produced by ACME that are stored
in DANE TLSA resource records [RFC6698].
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. TIMEOUT
records may be included along side the records they represent in the
UPDATE message or they be synthesized by the primary server receiving
the UPDATE.
* Via DHCP Lease Lifetimes.
Pusateri & Wattenberg Expires 25 November 2020 [Page 3]
Internet-Draft TIMEOUT Resource Record May 2020
* Via EDNS(0) Update Lease option [I-D.sekar-dns-ul] communicated in
DNS Update.
* Via an administrative default value such as one day (86400
seconds).
4. Common Usage Patterns
TIMEOUT resource records are just one tool in the toolbox for
cleaning up stale resource records. They provide a failsafe in case
other mechanisms meant to clean up records fail. It might be useful
to think of them similar to Garbage Collection (GC) or Automatic
Reference Counting (ARC) used by programming languages for memory
management. The model in which the TIMEOUT resource records are used
depends on the support provided for them by the primary DNS server.
As it cannot be presumed that all primary authoritative servers will
manage TIMEOUT resource records internally, an external management of
the TIMEOUT records and the resource records they represent might be
necessary. The client may perform external management of TIMEOUT
records it creates through an UPDATE or a third party with
appropriate permission may manage the records.
If the primary server understands TIMEOUT records and manages them
based on resource record updates, it will likely know when to remove
the resource records referenced by the TIMEOUT records. This is
similar to ARC.
┌─────────────┐
│Client UPDATE│
│ with EDNS0 │───┐
└─────────────┘ │ ┌───────────────┐
│ │ Primary │ Zone ┌─────────┐
┌────────────────┐ ├──▶│(Authoritative)│───Transfer──▶│Secondary│
│ UPDATE with │ │ └───────────────┘ └─────────┘
│TIMEOUT included│───┘
└────────────────┘
If the primary server does not understand TIMEOUT records, then an
external manager (client) will need to use DNS UPDATE to manage
TIMEOUT records and the resource records they reference. Garbage
Collectors run periodically looking for memory no longer being used
to reclaim. In a similar way, external TIMEOUT record managers need
to periodically scan the TIMEOUT records and send DNS UPDATE messages
to add/remove records when the server doesn't manage them
automatically.
Pusateri & Wattenberg Expires 25 November 2020 [Page 4]
Internet-Draft TIMEOUT Resource Record May 2020
┌────────────────┐ ┌───────────────┐
│ UPDATE with │ │ Primary │ Zone ┌─────────┐
│TIMEOUT included│───────▶│(Authoritative)│───Transfer──▶│Secondary│
└────────────────┘ └───────────────┘ └─────────┘
│ ▲
Zone │
Transfer UPDATE
│ │
┌─────────────┐ ▼ │
│Client UPDATE│ ┌───────────────┐
│ with EDNS0 │───────▶│ timeoutd │
└─────────────┘ └───────────────┘
It should be noted that similar to many instances of Garbage
Collection, the precision with which TIMEOUT records and the resource
records they reference are removed is not critical. Gross timers
and/or scanning mechanisms are perfectly appropriate and should not
consume additional resources for the purpose of being precise. As
described in Section 5.4 below, expiry times use one second
resolution.
4.1. TIMEOUT records vs. Update Leases
Each application will have to determine when it is better to use
TIMEOUT resource records, EDNS(0) Update Lease options, or a
combination of the two. In some cases, either will serve the same
purpose. A differentiating factor is that TIMEOUT resource records
use absolute time so that the records may be more easily synchronized
across secondary servers whereas Update Leases are specified in
relative time offsets.
If your primary DNS server supports TIMEOUT records directly, it may
be simpler to just provide an Update Lease lifetime in the DNS UPDATE
message that the server will use to create the TIMEOUT records
internally. If your primary DNS server does not support TIMEOUT
records and your application uses sources that have real-time clocks
that are synchronized with standard time sources, TIMEOUT records are
an available option to the client. However, if your clients are
using low-cost hardware without real-time clocks, they should send
Update Leases to the primary server or an intermediate proxy with a
synchronized real-time clock.
Pusateri & Wattenberg Expires 25 November 2020 [Page 5]
Internet-Draft TIMEOUT Resource Record May 2020
4.2. Testing for TIMEOUT
There is no more reliable mechanism to determine if the primary DNS
server supports the management of TIMEOUT records than explicitly
trying it. Before relying on a server to expire TIMEOUT records, the
application should send test records and test if they are handled as
expected. If the preferred mode of operation is not supported,
another mode can be attempted. For example, if sending a DNS UPDATE
with a EDNS(0) Update Lease of 1 second doesn't cause the record to
be expired within 6 seconds (1 + 5 fuzz), then the application can
try including a TIMEOUT record in the DNS UPDATE. If that doesn't
automatically expire, TIMEOUT records will need to be managed
externally.
5. Resource Record Composition
TIMEOUT resource records provide 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
[RFC6763] 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 and only differing
RDATA often exist.
In order to distinguish each individual record with potentially
different expiry times, the TIMEOUT resource record contains an
expiry time, the record type, a method to identify the actual records
for which the expiry time applies, and a count of the number of
records represented. Multiple TIMEOUT records with the same owner
name and class are created for each expiry time, record type, and
resource record representation. If the expiry time is the same,
multiple records can be combined into a single TIMEOUT record with
the same owner name, class, and record type but this is not required.
The fields and their values in a TIMEOUT record are defined as:
5.1. Represented 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, class, and represented type can exist. Any resource record
type can be specified in the Represented Record Type including
another TIMEOUT record. This specification does not put any
restrictions on the record type but implementations in authoritative
servers will likely do so for policy and security reasons.
Pusateri & Wattenberg Expires 25 November 2020 [Page 6]
Internet-Draft TIMEOUT Resource Record May 2020
QTYPEs and Meta-TYPEs MUST NOT be used as the represented record
type. For more information, refer to [RFC6895], Section 3.1.
5.2. Represented Record Count
The Represented Record Count is a 8-bit value that specifies the
number of records of the specified record type with this expiry time.
A count of zero indicates that it is not necessary to represent any
records in the list. This is a shortcut notation meaning all
resource records with the same owner name, class, and record type use
the same Expiry Time. When the Represented Record Count is 0, the
Method Identifier is set to NO METHOD (0) on transmission and ignored
on reception. A primary server MUST NOT install a TIMEOUT record
with No Method/No Count at the same time that a TIMEOUT record exists
for the same owner name, class, and type with a non-zero record
count. Either all records MUST match the No Method/No Count
shorthand syntax or they MUST all be included in the list of matching
records.
In the unlikely event that the Represented Record Count exceeds 255
which is the largest number representable in 8 bits, multiple
instances of the same Expiry Time can exist.
5.3. Method Identifiers
The Method Identifier is a 8-bit value that specifies an identifier
for the algorithm used to distinguish between resource records. The
identifiers are declared in a registry maintained by IANA for the
purpose of listing acceptable methods for this purpose. In addition
to the method and the index, the registry MAY contain a fixed output
length in bits of the method to be used or the term "variable" to
denote a variable length output per record. It is conceivable,
though not likely, that the same method could be used with different
fixed output lengths. In this case, each fixed output length would
require a different identifier 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.
Pusateri & Wattenberg Expires 25 November 2020 [Page 7]
Internet-Draft TIMEOUT Resource Record May 2020
Additional methods of representing records may be defined in the
future. If such methods are defined, a primary server could create
TIMEOUT record using a new method that is not understood by a
secondary server that could take over as the primary in the event of
an outage or administrative change. In this case, the new primary
would not be able to identify the records it is supposed to TIMEOUT.
This is a misconfiguration and it is the responsibility of the
administrator to ensure that secondary servers in a position to
become primary understand the TIMEOUT record methods of the primary
server.
5.3.1. Method Identifier 0: NO METHOD
The method identifier of 0 is defined as "NO METHOD" and MUST NOT be
used if the represented record count is greater than 0. The value of
0 is to be included in the IANA registry of method identifier values.
5.3.2. Method Identifier 1: MD-SHA256-128
The method identifier of 1 is defined as "MD-SHA256-128". Following
the expiry time is a list of 128-bit values. Each of these values is
the first 128-bits of a message digest of the RDATA of a represented
record in canonical DNSSEC form calculated using the 256-bit SHA-256
hash algorithm defined in [FIPS180-4]. The canonical DNSSEC form is
described in [RFC4034], Section 6. The input length of RDATA for the
message digest is the RDLEN of the represented record.
5.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. An absolute
time is necessary so the TIMEOUT records do not have to change during
zone transfers.
There are circumstances when a relative expiry time would be
convenient due to limited resources for clock synchronization in
constrained devices. In this case, DNS UPDATE messages should not
contain precomputed TIMEOUT records but convey the relative expiry
time using the EDNS(0) Update Lease Option defined in
[I-D.sekar-dns-ul]. The relative time is then converted to an
absolute expiry time when received by the primary server which will
create the TIMEOUT resource records.
Pusateri & Wattenberg Expires 25 November 2020 [Page 8]
Internet-Draft TIMEOUT Resource Record May 2020
6. TIMEOUT RDATA Wire Format
The TIMEOUT resource record follows the same pattern as other DNS
resource records including owner name, type, class, TTL, RDATA
length, and RDATA as defined in [RFC1035], Section 3.2.1.
The RDATA section of the resource record with method identifier NO
METHOD (0) 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Represented RR Type | Count (0) | Method (0) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Expiry Time (64-bit) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: Method (0) RDATA Wire Format
Figure 1 represents the TIMEOUT RDATA field of all matching records
of the represented type for the same owner name and class.
The RDATA section of the resource record with method identifier MD-
SHA256-128 (1) is illustrated in Figure 2:
Pusateri & Wattenberg Expires 25 November 2020 [Page 9]
Internet-Draft TIMEOUT Resource Record May 2020
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Represented RR Type | Count (n) | Method (1) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Expiry Time (64-bit) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| First 128 bits of SHA256 hash |
| of Represented Record 1 RDATA |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| First 128 bits of SHA256 hash |
| of Represented Record n RDATA |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: Method (1) MD-SHA256-128 Wire Format
Figure 2 represents an arbitrary number of represented records with
the same owner name, class, and represented type. For each expiry
time, a list of the first 128-bits of a SHA256 hash are appended.
7. Server Behavior
A server may or may not understand TIMEOUT resource records. If a
server does not understand them, they are treated like any other
resource record that the server may not understand. See [RFC3597]
for more information.
7.1. Primary Server Behavior
The primary server is the ultimate source of the database and
policies established by the server may overrule the actions of
external clients. The primary server is ultimately responsible for
ensuring the database is consistent but until TIMEOUT record
management is built-in to authoritative server software, external
UPDATE clients will likely manage the records.
Pusateri & Wattenberg Expires 25 November 2020 [Page 10]
Internet-Draft TIMEOUT Resource Record May 2020
Upon receiving any DNS UPDATE deleting resource records that might
have been covered by a TIMEOUT RR, a primary server MUST remove all
represented records in all of the TIMEOUT records with the same owner
name, class, and represented type.
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.
The TIMEOUT record TTL should use the default TTL for the zone like
any other record. The TTL values of the records covered by a TIMEOUT
are not affected by the TIMEOUT expiry time and may be longer than
the expiry time. 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.
7.2. Secondary Server Behavior
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.
8. TIMEOUT RDATA Presentation Format
Record Type:
resource record type mnemonics. When the mnemonic is unknown,
the TYPE is represented by the word "TYPE" immediately followed
by the decimal RR type number, with no intervening whitespace
as described in [RFC3597], Section 5
Represented Record Count:
unsigned decimal integer (0-255)
Method Identifier:
unsigned decimal integer (0-255)
Expiry Time:
The Expiry Time is displayed as a compact numeric-only
representation of ISO 8601. All punctuation is removed. This
form is slightly different than the recommendation in [RFC3339]
but is common for DNS protocols. It is defined in [RFC4034],
Section 3.2 as YYYYMMDDHHmmSS in UTC. This form will always be
exactly 14 digits since no component is optional.
Pusateri & Wattenberg Expires 25 November 2020 [Page 11]
Internet-Draft TIMEOUT Resource Record May 2020
YYYY is the year;
MM is the month number (01-12);
DD is the day of the month (01-31);
HH is the hour, in 24 hour notation (00-23);
mm is the minute (00-59); and
SS is the second (00-60) where 60 is only possible as a leap
second.
List of 0 or more hashes depending on Method Identifier:
( hash-1 hash2 ... )
hash values shown as upper case hexadecimal string;
some type of white space MUST exist between hash values but
MUST NOT exist within hash value;
MUST only display parentheses for one or more hash values;
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.
+---------+-------+----------------------------+------------+
| Type | Value | Meaning | Definition |
+=========+=======+============================+============+
| TIMEOUT | TBA | expire represented records | Section 5 |
+---------+-------+----------------------------+------------+
Table 1: DNS Parameters Resource Record Registry
This document establishes a new registry of DNS TIMEOUT Resource
Record Method Identifier values. The registry shall include a
numeric identifier, a method name, a description of the method, and
the length of the output function in bits or the keyword "variable".
The identifier is to be used in the RDATA section of the TIMEOUT
resource record.
Initially, there are two values defined in the registry. Values from
240 (0xF0) through 255 (0xFF) are reserved for experimental use.
Pusateri & Wattenberg Expires 25 November 2020 [Page 12]
Internet-Draft TIMEOUT Resource Record May 2020
+---------+---------------+----------------+----------+------------+
| ID | Method Name | Description | Length | Definition |
| | | | (bits) | |
+=========+===============+================+==========+============+
| 0 | NO METHOD | All records | 0 | Section |
| | | match | | 5.3.1 |
+---------+---------------+----------------+----------+------------+
| 1 | MD-SHA256-128 | List of | 128 bits | Section |
| | | 128-bit hashes | | 5.3.2 |
| | | of represented | | |
| | | records RDATA | | |
+---------+---------------+----------------+----------+------------+
| 240-255 | EXPERIMENTAL | Reserved for | variable | Section 9 |
| | | Experimental | | |
| | | Use | | |
+---------+---------------+----------------+----------+------------+
Table 2: TIMEOUT RR Method Identifier values
10. Security Considerations
There is no secure relationship between a TIMEOUT resource record and
the represented resource records it applies to. TIMEOUT records
should typically only apply to resource records created through the
UPDATE mechanism. Protection for permanent resource records in a
zone is advisable.
Authenticated UPDATE operations MUST be REQUIRED at authoritative
name servers supporting TIMEOUT resource records.
11. Acknowledgments
This idea was motivated through conversations with Mark Andrews.
Thanks to Mark as well as Paul Vixie, Joe Abley, Ted Lemon, Tony
Finch, Robert Story, Paul Wouters, Dick Franks, JINMEI, Tatuya,
Timothe Litt, and Stuart Cheshire for their suggestions, review, and
comments.
12. References
12.1. Normative References
[FIPS180-4]
National Institute of Standards and Technology, U.S.
Department of Commerce, "Secure Hash Standard (SHS) FIPS
180-4", August 2015,
<http://nvlpubs.nist.gov/nistpubs/FIPS/
NIST.FIPS.180-4.pdf>.
Pusateri & Wattenberg Expires 25 November 2020 [Page 13]
Internet-Draft TIMEOUT Resource Record May 2020
[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>.
[RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "Resource Records for the DNS Security Extensions",
RFC 4034, DOI 10.17487/RFC4034, March 2005,
<https://www.rfc-editor.org/info/rfc4034>.
[RFC6895] Eastlake 3rd, D., "Domain Name System (DNS) IANA
Considerations", BCP 42, RFC 6895, DOI 10.17487/RFC6895,
April 2013, <https://www.rfc-editor.org/info/rfc6895>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
12.2. Informative References
[I-D.sekar-dns-ul]
Cheshire, S. and T. Lemon, "Dynamic DNS Update Leases",
Work in Progress, Internet-Draft, draft-sekar-dns-ul-02, 2
August 2018,
<https://tools.ietf.org/html/draft-sekar-dns-ul-02>.
[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>.
Pusateri & Wattenberg Expires 25 November 2020 [Page 14]
Internet-Draft TIMEOUT Resource Record May 2020
[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>.
[RFC6698] Hoffman, P. and J. Schlyter, "The DNS-Based Authentication
of Named Entities (DANE) Transport Layer Security (TLS)
Protocol: TLSA", RFC 6698, DOI 10.17487/RFC6698, August
2012, <https://www.rfc-editor.org/info/rfc6698>.
[RFC6763] Cheshire, S. and M. Krochmal, "DNS-Based Service
Discovery", RFC 6763, DOI 10.17487/RFC6763, February 2013,
<https://www.rfc-editor.org/info/rfc6763>.
[RFC8555] Barnes, R., Hoffman-Andrews, J., McCarney, D., and J.
Kasten, "Automatic Certificate Management Environment
(ACME)", RFC 8555, DOI 10.17487/RFC8555, March 2019,
<https://www.rfc-editor.org/info/rfc8555>.
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:
+---------------------------------------------+----+----------------+
| Name | RR | Value |
| |Type| |
+=============================================+====+================+
| s.example.com. | A | 192.0.2.5 |
+---------------------------------------------+----+----------------+
| s.example.com. |AAAA| 2001:db8::5 |
+---------------------------------------------+----+----------------+
| 5.2.0.192.in-addr.arpa. |PTR | s.example.com. |
+---------------------------------------------+----+----------------+
| 5.0.0.0.0.0.0.0.0.0.0.0.b8.d.1.20.ip6.arpa. |PTR | s.example.com. |
+---------------------------------------------+----+----------------+
Table 3: Example Address Records Update
Next, consider the TIMEOUT resource records that would be generated
for the records in Table 3.
Pusateri & Wattenberg Expires 25 November 2020 [Page 15]
Internet-Draft TIMEOUT Resource Record May 2020
+---------------------------------------------+----+---+---+--------+
| Owner Name |Type|Cnt|Mth| Expire |
+=============================================+====+===+===+========+
| s.example.com. | A | 0 | 0 | Tn+Ln |
+---------------------------------------------+----+---+---+--------+
| s.example.com. |AAAA| 0 | 0 | Tn+Ln |
+---------------------------------------------+----+---+---+--------+
| 5.2.0.192.in-addr.arpa. |PTR | 0 | 0 | Tn+Ln |
+---------------------------------------------+----+---+---+--------+
| 5.0.0.0.0.0.0.0.0.0.0.0.b8.d.1.20.ip6.arpa. |PTR | 0 | 0 | Tn+Ln |
+---------------------------------------------+----+---+---+--------+
Table 4: Address TIMEOUT records
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.
+---------------------------+---------+---------------------------+
| Owner name | RR Type | Value |
+===========================+=========+===========================+
| _ipp._tcp.example.com. | PTR | p1._ipp._tcp.example.com. |
+---------------------------+---------+---------------------------+
| p1._ipp._tcp.example.com. | SRV | 0 0 631 p1.example.com. |
+---------------------------+---------+---------------------------+
| p1._ipp._tcp.example.com. | TXT | paper=A4 |
+---------------------------+---------+---------------------------+
| p1.example.com. | A | 192.0.2.1 |
+---------------------------+---------+---------------------------+
| p1.example.com. | AAAA | 2001:db8::1 |
+---------------------------+---------+---------------------------+
Table 5: DNS UPDATE from Host A
Pusateri & Wattenberg Expires 25 November 2020 [Page 16]
Internet-Draft TIMEOUT Resource Record May 2020
+---------------------------+---------+---------------------------+
| Owner name | RR Type | Value |
+===========================+=========+===========================+
| _ipp._tcp.example.com. | PTR | p2._ipp._tcp.example.com. |
+---------------------------+---------+---------------------------+
| p2._ipp._tcp.example.com. | SRV | 0 0 631 p2.example.com. |
+---------------------------+---------+---------------------------+
| p2._ipp._tcp.example.com. | TXT | paper=B4 |
+---------------------------+---------+---------------------------+
| p2.example.com. | A | 192.0.2.2 |
+---------------------------+---------+---------------------------+
Table 6: DNS UPDATE from Host B
For these printer registrations, the TIMEOUT records on the server
would look like the following:
+-------------------------+----+-+-+--------------------------------+
| Owner Name |Type|C|M| Expire / Hash |
+=========================+====+=+=+================================+
| _ipp.tcp.example.com. |PTR |1|1| Ta+La |
| | | | |69D67BCB98E8809702B9DFCA6B865558|
+-------------------------+----+-+-+--------------------------------+
| _ipp.tcp.example.com. |PTR |1|1| Tb+Lb |
| | | | |7EBE34BC8B3E7306F8FCF1D6805331E1|
+-------------------------+----+-+-+--------------------------------+
|p1._ipp._tcp.example.com.|SRV |0|0| Ta + La |
+-------------------------+----+-+-+--------------------------------+
|p1._ipp._tcp.example.com.|TXT |0|0| Ta + La |
+-------------------------+----+-+-+--------------------------------+
|p2._ipp._tcp.example.com.|SRV |0|0| Tb + Lb |
+-------------------------+----+-+-+--------------------------------+
|p2._ipp._tcp.example.com.|TXT |0|0| Tb + Lb |
+-------------------------+----+-+-+--------------------------------+
| p1.example.com. | A |0|0| Ta + La |
+-------------------------+----+-+-+--------------------------------+
| p1.example.com. |AAAA|0|0| Ta + La |
+-------------------------+----+-+-+--------------------------------+
| p2.example.com. | A |0|0| Tb + Lb |
+-------------------------+----+-+-+--------------------------------+
Table 7: Service TIMEOUT records
Authors' Addresses
Pusateri & Wattenberg Expires 25 November 2020 [Page 17]
Internet-Draft TIMEOUT Resource Record May 2020
Tom Pusateri
Unaffiliated
Raleigh, NC
United States of America
Email: pusateri@bangj.com
Tim Wattenberg
Unaffiliated
Cologne
Germany
Email: mail@timwattenberg.de
Pusateri & Wattenberg Expires 25 November 2020 [Page 18]
