[Docs] [txt|pdf|xml|html] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02

Internet Engineering Task Force                              T. Pusateri
Internet-Draft                                             T. Wattenberg
Intended status: Standards Track                            Unaffiliated
Expires: August 22, 2019                               February 18, 2019


                      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




Pusateri & Wattenberg    Expires August 22, 2019                [Page 1]


Internet-Draft           TIMEOUT Resource Record           February 2019


   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

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

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.






Pusateri & Wattenberg    Expires August 22, 2019                [Page 2]


Internet-Draft           TIMEOUT Resource Record           February 2019


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



Pusateri & Wattenberg    Expires August 22, 2019                [Page 3]


Internet-Draft           TIMEOUT Resource Record           February 2019


   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



Pusateri & Wattenberg    Expires August 22, 2019                [Page 4]


Internet-Draft           TIMEOUT Resource Record           February 2019


   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.








Pusateri & Wattenberg    Expires August 22, 2019                [Page 5]


Internet-Draft           TIMEOUT Resource Record           February 2019


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:
































Pusateri & Wattenberg    Expires August 22, 2019                [Page 6]


Internet-Draft           TIMEOUT Resource Record           February 2019


      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



Pusateri & Wattenberg    Expires August 22, 2019                [Page 7]


Internet-Draft           TIMEOUT Resource Record           February 2019


   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



Pusateri & Wattenberg    Expires August 22, 2019                [Page 8]


Internet-Draft           TIMEOUT Resource Record           February 2019


   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.

      +-------+----------+-----------+---------------+-------------+
      | Index | Name     | Algorithm | Length (bits) | Definition  |
      +-------+----------+-----------+---------------+-------------+
      |   0   | NOHASH   |           |       0       | Section 4.3 |
      |   1   | SHAKE128 | SHAKE128  |      128      | Section 5.1 |
      +-------+----------+-----------+---------------+-------------+

              Table 1: TIMEOUT RR Hash Algorithm Index values

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.




Pusateri & Wattenberg    Expires August 22, 2019                [Page 9]


Internet-Draft           TIMEOUT Resource Record           February 2019


13.  References

13.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>.

   [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>.

   [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>.

13.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>.




Pusateri & Wattenberg    Expires August 22, 2019               [Page 10]


Internet-Draft           TIMEOUT Resource Record           February 2019


   [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>.

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 |                   |
   +----------------------------------------+------+-------------------+
   | name.example.com.                      | A    | 192.0.2.5         |
   | name.example.com.                      | AAAA | 12001:db8::5      |
   | 5.2.0.192.in-addr.arpa.                | PTR  | name.example.com. |
   | 5.0.0.0.0.0.0.0.0.0.0.0.b8.0d.01.20.ip | PTR  | name.example.com. |
   | 6.arpa. (bytes)                        |      |                   |
   +----------------------------------------+------+-------------------+

                  Table 2: Example Address Records Update

   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:

   +---------------------------------+------+-------+-----+------------+
   | Owner Name                      | For  | Count | Alg | Expiration |
   |                                 | Type |       |     |            |
   +---------------------------------+------+-------+-----+------------+
   | name.example.com.               | A    | 0     | 0   | Tn + Ln    |
   | name.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.0d.0 | PTR  | 0     | 0   | Tn + Ln    |
   | 1.20.ip6.arpa. (bytes)          |      |       |     |            |
   +---------------------------------+------+-------+-----+------------+

                     Table 3: Address TIMEOUT records



Pusateri & Wattenberg    Expires August 22, 2019               [Page 11]


Internet-Draft           TIMEOUT Resource Record           February 2019


   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   | Value                     |
   |                                | Type |                           |
   +--------------------------------+------+---------------------------+
   | _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 4: DNS UPDATE from Host A

   +--------------------------------+------+---------------------------+
   | Owner name                     | RR   | Value                     |
   |                                | Type |                           |
   +--------------------------------+------+---------------------------+
   | _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 5: DNS UPDATE from Host B

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
















Pusateri & Wattenberg    Expires August 22, 2019               [Page 12]


Internet-Draft           TIMEOUT Resource Record           February 2019


   +---------------------------+------+-------+-----+------------------+
   | Owner Name                | For  | Count | Alg | Expire /         |
   |                           | Type |       |     | Hash List        |
   +---------------------------+------+-------+-----+------------------+
   | _ipp.tcp.example.com.     | PTR  | 1     | 1   | Ta + La          |
   |                           |      |       |     | 7ba17d11f8d96bb5 |
   |                           |      |       |     | 4b7ca675bebaf1b6 |
   |                           |      | 1     | 1   | Tb + Lb          |
   |                           |      |       |     | 644685a489ad3bd4 |
   |                           |      |       |     | 350c1230c7643745 |
   | 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 6: Service TIMEOUT records

Authors' Addresses

   Tom Pusateri
   Unaffiliated
   Raleigh, NC
   USA

   Email: pusateri@bangj.com


   Tim Wattenberg
   Unaffiliated
   Cologne
   Germany

   Email: mail@timwattenberg.de














Pusateri & Wattenberg    Expires August 22, 2019               [Page 13]


Html markup produced by rfcmarkup 1.129c, available from https://tools.ietf.org/tools/rfcmarkup/