idnits 2.17.1 draft-pusateri-dnsop-update-timeout-02.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 exact meaning of the all-uppercase expression 'NOT REQUIRED' is not defined in RFC 2119. If it is intended as a requirements expression, it should be rewritten using one of the combinations defined in RFC 2119; otherwise it should not be all-uppercase. -- The document date (March 4, 2019) is 1879 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 (==), 2 comments (--). 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: September 5, 2019 March 4, 2019 7 DNS TIMEOUT Resource Record 8 draft-pusateri-dnsop-update-timeout-02 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 September 5, 2019. 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 . . . . . . . . . . . . . . . . . 3 57 4.1. Represented Record Type . . . . . . . . . . . . . . . . . 4 58 4.2. Represented Record Count . . . . . . . . . . . . . . . . 4 59 4.3. Method Identifiers . . . . . . . . . . . . . . . . . . . 4 60 4.3.1. Method Identifier 0: NO METHOD . . . . . . . . . . . 5 61 4.3.2. Method Identifier 1: RDATA . . . . . . . . . . . . . 5 62 4.4. Expiry Time . . . . . . . . . . . . . . . . . . . . . . . 5 63 5. TIMEOUT RDATA Wire Format . . . . . . . . . . . . . . . . . . 5 64 6. Primary Server Behavior . . . . . . . . . . . . . . . . . . . 7 65 7. Secondary Server Behavior . . . . . . . . . . . . . . . . . . 7 66 8. TIMEOUT RDATA Presentation Format . . . . . . . . . . . . . . 7 67 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 68 10. Security Considerations . . . . . . . . . . . . . . . . . . . 9 69 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 9 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. A zone administrator may 82 want to enforce a default lifetime for dynamic updates (such as the 83 DHCP lease lifetime) or the DNS Update may contain a lifetime using 84 an EDNS(0) Update Lease option [I-D.sekar-dns-ul]. However, this 85 lease lifetime is not communicated to secondary servers and will not 86 endure through server software restarts. Therefore, this 87 specification defines a new DNS TIMEOUT resource record that 88 associates a lifetime with one or more resource records with the same 89 owner name, type, and class that can be transferred to secondary 90 servers through normal AXFR [RFC5936], IXFR [RFC1995] transfer 91 mechanisms. 93 An UPDATE lifetime could be stored in a proprietary database on an 94 authoritative primary server but there is an advantage to saving it 95 as a resource record: redundant master servers and secondary servers 96 capable of taking over as the primary server for a zone automatically 97 can benefit from the existing database synchronization of resource 98 records. In addition, primary and secondary servers from multiple 99 vendors can synchronize the lifetimes through the open format 100 provided by a resource record. 102 2. Requirements Language 104 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 105 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 106 "OPTIONAL" in this document are to be interpreted as described in BCP 107 14 [RFC2119] [RFC8174] when, and only when, they appear in all 108 capitals, as shown here. These words may also appear in this 109 document in lower case as plain English words, absent their normative 110 meanings. 112 3. Sources of TIMEOUT Expiry Time 114 The expire time may come from many different sources. A few are 115 listed here however, this list is not considered complete. 117 1. Via DHCP Dynamic Lease Lifetime communicated out of band. 119 2. Via EDNS(0) Update Lease option [I-D.sekar-dns-ul] communicated 120 in DNS Update. 122 3. Via an administrative default server value such as one day (86400 123 seconds). 125 4. Resource Record Composition 127 TIMEOUT resource records provide expiry times for a mixed variety of 128 resource record types with the same owner name, type, and class. 129 Since there could exist multiple records of the same record type with 130 the same owner name and class, the TIMEOUT resource record must be 131 able to identify each of these records individually with only 132 different RDATA. As an example, PTR records for service discovery 133 [RFC6763] provide a level of indirection to SRV and TXT records by 134 instance name. The instance name is stored in the PTR RDATA and 135 multiple PTR records with the same owner name but only differing 136 RDATA often exist. 138 In order to distinguish each individual record with potentially 139 different expiry times, the TIMEOUT resource record contains an 140 exipry time, the record type, a method to identify the actual records 141 for which the expiry time applies, and a count of the number of 142 records represented. Multiple TIMEOUT records with the same owner 143 name and class are created for each expiry time, record type, and 144 resource record representation. If the expiry time is the same, 145 multiple records can be combined into a single TIMEOUT record with 146 the same owner name, class, and record type but this is NOT REQUIRED. 148 The fields and their values in a TIMEOUT record are defined as: 150 4.1. Represented Record Type 152 A 16-bit field containing the resource record type to which the 153 TIMEOUT record applies. Multiple TIMEOUT records for the same owner 154 name, class, and represented type can exist. 156 4.2. Represented Record Count 158 The Represented Record Count is a 8-bit value that specifies the 159 number of records of the specified record type with this expiry time. 161 An RR Count of zero indicates that it is not necessary to represent 162 any records in the list. This is a shortcut notation meaning all 163 resource records with the same owner name, class, and record type use 164 the same Expiry Time. There MUST be only one TIMEOUT record for the 165 same owner name, class, and record type if the Represented Record 166 Count is zero. If an additional TIMEOUT record exists with the same 167 owner name, class, and record type, it MUST be ignored and SHOULD be 168 removed. When the Represented Record Count is 0, the Method 169 Identifer is set to NO METHOD (0) on transmission and ignored on 170 reception. 172 In the unlikely event that the Represented Record Count exceeds 255 173 which is the largest number representable in 8 bits, multiple 174 instances of the same Expiry Time can exist. 176 4.3. Method Identifiers 178 The Method Identifier is a 8-bit value that specifies an identifier 179 for the algorithm used to distinguish between resource records. The 180 identifiers are declared in a registry maintained by IANA for the 181 purpose of listing acceptable methods for this purpose. In addition 182 to the method and the index, the registry MAY contain a fixed output 183 length in bits of the method to be used or the term "variable" to 184 denote a variable length output per record. It is conceivable, 185 though not likely, that the same method could be used with different 186 fixed output lengths. In this case, each fixed output length would 187 require a different identifier in the registry. Additions to this 188 registry will be approved with additional documentation under expert 189 review. At the time that the registry is created by IANA, a group of 190 expert reviewers will be established. 192 Additional methods of representing records such as hashes or other 193 algorithms may be defined in the future. If such methods are 194 defined, a primary server could create TIMEOUT record using a new 195 method that is not understood by a secondary server that could take 196 over as the primary in the event of an outage or administrative 197 change. In this case, the new primary would not be able to identify 198 the records it is supposed to TIMEOUT. This is a misconfiguration 199 and it is the responsibility of the administrator to ensure that 200 secondary servers in a position to become primary understand the 201 TIMEOUT record methods of the primary server. 203 4.3.1. Method Identifier 0: NO METHOD 205 The method identifier of 0 is defined as "NO METHOD" and MUST NOT be 206 used if the represented record count is greater than 0. The value of 207 0 is to be included in the IANA registry of method identifier values. 209 4.3.2. Method Identifier 1: RDATA 211 The method identifier of 1 is defined as "RDATA". It begins with the 212 RDATA length as a 16-bit value containing the length of the RDATA in 213 bytes followed by the number of bytes of RDATA as appears in the 214 record being represented. The record MUST be in canonical DNSSEC 215 form as described in Section 6 of [RFC4034]. 217 4.4. Expiry Time 219 The expiry time is a 64-bit number expressed as the number of seconds 220 since the UNIX epoch (00:00:00 UTC on January 1, 1970). This value 221 is an absolute time at which the record will expire. Lease times 222 must be converted to an absolute expiry time when received. 224 5. TIMEOUT RDATA Wire Format 226 The TIMEOUT resource record follows the same pattern as other DNS 227 resource records as defined in Section 3.2.1 of [RFC1035] including 228 owner name, type, class, TTL, RDATA length, and RDATA. 230 The RDATA section of the resource record with method identifier RDATA 231 (1) is illustrated in Figure 1: 233 0 1 2 3 234 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 235 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 236 | Represented RR Type | Count (n) | Method (1) | 237 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 238 | Expiry Time (64-bit) | 239 | | 240 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 241 . Represented RDATA LEN 1 | . 242 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ . 243 . . 244 . Represented RDATA 1 . 245 . . 246 . . 247 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 248 . Represented RDATA LEN n | . 249 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ . 250 . . 251 . Represented RDATA n . 252 . . 253 . . 254 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 256 Figure 1: Method (1) RDATA Wire Format 258 Figure 1 represents an arbitrary number of represented records with 259 the same owner name, class, and represented type. For each expiry 260 time, a list of RDATA length and RDATA pairs are attached. The 261 overall RDATA length of the TIMEOUT record indicates when the last 262 represented record is contained in the record. 264 The RDATA section of the resource record with method identifier NO 265 METHOD (0) is illustrated in Figure 2: 267 0 1 2 3 268 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 269 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 270 | Represented RR Type | Count (0) | Method (0) | 271 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 272 | Expiry Time (64-bit) | 273 | | 274 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 276 Figure 2: Method (0) RDATA Wire Format 278 Figure 2 represents the TIMEOUT RDATA field of all matching records 279 of the represented type for the same owner name and class. 281 6. Primary Server Behavior 283 A TIMEOUT resource record MUST be removed when the last resource 284 record it covers has been removed. This may be due to the record 285 expiring (reaching the expiry time) or due to a subsequent DNS Update 286 or administrative action. 288 Upon receiving any DNS UPDATE deleting resource records that might 289 have been covered by a TIMEOUT RR, a primary server MUST remove all 290 represented records in all of the TIMEOUT records with the same owner 291 name, class, and represented type. 293 As a reminder from Section 3.3.13 of [RFC1035], the MINIMUM field of 294 the SOA for the zone is used as a lower bound of the TTL for all 295 records in the zone. Therefore, even if the TIMEOUT record will 296 expire in less time than the MINIMUM, the TTL is still set to the 297 MINIMUM for records covered by the TIMEOUT record and the TIMEOUT 298 record itself when a response is returned by an authoritative server. 299 The TIMEOUT RR is mostly for the benefit of the authoritative server 300 to know when to remove the records. The fact that some records might 301 live longer in the cache of a resolver is no different than other 302 records that might get removed while still in a remote resolver 303 cache. 305 7. Secondary Server Behavior 307 A secondary server may or may not understand TIMEOUT resource 308 records. If a secondary server does not understand them, they are 309 treated like any other resource record that the server may not 310 understand [RFC3597]. 312 A secondary server MUST NOT expire the records in a zone it maintains 313 covered by the TIMEOUT resource record and it MUST NOT expire the 314 TIMEOUT resource record itself when the last record it covers has 315 expired. The secondary server MUST always wait for the records to be 316 removed or updated by the primary server. 318 8. TIMEOUT RDATA Presentation Format 320 Record Type: 321 resource record type mnemonics. When the mnemonic is unknown, 322 the TYPE representation described in Section 5 of [RFC3597] 324 Represented Record Count: 325 unsigned decimal integer (0-255) 327 Method Identifier: 328 unsigned decimal integer (0-255) 330 Expiry Time: 331 The Expiry Time is displayed as a compact numeric-only 332 representation of ISO 8601. All punctuation is removed. This 333 form is slightly different than the recommendation in [RFC3339] 334 but is common for DNS protocols. It is defined in Section 3.2 335 of [RFC4034] as YYYYMMDDHHmmSS in UTC. This form will always 336 be exactly 14 digits since no component is optional. 338 YYYY is the year; 339 MM is the month number (01-12); 340 DD is the day of the month (01-31); 341 HH is the hour, in 24 hour notation (00-23); 342 mm is the minute (00-59); and 343 SS is the second (00-59). 345 RDATA Length: 346 unsigned decimal integer 348 RDATA: 349 record type specific 351 9. IANA Considerations 353 This document defines a new DNS Resource Record Type named TIMEOUT to 354 be exchanged between authoritative primary and secondary DNS servers. 355 It is assigned out of the DNS Parameters Resource Record (RR) Type 356 registry. The value for the TIMEOUT resource record type is TBA. 358 This document establishes a new registry of DNS TIMEOUT Resource 359 Record Method Identifier values. The registry shall include a 360 numeric identifier, a method name, a description of the method, and 361 the length of the output function in bits or the keyword "variable". 362 The identifier is to be used in the RDATA section of the TIMEOUT 363 resource record. 365 +-------+------------+----------------+-------------+---------------+ 366 | ID | Method | Description | Length | Definition | 367 | | Name | | (bits) | | 368 +-------+------------+----------------+-------------+---------------+ 369 | 0 | NO METHOD | All records | 0 | Section 4.3.1 | 370 | | | match | | | 371 | 1 | RDATA | Actual RDATA | variable | Section 4.3.2 | 372 | | | of represented | | | 373 | | | records | | | 374 +-------+------------+----------------+-------------+---------------+ 376 Table 1: TIMEOUT RR Method Identifier values 378 10. Security Considerations 380 There is no secure relationship between a TIMEOUT resource record and 381 the represented resource records it applies to. TIMEOUT records 382 should typically only apply to resource records created through the 383 UPDATE mechanism. Protection for permanent resource records in a 384 zone is advisable. 386 Authenticated UPDATE operations MUST be REQUIRED at authoritative 387 name servers supporting TIMEOUT resource records. 389 11. Acknowledgments 391 This idea was motivated through conversations with Mark Andrews. 392 Thanks to Mark as well as Paul Vixie, Joe Abley, Ted Lemon, Tony 393 Finch, Robert Story, Paul Wouters, and Dick Franks for their 394 suggestions, review, and comments. 396 12. References 398 12.1. Normative References 400 [RFC1035] Mockapetris, P., "Domain names - implementation and 401 specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, 402 November 1987, . 404 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 405 Requirement Levels", BCP 14, RFC 2119, 406 DOI 10.17487/RFC2119, March 1997, 407 . 409 [RFC3339] Klyne, G. and C. Newman, "Date and Time on the Internet: 410 Timestamps", RFC 3339, DOI 10.17487/RFC3339, July 2002, 411 . 413 [RFC3597] Gustafsson, A., "Handling of Unknown DNS Resource Record 414 (RR) Types", RFC 3597, DOI 10.17487/RFC3597, September 415 2003, . 417 [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. 418 Rose, "Resource Records for the DNS Security Extensions", 419 RFC 4034, DOI 10.17487/RFC4034, March 2005, 420 . 422 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 423 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 424 May 2017, . 426 12.2. Informative References 428 [I-D.sekar-dns-ul] 429 Cheshire, S. and T. Lemon, "Dynamic DNS Update Leases", 430 draft-sekar-dns-ul-02 (work in progress), August 2018. 432 [RFC1995] Ohta, M., "Incremental Zone Transfer in DNS", RFC 1995, 433 DOI 10.17487/RFC1995, August 1996, 434 . 436 [RFC2136] Vixie, P., Ed., Thomson, S., Rekhter, Y., and J. Bound, 437 "Dynamic Updates in the Domain Name System (DNS UPDATE)", 438 RFC 2136, DOI 10.17487/RFC2136, April 1997, 439 . 441 [RFC5936] Lewis, E. and A. Hoenes, Ed., "DNS Zone Transfer Protocol 442 (AXFR)", RFC 5936, DOI 10.17487/RFC5936, June 2010, 443 . 445 [RFC6763] Cheshire, S. and M. Krochmal, "DNS-Based Service 446 Discovery", RFC 6763, DOI 10.17487/RFC6763, February 2013, 447 . 449 Appendix A. Example TIMEOUT resource records 451 The following example shows sample TIMEOUT resource records based on 452 DNS UPDATEs containing A and AAAA address records plus the 453 corresponding PTR records. 455 A host sending a name registration at time Tn for "A" and "AAAA" 456 records with lease lifetime Ln would have a series of UPDATEs (one 457 for each zone) that contain: 459 +-------------------------------------------+------+----------------+ 460 | Name | RR | Value | 461 | | Type | | 462 +-------------------------------------------+------+----------------+ 463 | s.example.com. | A | 192.0.2.5 | 464 | s.example.com. | AAAA | 12001:db8::5 | 465 | 5.2.0.192.in-addr.arpa. | PTR | s.example.com. | 466 | 5.0.0.0.0.0.0.0.0.0.0.0.b8.0d.01.20.ip6.a | PTR | s.example.com. | 467 | rpa. (bytes) | | | 468 +-------------------------------------------+------+----------------+ 470 Table 2: Example Address Records Update 472 Next, consider the TIMEOUT resource records that would be generated 473 for the records in Table 2. Notice that none of the 4 TIMEOUT 474 records on the server would require a hash: 476 +------------------------------+------+-------+--------+------------+ 477 | Owner Name | For | Count | Method | Expiration | 478 | | Type | | | | 479 +------------------------------+------+-------+--------+------------+ 480 | s.example.com. | A | 0 | 0 | Tn + Ln | 481 | s.example.com. | AAAA | 0 | 0 | Tn + Ln | 482 | 5.2.0.192.in-addr.arpa. | PTR | 0 | 0 | Tn + Ln | 483 | 5.0.0.0.0.0.0.0.0.0.0.0.b8.0 | PTR | 0 | 0 | Tn + Ln | 484 | d.01.20.ip6.arpa. (bytes) | | | | | 485 +------------------------------+------+-------+--------+------------+ 487 Table 3: Address TIMEOUT records 489 Next, assume there are two hosts advertising the same service type 490 (different service types will have different owner names). We will 491 use _ipp._tcp.example.com as an example. 493 Host A sends an UPDATE at time Ta with lease life La for PTR, SRV, A, 494 AAAA, and TXT records. Host B sends an UPDATE at time Tb with lease 495 life Lb for PTR, SRV, A, and TXT records. 497 +--------------------------------+------+---------------------------+ 498 | Owner name | RR | Value | 499 | | Type | | 500 +--------------------------------+------+---------------------------+ 501 | _ipp._tcp.example.com. | PTR | p1._ipp._tcp.example.com. | 502 | p1._ipp._tcp.example.com. | SRV | 0 0 631 p1.example.com. | 503 | p1._ipp._tcp.example.com. | TXT | paper=A4 | 504 | p1.example.com. | A | 192.0.2.1 | 505 | p1.example.com. | AAAA | 2001:db8::1 | 506 +--------------------------------+------+---------------------------+ 508 Table 4: DNS UPDATE from Host A 510 +--------------------------------+------+---------------------------+ 511 | Owner name | RR | Value | 512 | | Type | | 513 +--------------------------------+------+---------------------------+ 514 | _ipp._tcp.example.com. | PTR | p2._ipp._tcp.example.com. | 515 | p2._ipp._tcp.example.com. | SRV | 0 0 631 p2.example.com. | 516 | p2._ipp._tcp.example.com. | TXT | paper=B4 | 517 | p2.example.com. | A | 192.0.2.2 | 518 +--------------------------------+------+---------------------------+ 520 Table 5: DNS UPDATE from Host B 522 For these printer registrations, the TIMEOUT records on the server 523 would look like the following: 525 +---------------------------+------+---+-----+----------------------+ 526 | Owner Name | For | C | Met | Expire / | 527 | | Type | o | hod | RDLEN RDATA | 528 | | | u | | | 529 | | | n | | | 530 | | | t | | | 531 +---------------------------+------+---+-----+----------------------+ 532 | _ipp.tcp.example.com. | PTR | 1 | 1 | Ta + La 25 p1._ipp._ | 533 | | | | | tcp.example.com. | 534 | _ipp.tcp.example.com. | PTR | 1 | 1 | Tb + Lb 25 p2._ipp._ | 535 | | | | | tcp.example.com. | 536 | p1._ipp._tcp.example.com. | SRV | 0 | 0 | Ta + La | 537 | p1._ipp._tcp.example.com. | TXT | 0 | 0 | Ta + La | 538 | p2._ipp._tcp.example.com. | SRV | 0 | 0 | Tb + Lb | 539 | p2._ipp._tcp.example.com. | TXT | 0 | 0 | Tb + Lb | 540 | p1.example.com. | A | 0 | 0 | Ta + La | 541 | p1.example.com. | AAAA | 0 | 0 | Ta + La | 542 | p2.example.com. | A | 0 | 0 | Tb + Lb | 543 +---------------------------+------+---+-----+----------------------+ 545 Table 6: Service TIMEOUT records 547 Authors' Addresses 549 Tom Pusateri 550 Unaffiliated 551 Raleigh, NC 552 USA 554 Email: pusateri@bangj.com 556 Tim Wattenberg 557 Unaffiliated 558 Cologne 559 Germany 561 Email: mail@timwattenberg.de