idnits 2.17.1 draft-pusateri-dnsop-update-timeout-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 2 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. == There are 1 instance of lines with non-RFC3849-compliant IPv6 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 6, 2019) is 1749 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-03) exists of draft-sekar-dns-ul-02 Summary: 0 errors (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force T. Pusateri 3 Internet-Draft T. Wattenberg 4 Intended status: Standards Track Unaffiliated 5 Expires: January 7, 2020 July 6, 2019 7 DNS TIMEOUT Resource Record 8 draft-pusateri-dnsop-update-timeout-03 10 Abstract 12 This specification defines a new DNS TIMEOUT resource record (RR) 13 that associates a lifetime with one or more zone resource records 14 with the same owner name, type, and class. It is intended to be used 15 to transfer resource record lifetime state between a zone's primary 16 and secondary servers and to store lifetime state during server 17 software restarts. 19 Status of This Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at https://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on January 7, 2020. 36 Copyright Notice 38 Copyright (c) 2019 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (https://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 54 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3 55 3. Sources of TIMEOUT Expiry Time . . . . . . . . . . . . . . . 3 56 4. Resource Record Composition . . . . . . . . . . . . . . . . . 4 57 4.1. Represented Record Type . . . . . . . . . . . . . . . . . 4 58 4.2. Represented Record Count . . . . . . . . . . . . . . . . 4 59 4.3. Method Identifiers . . . . . . . . . . . . . . . . . . . 5 60 4.3.1. Method Identifier 0: NO METHOD . . . . . . . . . . . 5 61 4.3.2. Method Identifier 1: RDATA . . . . . . . . . . . . . 5 62 4.4. Expiry Time . . . . . . . . . . . . . . . . . . . . . . . 6 63 5. TIMEOUT RDATA Wire Format . . . . . . . . . . . . . . . . . . 6 64 6. Primary Server Behavior . . . . . . . . . . . . . . . . . . . 7 65 7. Secondary Server Behavior . . . . . . . . . . . . . . . . . . 8 66 8. TIMEOUT RDATA Presentation Format . . . . . . . . . . . . . . 8 67 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 68 10. Security Considerations . . . . . . . . . . . . . . . . . . . 9 69 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10 70 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 71 12.1. Normative References . . . . . . . . . . . . . . . . . . 10 72 12.2. Informative References . . . . . . . . . . . . . . . . . 10 73 Appendix A. Example TIMEOUT resource records . . . . . . . . . . 11 74 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 76 1. Introduction 78 DNS Update [RFC2136] provides a mechanism to dynamically add/remove 79 DNS resource records to/from a zone. When a resource record is 80 dynamically added, it remains in the zone until it is removed 81 manually or via a subsequent DNS Update. The context of a dynamic 82 update may provide lifetime hints for the updated records (such as 83 the EDNS(0) Update Lease option [I-D.sekar-dns-ul]), however, this 84 lifetime is not communicated to secondary servers and will not endure 85 through server software restarts. This specification defines a new 86 DNS TIMEOUT resource record that associates lifetimes with one or 87 more resource records with the same owner name, type, and class that 88 can be transferred to secondary servers through normal AXFR 89 [RFC5936], IXFR [RFC1995] transfer mechanisms. 91 An UPDATE lifetime could be stored in a proprietary database on an 92 authoritative primary server but there is an advantage to saving it 93 as a resource record: redundant master servers and secondary servers 94 capable of taking over as the primary server for a zone automatically 95 can benefit from the existing database synchronization of resource 96 records. In addition, primary and secondary servers from multiple 97 vendors can synchronize the lifetimes through the open format 98 provided by a resource record. 100 TIMEOUT records can be installed via policy by a primary server, 101 manually, or via an external UPDATE from a client. If TIMEOUT 102 records are being managed by an UPDATE client, the client should be 103 aware of server software policy with respect to TIMEOUT records to 104 prevent the TIMEOUT records from being rejected. The primary server 105 has ultimate responsibility for the records in the database and the 106 client must work within the restrictions of the policy of the primary 107 server. 109 TIMEOUT records can be thought of as a universal method for removing 110 stale dynamic DNS records. Clients such as DHCP lease servers who 111 best know the lease lifetimes can include individual TIMEOUT records 112 in the dynamic UPDATE messages specific for each lease lifetime. 113 These TIMEOUT records can be refreshed when the lease is refreshed 114 and will timeout the A, AAAA, and PTR records if they are not 115 refreshed by the DHCP server. Additional use cases include service 116 discovery resource records installed in unicast DNS servers via 117 UPDATE described in [RFC6763], Active Directory Controllers 118 publishing SRV records, and DNS TXT validation resource records 119 supporting ACME certificate management as described in Section 8.4 of 120 [RFC8555]. 122 2. Requirements Language 124 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 125 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 126 "OPTIONAL" in this document are to be interpreted as described in BCP 127 14 [RFC2119] [RFC8174] when, and only when, they appear in all 128 capitals, as shown here. These words may also appear in this 129 document in lower case as plain English words, absent their normative 130 meanings. 132 3. Sources of TIMEOUT Expiry Time 134 The expire time may come from many different sources. A few are 135 listed here however, this list is not considered complete. TIMEOUT 136 records may be included along side the records they represent in the 137 UPDATE message or they be synthesized by the primary server receiving 138 the UPDATE. 140 1. Via DHCP Dynamic Lease Lifetimes. 142 2. Via EDNS(0) Update Lease option [I-D.sekar-dns-ul] communicated 143 in DNS Update. 145 3. Via an administrative default value such as one day (86400 146 seconds). 148 4. Resource Record Composition 150 TIMEOUT resource records provide expiry times for a mixed variety of 151 resource record types with the same owner name, type, and class. 152 Since there could exist multiple records of the same record type with 153 the same owner name and class, the TIMEOUT resource record must be 154 able to identify each of these records individually with only 155 different RDATA. As an example, PTR records for service discovery 156 [RFC6763] provide a level of indirection to SRV and TXT records by 157 instance name. The instance name is stored in the PTR RDATA and 158 multiple PTR records with the same owner name but only differing 159 RDATA often exist. 161 In order to distinguish each individual record with potentially 162 different expiry times, the TIMEOUT resource record contains an 163 exipry time, the record type, a method to identify the actual records 164 for which the expiry time applies, and a count of the number of 165 records represented. Multiple TIMEOUT records with the same owner 166 name and class are created for each expiry time, record type, and 167 resource record representation. If the expiry time is the same, 168 multiple records can be combined into a single TIMEOUT record with 169 the same owner name, class, and record type but this is not required. 171 The fields and their values in a TIMEOUT record are defined as: 173 4.1. Represented Record Type 175 A 16-bit field containing the resource record type to which the 176 TIMEOUT record applies. Multiple TIMEOUT records for the same owner 177 name, class, and represented type can exist. Any resource record 178 type can be specified in the Represented Record Type including 179 another TIMEOUT record. This specification does not put any 180 restrictions on the record type but implementations in authoritative 181 servers will likely do so for policy and security reasons. 183 4.2. Represented Record Count 185 The Represented Record Count is a 8-bit value that specifies the 186 number of records of the specified record type with this expiry time. 188 An RR Count of zero indicates that it is not necessary to represent 189 any records in the list. This is a shortcut notation meaning all 190 resource records with the same owner name, class, and record type use 191 the same Expiry Time. When the Represented Record Count is 0, the 192 Method Identifer is set to NO METHOD (0) on transmission and ignored 193 on reception. 195 In the unlikely event that the Represented Record Count exceeds 255 196 which is the largest number representable in 8 bits, multiple 197 instances of the same Expiry Time can exist. 199 4.3. Method Identifiers 201 The Method Identifier is a 8-bit value that specifies an identifier 202 for the algorithm used to distinguish between resource records. The 203 identifiers are declared in a registry maintained by IANA for the 204 purpose of listing acceptable methods for this purpose. In addition 205 to the method and the index, the registry MAY contain a fixed output 206 length in bits of the method to be used or the term "variable" to 207 denote a variable length output per record. It is conceivable, 208 though not likely, that the same method could be used with different 209 fixed output lengths. In this case, each fixed output length would 210 require a different identifier in the registry. Additions to this 211 registry will be approved with additional documentation under expert 212 review. At the time that the registry is created by IANA, a group of 213 expert reviewers will be established. 215 Additional methods of representing records such as hashes or other 216 algorithms may be defined in the future. If such methods are 217 defined, a primary server could create TIMEOUT record using a new 218 method that is not understood by a secondary server that could take 219 over as the primary in the event of an outage or administrative 220 change. In this case, the new primary would not be able to identify 221 the records it is supposed to TIMEOUT. This is a misconfiguration 222 and it is the responsibility of the administrator to ensure that 223 secondary servers in a position to become primary understand the 224 TIMEOUT record methods of the primary server. 226 4.3.1. Method Identifier 0: NO METHOD 228 The method identifier of 0 is defined as "NO METHOD" and MUST NOT be 229 used if the represented record count is greater than 0. The value of 230 0 is to be included in the IANA registry of method identifier values. 232 4.3.2. Method Identifier 1: RDATA 234 The method identifier of 1 is defined as "RDATA". It begins with the 235 RDATA length as a 16-bit value containing the length of the RDATA in 236 bytes followed by the number of bytes of RDATA as appears in the 237 record being represented. The record MUST be in canonical DNSSEC 238 form as described in Section 6 of [RFC4034]. Any comparisons of 239 RDATA in an actual record covered by the TIMEOUT against the 240 Represented RDATA contained in a TIMEOUT record must be compared in 241 canonical form. 243 4.4. Expiry Time 245 The expiry time is a 64-bit number expressed as the number of seconds 246 since the UNIX epoch (00:00:00 UTC on January 1, 1970). This value 247 is an absolute time at which the record will expire. Lease times 248 must be converted to an absolute expiry time when received. 250 5. TIMEOUT RDATA Wire Format 252 The TIMEOUT resource record follows the same pattern as other DNS 253 resource records as defined in Section 3.2.1 of [RFC1035] including 254 owner name, type, class, TTL, RDATA length, and RDATA. 256 The RDATA section of the resource record with method identifier RDATA 257 (1) is illustrated in Figure 1: 259 0 1 2 3 260 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 261 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 262 | Represented RR Type | Count (n) | Method (1) | 263 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 264 | Expiry Time (64-bit) | 265 | | 266 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 267 . Represented RDATA LEN 1 | . 268 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ . 269 . . 270 . Represented RDATA 1 . 271 . . 272 . . 273 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 274 . Represented RDATA LEN n | . 275 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ . 276 . . 277 . Represented RDATA n . 278 . . 279 . . 280 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 282 Figure 1: Method (1) RDATA Wire Format 284 Figure 1 represents an arbitrary number of represented records with 285 the same owner name, class, and represented type. For each expiry 286 time, a list of RDATA length and RDATA pairs are attached. The 287 overall RDATA length of the TIMEOUT record indicates when the last 288 represented record is contained in the record. 290 The RDATA section of the resource record with method identifier NO 291 METHOD (0) is illustrated in Figure 2: 293 0 1 2 3 294 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 295 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 296 | Represented RR Type | Count (0) | Method (0) | 297 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 298 | Expiry Time (64-bit) | 299 | | 300 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 302 Figure 2: Method (0) RDATA Wire Format 304 Figure 2 represents the TIMEOUT RDATA field of all matching records 305 of the represented type for the same owner name and class. 307 6. Primary Server Behavior 309 A TIMEOUT resource record MUST be removed when the last resource 310 record it covers has been removed. This may be due to the record 311 expiring (reaching the expiry time) or due to a subsequent DNS Update 312 or administrative action. If the TIMEOUT record is being managed by 313 the primary server, it has the responsibility to remove it. If the 314 TIMEOUT record was installed by an external UPDATE client, the UPDATE 315 client has the responsibility to remove it. The primary server is 316 the ultimate source of the database and policy established by the 317 server may overrule the actions of external clients. The primary 318 server is ultimately responsible for ensuring the database is 319 consistent but until TIMEOUT record management is built-in to 320 authoritative server software, external UPDATE clients will likely 321 manage the records. 323 Upon receiving any DNS UPDATE deleting resource records that might 324 have been covered by a TIMEOUT RR, a primary server MUST remove all 325 represented records in all of the TIMEOUT records with the same owner 326 name, class, and represented type. 328 The TIMEOUT record TTL should use the default TTL for the zone like 329 any other record. The TTL values of the records covered by a TIMEOUT 330 are not affected by the TIMEOUT expiry time and may be longer than 331 the expirey time. The TIMEOUT RR is mostly for the benefit of the 332 authoritative server to know when to remove the records. The fact 333 that some records might live longer in the cache of a resolver is no 334 different than other records that might get removed while still in a 335 remote resolver cache. 337 7. Secondary Server Behavior 339 A secondary server may or may not understand TIMEOUT resource 340 records. If a secondary server does not understand them, they are 341 treated like any other resource record that the server may not 342 understand [RFC3597]. 344 A secondary server MUST NOT expire the records in a zone it maintains 345 covered by the TIMEOUT resource record and it MUST NOT expire the 346 TIMEOUT resource record itself when the last record it covers has 347 expired. The secondary server MUST always wait for the records to be 348 removed or updated by the primary server. 350 8. TIMEOUT RDATA Presentation Format 352 Record Type: 353 resource record type mnemonics. When the mnemonic is unknown, 354 the TYPE representation described in Section 5 of [RFC3597] 356 Represented Record Count: 357 unsigned decimal integer (0-255) 359 Method Identifier: 360 unsigned decimal integer (0-255) 362 Expiry Time: 363 The Expiry Time is displayed as a compact numeric-only 364 representation of ISO 8601. All punctuation is removed. This 365 form is slightly different than the recommendation in [RFC3339] 366 but is common for DNS protocols. It is defined in Section 3.2 367 of [RFC4034] as YYYYMMDDHHmmSS in UTC. This form will always 368 be exactly 14 digits since no component is optional. 370 YYYY is the year; 371 MM is the month number (01-12); 372 DD is the day of the month (01-31); 373 HH is the hour, in 24 hour notation (00-23); 374 mm is the minute (00-59); and 375 SS is the second (00-60) where 60 is only possible as a leap 376 second. 378 RDATA Length: 379 unsigned decimal integer 381 RDATA: 382 record type specific 384 9. IANA Considerations 386 This document defines a new DNS Resource Record Type named TIMEOUT to 387 be exchanged between authoritative primary and secondary DNS servers. 388 It is assigned out of the DNS Parameters Resource Record (RR) Type 389 registry. The value for the TIMEOUT resource record type is TBA. 391 This document establishes a new registry of DNS TIMEOUT Resource 392 Record Method Identifier values. The registry shall include a 393 numeric identifier, a method name, a description of the method, and 394 the length of the output function in bits or the keyword "variable". 395 The identifier is to be used in the RDATA section of the TIMEOUT 396 resource record. 398 Initially, there are two values defined in the registry. Values from 399 240 (0xF0) through 255 (0xFF) are reserved for experimental use. 401 +---------+--------------+---------------+----------+---------------+ 402 | ID | Method Name | Description | Length | Definition | 403 | | | | (bits) | | 404 +---------+--------------+---------------+----------+---------------+ 405 | 0 | NO METHOD | All records | 0 | Section 4.3.1 | 406 | | | match | | | 407 | 1 | RDATA | Actual RDATA | variable | Section 4.3.2 | 408 | | | of | | | 409 | | | represented | | | 410 | | | records | | | 411 | 240-255 | EXPERIMENTAL | Reserved for | variable | Section 9 | 412 | | | Experimental | | | 413 | | | Use | | | 414 +---------+--------------+---------------+----------+---------------+ 416 Table 1: TIMEOUT RR Method Identifier values 418 10. Security Considerations 420 There is no secure relationship between a TIMEOUT resource record and 421 the represented resource records it applies to. TIMEOUT records 422 should typically only apply to resource records created through the 423 UPDATE mechanism. Protection for permanent resource records in a 424 zone is advisable. 426 Authenticated UPDATE operations MUST be REQUIRED at authoritative 427 name servers supporting TIMEOUT resource records. 429 11. Acknowledgments 431 This idea was motivated through conversations with Mark Andrews. 432 Thanks to Mark as well as Paul Vixie, Joe Abley, Ted Lemon, Tony 433 Finch, Robert Story, Paul Wouters, Dick Franks, JINMEI, Tatuya, and 434 Timothe Litt for their suggestions, review, and comments. 436 12. References 438 12.1. Normative References 440 [RFC1035] Mockapetris, P., "Domain names - implementation and 441 specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, 442 November 1987, . 444 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 445 Requirement Levels", BCP 14, RFC 2119, 446 DOI 10.17487/RFC2119, March 1997, 447 . 449 [RFC3339] Klyne, G. and C. Newman, "Date and Time on the Internet: 450 Timestamps", RFC 3339, DOI 10.17487/RFC3339, July 2002, 451 . 453 [RFC3597] Gustafsson, A., "Handling of Unknown DNS Resource Record 454 (RR) Types", RFC 3597, DOI 10.17487/RFC3597, September 455 2003, . 457 [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. 458 Rose, "Resource Records for the DNS Security Extensions", 459 RFC 4034, DOI 10.17487/RFC4034, March 2005, 460 . 462 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 463 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 464 May 2017, . 466 12.2. Informative References 468 [I-D.sekar-dns-ul] 469 Cheshire, S. and T. Lemon, "Dynamic DNS Update Leases", 470 draft-sekar-dns-ul-02 (work in progress), August 2018. 472 [RFC1995] Ohta, M., "Incremental Zone Transfer in DNS", RFC 1995, 473 DOI 10.17487/RFC1995, August 1996, 474 . 476 [RFC2136] Vixie, P., Ed., Thomson, S., Rekhter, Y., and J. Bound, 477 "Dynamic Updates in the Domain Name System (DNS UPDATE)", 478 RFC 2136, DOI 10.17487/RFC2136, April 1997, 479 . 481 [RFC5936] Lewis, E. and A. Hoenes, Ed., "DNS Zone Transfer Protocol 482 (AXFR)", RFC 5936, DOI 10.17487/RFC5936, June 2010, 483 . 485 [RFC6763] Cheshire, S. and M. Krochmal, "DNS-Based Service 486 Discovery", RFC 6763, DOI 10.17487/RFC6763, February 2013, 487 . 489 [RFC8555] Barnes, R., Hoffman-Andrews, J., McCarney, D., and J. 490 Kasten, "Automatic Certificate Management Environment 491 (ACME)", RFC 8555, DOI 10.17487/RFC8555, March 2019, 492 . 494 Appendix A. Example TIMEOUT resource records 496 The following example shows sample TIMEOUT resource records based on 497 DNS UPDATEs containing A and AAAA address records plus the 498 corresponding PTR records. 500 A host sending a name registration at time Tn for "A" and "AAAA" 501 records with lease lifetime Ln would have a series of UPDATEs (one 502 for each zone) that contain: 504 +-------------------------------------------+------+----------------+ 505 | Name | RR | Value | 506 | | Type | | 507 +-------------------------------------------+------+----------------+ 508 | s.example.com. | A | 192.0.2.5 | 509 | s.example.com. | AAAA | 12001:db8::5 | 510 | 5.2.0.192.in-addr.arpa. | PTR | s.example.com. | 511 | 5.0.0.0.0.0.0.0.0.0.0.0.b8.0d.01.20.ip6.a | PTR | s.example.com. | 512 | rpa. (bytes) | | | 513 +-------------------------------------------+------+----------------+ 515 Table 2: Example Address Records Update 517 Next, consider the TIMEOUT resource records that would be generated 518 for the records in Table 2. 520 +------------------------------+------+-------+--------+------------+ 521 | Owner Name | For | Count | Method | Expiration | 522 | | Type | | | | 523 +------------------------------+------+-------+--------+------------+ 524 | s.example.com. | A | 0 | 0 | Tn + Ln | 525 | s.example.com. | AAAA | 0 | 0 | Tn + Ln | 526 | 5.2.0.192.in-addr.arpa. | PTR | 0 | 0 | Tn + Ln | 527 | 5.0.0.0.0.0.0.0.0.0.0.0.b8.0 | PTR | 0 | 0 | Tn + Ln | 528 | d.01.20.ip6.arpa. (bytes) | | | | | 529 +------------------------------+------+-------+--------+------------+ 531 Table 3: Address TIMEOUT records 533 Next, assume there are two hosts advertising the same service type 534 (different service types will have different owner names). We will 535 use _ipp._tcp.example.com as an example. 537 Host A sends an UPDATE at time Ta with lease life La for PTR, SRV, A, 538 AAAA, and TXT records. Host B sends an UPDATE at time Tb with lease 539 life Lb for PTR, SRV, A, and TXT records. 541 +--------------------------------+------+---------------------------+ 542 | Owner name | RR | Value | 543 | | Type | | 544 +--------------------------------+------+---------------------------+ 545 | _ipp._tcp.example.com. | PTR | p1._ipp._tcp.example.com. | 546 | p1._ipp._tcp.example.com. | SRV | 0 0 631 p1.example.com. | 547 | p1._ipp._tcp.example.com. | TXT | paper=A4 | 548 | p1.example.com. | A | 192.0.2.1 | 549 | p1.example.com. | AAAA | 2001:db8::1 | 550 +--------------------------------+------+---------------------------+ 552 Table 4: DNS UPDATE from Host A 554 +--------------------------------+------+---------------------------+ 555 | Owner name | RR | Value | 556 | | Type | | 557 +--------------------------------+------+---------------------------+ 558 | _ipp._tcp.example.com. | PTR | p2._ipp._tcp.example.com. | 559 | p2._ipp._tcp.example.com. | SRV | 0 0 631 p2.example.com. | 560 | p2._ipp._tcp.example.com. | TXT | paper=B4 | 561 | p2.example.com. | A | 192.0.2.2 | 562 +--------------------------------+------+---------------------------+ 564 Table 5: DNS UPDATE from Host B 566 For these printer registrations, the TIMEOUT records on the server 567 would look like the following: 569 +---------------------------+------+---+-----+----------------------+ 570 | Owner Name | For | C | Met | Expire / | 571 | | Type | o | hod | RDLEN RDATA | 572 | | | u | | | 573 | | | n | | | 574 | | | t | | | 575 +---------------------------+------+---+-----+----------------------+ 576 | _ipp.tcp.example.com. | PTR | 1 | 1 | Ta + La 25 p1._ipp._ | 577 | | | | | tcp.example.com. | 578 | _ipp.tcp.example.com. | PTR | 1 | 1 | Tb + Lb 25 p2._ipp._ | 579 | | | | | tcp.example.com. | 580 | p1._ipp._tcp.example.com. | SRV | 0 | 0 | Ta + La | 581 | p1._ipp._tcp.example.com. | TXT | 0 | 0 | Ta + La | 582 | p2._ipp._tcp.example.com. | SRV | 0 | 0 | Tb + Lb | 583 | p2._ipp._tcp.example.com. | TXT | 0 | 0 | Tb + Lb | 584 | p1.example.com. | A | 0 | 0 | Ta + La | 585 | p1.example.com. | AAAA | 0 | 0 | Ta + La | 586 | p2.example.com. | A | 0 | 0 | Tb + Lb | 587 +---------------------------+------+---+-----+----------------------+ 589 Table 6: Service TIMEOUT records 591 Authors' Addresses 593 Tom Pusateri 594 Unaffiliated 595 Raleigh, NC 596 USA 598 Email: pusateri@bangj.com 600 Tim Wattenberg 601 Unaffiliated 602 Cologne 603 Germany 605 Email: mail@timwattenberg.de