< draft-pusateri-dnsop-update-timeout-02.txt   draft-pusateri-dnsop-update-timeout-03.txt >
Internet Engineering Task Force T. Pusateri Internet Engineering Task Force T. Pusateri
Internet-Draft T. Wattenberg Internet-Draft T. Wattenberg
Intended status: Standards Track Unaffiliated Intended status: Standards Track Unaffiliated
Expires: September 5, 2019 March 4, 2019 Expires: January 7, 2020 July 6, 2019
DNS TIMEOUT Resource Record DNS TIMEOUT Resource Record
draft-pusateri-dnsop-update-timeout-02 draft-pusateri-dnsop-update-timeout-03
Abstract Abstract
This specification defines a new DNS TIMEOUT resource record (RR) This specification defines a new DNS TIMEOUT resource record (RR)
that associates a lifetime with one or more zone resource records 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 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 to transfer resource record lifetime state between a zone's primary
and secondary servers and to store lifetime state during server and secondary servers and to store lifetime state during server
software restarts. software restarts.
skipping to change at page 1, line 35 skipping to change at page 1, line 35
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on September 5, 2019. This Internet-Draft will expire on January 7, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2019 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 12 skipping to change at page 2, line 12
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3
3. Sources of TIMEOUT Expiry Time . . . . . . . . . . . . . . . 3 3. Sources of TIMEOUT Expiry Time . . . . . . . . . . . . . . . 3
4. Resource Record Composition . . . . . . . . . . . . . . . . . 3 4. Resource Record Composition . . . . . . . . . . . . . . . . . 4
4.1. Represented Record Type . . . . . . . . . . . . . . . . . 4 4.1. Represented Record Type . . . . . . . . . . . . . . . . . 4
4.2. Represented Record Count . . . . . . . . . . . . . . . . 4 4.2. Represented Record Count . . . . . . . . . . . . . . . . 4
4.3. Method Identifiers . . . . . . . . . . . . . . . . . . . 4 4.3. Method Identifiers . . . . . . . . . . . . . . . . . . . 5
4.3.1. Method Identifier 0: NO METHOD . . . . . . . . . . . 5 4.3.1. Method Identifier 0: NO METHOD . . . . . . . . . . . 5
4.3.2. Method Identifier 1: RDATA . . . . . . . . . . . . . 5 4.3.2. Method Identifier 1: RDATA . . . . . . . . . . . . . 5
4.4. Expiry Time . . . . . . . . . . . . . . . . . . . . . . . 5 4.4. Expiry Time . . . . . . . . . . . . . . . . . . . . . . . 6
5. TIMEOUT RDATA Wire Format . . . . . . . . . . . . . . . . . . 5 5. TIMEOUT RDATA Wire Format . . . . . . . . . . . . . . . . . . 6
6. Primary Server Behavior . . . . . . . . . . . . . . . . . . . 7 6. Primary Server Behavior . . . . . . . . . . . . . . . . . . . 7
7. Secondary Server Behavior . . . . . . . . . . . . . . . . . . 7 7. Secondary Server Behavior . . . . . . . . . . . . . . . . . . 8
8. TIMEOUT RDATA Presentation Format . . . . . . . . . . . . . . 7 8. TIMEOUT RDATA Presentation Format . . . . . . . . . . . . . . 8
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
10. Security Considerations . . . . . . . . . . . . . . . . . . . 9 10. Security Considerations . . . . . . . . . . . . . . . . . . . 9
11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 9 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 10
12.1. Normative References . . . . . . . . . . . . . . . . . . 10 12.1. Normative References . . . . . . . . . . . . . . . . . . 10
12.2. Informative References . . . . . . . . . . . . . . . . . 10 12.2. Informative References . . . . . . . . . . . . . . . . . 10
Appendix A. Example TIMEOUT resource records . . . . . . . . . . 11 Appendix A. Example TIMEOUT resource records . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13
1. Introduction 1. Introduction
DNS Update [RFC2136] provides a mechanism to dynamically add/remove DNS Update [RFC2136] provides a mechanism to dynamically add/remove
DNS resource records to/from a zone. When a resource record is DNS resource records to/from a zone. When a resource record is
dynamically added, it remains in the zone until it is removed dynamically added, it remains in the zone until it is removed
manually or via a subsequent DNS Update. A zone administrator may manually or via a subsequent DNS Update. The context of a dynamic
want to enforce a default lifetime for dynamic updates (such as the update may provide lifetime hints for the updated records (such as
DHCP lease lifetime) or the DNS Update may contain a lifetime using the EDNS(0) Update Lease option [I-D.sekar-dns-ul]), however, this
an EDNS(0) Update Lease option [I-D.sekar-dns-ul]. However, this lifetime is not communicated to secondary servers and will not endure
lease lifetime is not communicated to secondary servers and will not through server software restarts. This specification defines a new
endure through server software restarts. Therefore, this DNS TIMEOUT resource record that associates lifetimes with one or
specification defines a new DNS TIMEOUT resource record that more resource records with the same owner name, type, and class that
associates a lifetime with one or more resource records with the same can be transferred to secondary servers through normal AXFR
owner name, type, and class that can be transferred to secondary [RFC5936], IXFR [RFC1995] transfer mechanisms.
servers through normal AXFR [RFC5936], IXFR [RFC1995] transfer
mechanisms.
An UPDATE lifetime could be stored in a proprietary database on an An UPDATE lifetime could be stored in a proprietary database on an
authoritative primary server but there is an advantage to saving it authoritative primary server but there is an advantage to saving it
as a resource record: redundant master servers and secondary servers as a resource record: redundant master servers and secondary servers
capable of taking over as the primary server for a zone automatically capable of taking over as the primary server for a zone automatically
can benefit from the existing database synchronization of resource can benefit from the existing database synchronization of resource
records. In addition, primary and secondary servers from multiple records. In addition, primary and secondary servers from multiple
vendors can synchronize the lifetimes through the open format vendors can synchronize the lifetimes through the open format
provided by a resource record. 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 lease 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, and DNS TXT validation resource records
supporting ACME certificate management as described in Section 8.4 of
[RFC8555].
2. Requirements Language 2. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP "OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. These words may also appear in this capitals, as shown here. These words may also appear in this
document in lower case as plain English words, absent their normative document in lower case as plain English words, absent their normative
meanings. meanings.
3. Sources of TIMEOUT Expiry Time 3. Sources of TIMEOUT Expiry Time
The expire time may come from many different sources. A few are The expire time may come from many different sources. A few are
listed here however, this list is not considered complete. 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.
1. Via DHCP Dynamic Lease Lifetime communicated out of band. 1. Via DHCP Dynamic Lease Lifetimes.
2. Via EDNS(0) Update Lease option [I-D.sekar-dns-ul] communicated 2. Via EDNS(0) Update Lease option [I-D.sekar-dns-ul] communicated
in DNS Update. in DNS Update.
3. Via an administrative default server value such as one day (86400 3. Via an administrative default value such as one day (86400
seconds). seconds).
4. Resource Record Composition 4. Resource Record Composition
TIMEOUT resource records provide expiry times for a mixed variety of TIMEOUT resource records provide expiry times for a mixed variety of
resource record types with the same owner name, type, and class. resource record types with the same owner name, type, and class.
Since there could exist multiple records of the same record type with Since there could exist multiple records of the same record type with
the same owner name and class, the TIMEOUT resource record must be the same owner name and class, the TIMEOUT resource record must be
able to identify each of these records individually with only able to identify each of these records individually with only
different RDATA. As an example, PTR records for service discovery different RDATA. As an example, PTR records for service discovery
skipping to change at page 4, line 6 skipping to change at page 4, line 29
RDATA often exist. RDATA often exist.
In order to distinguish each individual record with potentially In order to distinguish each individual record with potentially
different expiry times, the TIMEOUT resource record contains an different expiry times, the TIMEOUT resource record contains an
exipry time, the record type, a method to identify the actual records exipry time, the record type, a method to identify the actual records
for which the expiry time applies, and a count of the number of for which the expiry time applies, and a count of the number of
records represented. Multiple TIMEOUT records with the same owner records represented. Multiple TIMEOUT records with the same owner
name and class are created for each expiry time, record type, and name and class are created for each expiry time, record type, and
resource record representation. If the expiry time is the same, resource record representation. If the expiry time is the same,
multiple records can be combined into a single TIMEOUT record with 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 same owner name, class, and record type but this is not required.
The fields and their values in a TIMEOUT record are defined as: The fields and their values in a TIMEOUT record are defined as:
4.1. Represented Record Type 4.1. Represented Record Type
A 16-bit field containing the resource record type to which the A 16-bit field containing the resource record type to which the
TIMEOUT record applies. Multiple TIMEOUT records for the same owner TIMEOUT record applies. Multiple TIMEOUT records for the same owner
name, class, and represented type can exist. 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.
4.2. Represented Record Count 4.2. Represented Record Count
The Represented Record Count is a 8-bit value that specifies the The Represented Record Count is a 8-bit value that specifies the
number of records of the specified record type with this expiry time. number of records of the specified record type with this expiry time.
An RR Count of zero indicates that it is not necessary to represent An RR Count of zero indicates that it is not necessary to represent
any records in the list. This is a shortcut notation meaning all any records in the list. This is a shortcut notation meaning all
resource records with the same owner name, class, and record type use resource records with the same owner name, class, and record type use
the same Expiry Time. There MUST be only one TIMEOUT record for the the same Expiry Time. When the Represented Record Count is 0, the
same owner name, class, and record type if the Represented Record Method Identifer is set to NO METHOD (0) on transmission and ignored
Count is zero. If an additional TIMEOUT record exists with the same on reception.
owner name, class, and record type, it MUST be ignored and SHOULD be
removed. When the Represented Record Count is 0, the Method
Identifer is set to NO METHOD (0) on transmission and ignored on
reception.
In the unlikely event that the Represented Record Count exceeds 255 In the unlikely event that the Represented Record Count exceeds 255
which is the largest number representable in 8 bits, multiple which is the largest number representable in 8 bits, multiple
instances of the same Expiry Time can exist. instances of the same Expiry Time can exist.
4.3. Method Identifiers 4.3. Method Identifiers
The Method Identifier is a 8-bit value that specifies an identifier The Method Identifier is a 8-bit value that specifies an identifier
for the algorithm used to distinguish between resource records. The for the algorithm used to distinguish between resource records. The
identifiers are declared in a registry maintained by IANA for the identifiers are declared in a registry maintained by IANA for the
skipping to change at page 5, line 28 skipping to change at page 5, line 50
The method identifier of 0 is defined as "NO METHOD" and MUST NOT be 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 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. 0 is to be included in the IANA registry of method identifier values.
4.3.2. Method Identifier 1: RDATA 4.3.2. Method Identifier 1: RDATA
The method identifier of 1 is defined as "RDATA". It begins with the The method identifier of 1 is defined as "RDATA". It begins with the
RDATA length as a 16-bit value containing the length of the RDATA in RDATA length as a 16-bit value containing the length of the RDATA in
bytes followed by the number of bytes of RDATA as appears in the bytes followed by the number of bytes of RDATA as appears in the
record being represented. The record MUST be in canonical DNSSEC record being represented. The record MUST be in canonical DNSSEC
form as described in Section 6 of [RFC4034]. form as described in Section 6 of [RFC4034]. Any comparisons of
RDATA in an actual record covered by the TIMEOUT against the
Represented RDATA contained in a TIMEOUT record must be compared in
canonical form.
4.4. Expiry Time 4.4. Expiry Time
The expiry time is a 64-bit number expressed as the number of seconds 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 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 is an absolute time at which the record will expire. Lease times
must be converted to an absolute expiry time when received. must be converted to an absolute expiry time when received.
5. TIMEOUT RDATA Wire Format 5. TIMEOUT RDATA Wire Format
skipping to change at page 7, line 13 skipping to change at page 7, line 30
Figure 2: Method (0) RDATA Wire Format Figure 2: Method (0) RDATA Wire Format
Figure 2 represents the TIMEOUT RDATA field of all matching records Figure 2 represents the TIMEOUT RDATA field of all matching records
of the represented type for the same owner name and class. of the represented type for the same owner name and class.
6. Primary Server Behavior 6. Primary Server Behavior
A TIMEOUT resource record MUST be removed when the last resource A TIMEOUT resource record MUST be removed when the last resource
record it covers has been removed. This may be due to the record 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 expiring (reaching the expiry time) or due to a subsequent DNS Update
or administrative action. or administrative action. If the TIMEOUT record is being managed by
the primary server, it has the responsibility to remove it. If the
TIMEOUT record was installed by an external UPDATE client, the UPDATE
client has the responsibility to remove it. The primary server is
the ultimate source of the database and policy 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.
Upon receiving any DNS UPDATE deleting resource records that might Upon receiving any DNS UPDATE deleting resource records that might
have been covered by a TIMEOUT RR, a primary server MUST remove all 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 represented records in all of the TIMEOUT records with the same owner
name, class, and represented type. name, class, and represented type.
As a reminder from Section 3.3.13 of [RFC1035], the MINIMUM field of The TIMEOUT record TTL should use the default TTL for the zone like
the SOA for the zone is used as a lower bound of the TTL for all any other record. The TTL values of the records covered by a TIMEOUT
records in the zone. Therefore, even if the TIMEOUT record will are not affected by the TIMEOUT expiry time and may be longer than
expire in less time than the MINIMUM, the TTL is still set to the the expirey time. The TIMEOUT RR is mostly for the benefit of the
MINIMUM for records covered by the TIMEOUT record and the TIMEOUT authoritative server to know when to remove the records. The fact
record itself when a response is returned by an authoritative server. that some records might live longer in the cache of a resolver is no
The TIMEOUT RR is mostly for the benefit of the authoritative server different than other records that might get removed while still in a
to know when to remove the records. The fact that some records might remote resolver cache.
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. Secondary Server Behavior 7. Secondary Server Behavior
A secondary server may or may not understand TIMEOUT resource A secondary server may or may not understand TIMEOUT resource
records. If a secondary server does not understand them, they are records. If a secondary server does not understand them, they are
treated like any other resource record that the server may not treated like any other resource record that the server may not
understand [RFC3597]. understand [RFC3597].
A secondary server MUST NOT expire the records in a zone it maintains 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 covered by the TIMEOUT resource record and it MUST NOT expire the
skipping to change at page 8, line 21 skipping to change at page 8, line 47
form is slightly different than the recommendation in [RFC3339] form is slightly different than the recommendation in [RFC3339]
but is common for DNS protocols. It is defined in Section 3.2 but is common for DNS protocols. It is defined in Section 3.2
of [RFC4034] as YYYYMMDDHHmmSS in UTC. This form will always of [RFC4034] as YYYYMMDDHHmmSS in UTC. This form will always
be exactly 14 digits since no component is optional. be exactly 14 digits since no component is optional.
YYYY is the year; YYYY is the year;
MM is the month number (01-12); MM is the month number (01-12);
DD is the day of the month (01-31); DD is the day of the month (01-31);
HH is the hour, in 24 hour notation (00-23); HH is the hour, in 24 hour notation (00-23);
mm is the minute (00-59); and mm is the minute (00-59); and
SS is the second (00-59). SS is the second (00-60) where 60 is only possible as a leap
second.
RDATA Length: RDATA Length:
unsigned decimal integer unsigned decimal integer
RDATA: RDATA:
record type specific record type specific
9. IANA Considerations 9. IANA Considerations
This document defines a new DNS Resource Record Type named TIMEOUT to This document defines a new DNS Resource Record Type named TIMEOUT to
skipping to change at page 9, line 19 skipping to change at page 9, line 22
It is assigned out of the DNS Parameters Resource Record (RR) Type It is assigned out of the DNS Parameters Resource Record (RR) Type
registry. The value for the TIMEOUT resource record type is TBA. registry. The value for the TIMEOUT resource record type is TBA.
This document establishes a new registry of DNS TIMEOUT Resource This document establishes a new registry of DNS TIMEOUT Resource
Record Method Identifier values. The registry shall include a Record Method Identifier values. The registry shall include a
numeric identifier, a method name, a description of the method, and numeric identifier, a method name, a description of the method, and
the length of the output function in bits or the keyword "variable". 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 The identifier is to be used in the RDATA section of the TIMEOUT
resource record. resource record.
+-------+------------+----------------+-------------+---------------+ Initially, there are two values defined in the registry. Values from
| ID | Method | Description | Length | Definition | 240 (0xF0) through 255 (0xFF) are reserved for experimental use.
| | Name | | (bits) | |
+-------+------------+----------------+-------------+---------------+ +---------+--------------+---------------+----------+---------------+
| 0 | NO METHOD | All records | 0 | Section 4.3.1 | | ID | Method Name | Description | Length | Definition |
| | | match | | | | | | | (bits) | |
| 1 | RDATA | Actual RDATA | variable | Section 4.3.2 | +---------+--------------+---------------+----------+---------------+
| | | of represented | | | | 0 | NO METHOD | All records | 0 | Section 4.3.1 |
| | | records | | | | | | match | | |
+-------+------------+----------------+-------------+---------------+ | 1 | RDATA | Actual RDATA | variable | Section 4.3.2 |
| | | of | | |
| | | represented | | |
| | | records | | |
| 240-255 | EXPERIMENTAL | Reserved for | variable | Section 9 |
| | | Experimental | | |
| | | Use | | |
+---------+--------------+---------------+----------+---------------+
Table 1: TIMEOUT RR Method Identifier values Table 1: TIMEOUT RR Method Identifier values
10. Security Considerations 10. Security Considerations
There is no secure relationship between a TIMEOUT resource record and There is no secure relationship between a TIMEOUT resource record and
the represented resource records it applies to. TIMEOUT records the represented resource records it applies to. TIMEOUT records
should typically only apply to resource records created through the should typically only apply to resource records created through the
UPDATE mechanism. Protection for permanent resource records in a UPDATE mechanism. Protection for permanent resource records in a
zone is advisable. zone is advisable.
Authenticated UPDATE operations MUST be REQUIRED at authoritative Authenticated UPDATE operations MUST be REQUIRED at authoritative
name servers supporting TIMEOUT resource records. name servers supporting TIMEOUT resource records.
11. Acknowledgments 11. Acknowledgments
This idea was motivated through conversations with Mark Andrews. This idea was motivated through conversations with Mark Andrews.
Thanks to Mark as well as Paul Vixie, Joe Abley, Ted Lemon, Tony Thanks to Mark as well as Paul Vixie, Joe Abley, Ted Lemon, Tony
Finch, Robert Story, Paul Wouters, and Dick Franks for their Finch, Robert Story, Paul Wouters, Dick Franks, JINMEI, Tatuya, and
suggestions, review, and comments. Timothe Litt for their suggestions, review, and comments.
12. References 12. References
12.1. Normative References 12.1. Normative References
[RFC1035] Mockapetris, P., "Domain names - implementation and [RFC1035] Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, specification", STD 13, RFC 1035, DOI 10.17487/RFC1035,
November 1987, <https://www.rfc-editor.org/info/rfc1035>. November 1987, <https://www.rfc-editor.org/info/rfc1035>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
skipping to change at page 11, line 9 skipping to change at page 11, line 18
<https://www.rfc-editor.org/info/rfc2136>. <https://www.rfc-editor.org/info/rfc2136>.
[RFC5936] Lewis, E. and A. Hoenes, Ed., "DNS Zone Transfer Protocol [RFC5936] Lewis, E. and A. Hoenes, Ed., "DNS Zone Transfer Protocol
(AXFR)", RFC 5936, DOI 10.17487/RFC5936, June 2010, (AXFR)", RFC 5936, DOI 10.17487/RFC5936, June 2010,
<https://www.rfc-editor.org/info/rfc5936>. <https://www.rfc-editor.org/info/rfc5936>.
[RFC6763] Cheshire, S. and M. Krochmal, "DNS-Based Service [RFC6763] Cheshire, S. and M. Krochmal, "DNS-Based Service
Discovery", RFC 6763, DOI 10.17487/RFC6763, February 2013, Discovery", RFC 6763, DOI 10.17487/RFC6763, February 2013,
<https://www.rfc-editor.org/info/rfc6763>. <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 Appendix A. Example TIMEOUT resource records
The following example shows sample TIMEOUT resource records based on The following example shows sample TIMEOUT resource records based on
DNS UPDATEs containing A and AAAA address records plus the DNS UPDATEs containing A and AAAA address records plus the
corresponding PTR records. corresponding PTR records.
A host sending a name registration at time Tn for "A" and "AAAA" 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 records with lease lifetime Ln would have a series of UPDATEs (one
for each zone) that contain: for each zone) that contain:
skipping to change at page 11, line 33 skipping to change at page 11, line 47
| s.example.com. | A | 192.0.2.5 | | s.example.com. | A | 192.0.2.5 |
| s.example.com. | AAAA | 12001:db8::5 | | s.example.com. | AAAA | 12001:db8::5 |
| 5.2.0.192.in-addr.arpa. | PTR | s.example.com. | | 5.2.0.192.in-addr.arpa. | PTR | s.example.com. |
| 5.0.0.0.0.0.0.0.0.0.0.0.b8.0d.01.20.ip6.a | PTR | s.example.com. | | 5.0.0.0.0.0.0.0.0.0.0.0.b8.0d.01.20.ip6.a | PTR | s.example.com. |
| rpa. (bytes) | | | | rpa. (bytes) | | |
+-------------------------------------------+------+----------------+ +-------------------------------------------+------+----------------+
Table 2: Example Address Records Update Table 2: Example Address Records Update
Next, consider the TIMEOUT resource records that would be generated Next, consider the TIMEOUT resource records that would be generated
for the records in Table 2. Notice that none of the 4 TIMEOUT for the records in Table 2.
records on the server would require a hash:
+------------------------------+------+-------+--------+------------+ +------------------------------+------+-------+--------+------------+
| Owner Name | For | Count | Method | Expiration | | Owner Name | For | Count | Method | Expiration |
| | Type | | | | | | Type | | | |
+------------------------------+------+-------+--------+------------+ +------------------------------+------+-------+--------+------------+
| s.example.com. | A | 0 | 0 | Tn + Ln | | s.example.com. | A | 0 | 0 | Tn + Ln |
| s.example.com. | AAAA | 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.2.0.192.in-addr.arpa. | PTR | 0 | 0 | Tn + Ln |
| 5.0.0.0.0.0.0.0.0.0.0.0.b8.0 | PTR | 0 | 0 | Tn + Ln | | 5.0.0.0.0.0.0.0.0.0.0.0.b8.0 | PTR | 0 | 0 | Tn + Ln |
| d.01.20.ip6.arpa. (bytes) | | | | | | d.01.20.ip6.arpa. (bytes) | | | | |
 End of changes. 24 change blocks. 
61 lines changed or deleted 105 lines changed or added

This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/