idnits 2.17.1 draft-ietf-dnsop-attrleaf-fix-04.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 : ---------------------------------------------------------------------------- -- The draft header indicates that this document updates RFC3529, but the abstract doesn't seem to mention this, which it should. -- The draft header indicates that this document updates RFC3404, but the abstract doesn't seem to mention this, which it should. -- The draft header indicates that this document updates RFC2782, but the abstract doesn't seem to mention this, which it should. -- The draft header indicates that this document updates RFC3620, but the abstract doesn't seem to mention this, which it should. -- The draft header indicates that this document updates RFC3263, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year (Using the creation date from RFC2782, updated by this document, for RFC5378 checks: 1998-09-02) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (August 21, 2018) is 2075 days in the past. Is this intentional? Checking references for intended status: Best Current Practice ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'RFC3263' is defined on line 460, but no explicit reference was found in the text == Unused Reference: 'RFC3404' is defined on line 464, but no explicit reference was found in the text == Unused Reference: 'RFC3529' is defined on line 468, but no explicit reference was found in the text == Unused Reference: 'RFC3620' is defined on line 472, but no explicit reference was found in the text == Unused Reference: 'RFC3832' is defined on line 474, but no explicit reference was found in the text == Unused Reference: 'RFC3861' is defined on line 479, but no explicit reference was found in the text == Unused Reference: 'RFC3887' is defined on line 482, but no explicit reference was found in the text == Unused Reference: 'RFC3921' is defined on line 485, but no explicit reference was found in the text == Unused Reference: 'RFC3958' is defined on line 490, but no explicit reference was found in the text == Unused Reference: 'RFC4120' is defined on line 494, but no explicit reference was found in the text == Unused Reference: 'RFC4227' is defined on line 497, but no explicit reference was found in the text == Unused Reference: 'RFC4386' is defined on line 501, but no explicit reference was found in the text == Unused Reference: 'RFC4387' is defined on line 505, but no explicit reference was found in the text == Unused Reference: 'RFC4976' is defined on line 509, but no explicit reference was found in the text == Unused Reference: 'RFC5026' is defined on line 513, but no explicit reference was found in the text == Unused Reference: 'RFC5328' is defined on line 518, but no explicit reference was found in the text == Unused Reference: 'RFC5389' is defined on line 522, but no explicit reference was found in the text == Unused Reference: 'RFC5415' is defined on line 525, but no explicit reference was found in the text == Unused Reference: 'RFC5509' is defined on line 529, but no explicit reference was found in the text == Unused Reference: 'RFC5518' is defined on line 535, but no explicit reference was found in the text == Unused Reference: 'RFC5555' is defined on line 538, but no explicit reference was found in the text == Unused Reference: 'RFC5617' is defined on line 541, but no explicit reference was found in the text == Unused Reference: 'RFC5679' is defined on line 546, but no explicit reference was found in the text == Unused Reference: 'RFC5766' is defined on line 549, but no explicit reference was found in the text == Unused Reference: 'RFC5780' is defined on line 553, but no explicit reference was found in the text == Unused Reference: 'RFC5804' is defined on line 557, but no explicit reference was found in the text == Unused Reference: 'RFC5864' is defined on line 560, but no explicit reference was found in the text == Unused Reference: 'RFC5928' is defined on line 563, but no explicit reference was found in the text == Unused Reference: 'RFC6011' is defined on line 566, but no explicit reference was found in the text == Unused Reference: 'RFC6120' is defined on line 570, but no explicit reference was found in the text == Unused Reference: 'RFC6186' is defined on line 573, but no explicit reference was found in the text == Unused Reference: 'RFC6376' is defined on line 576, but no explicit reference was found in the text == Unused Reference: 'RFC6733' is defined on line 579, but no explicit reference was found in the text == Unused Reference: 'RFC7208' is defined on line 584, but no explicit reference was found in the text == Unused Reference: 'RFC7489' is defined on line 588, but no explicit reference was found in the text == Unused Reference: 'RFC7671' is defined on line 592, but no explicit reference was found in the text ** Downref: Normative reference to an Informational RFC: RFC 7553 -- Obsolete informational reference (is this intentional?): RFC 3921 (Obsoleted by RFC 6121) -- Obsolete informational reference (is this intentional?): RFC 5389 (Obsoleted by RFC 8489) -- Obsolete informational reference (is this intentional?): RFC 5766 (Obsoleted by RFC 8656) Summary: 1 error (**), 0 flaws (~~), 37 warnings (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 dnsop D. Crocker 3 Internet-Draft Brandenburg InternetWorking 4 Updates: 2782, 3263, 3404, 3529, 3620, August 21, 2018 5 3832, 3861, 3887, 3921, 3958, 6 4120, 4227, 4386, 4387, 4976, 7 5026, 5328, 5389, 5415, 5518, 8 5555, 5617, 5679, 5766, 5780, 9 5804, 5864, 5928, 6011, 6120, 10 6186, 6376, 6733, 7208, 7489, 11 8145 (if approved) 12 Intended status: Best Current Practice 13 Expires: February 22, 2019 15 DNS Attrleaf Changes: Fixing Specifications with Underscored Node Name 16 Use 17 draft-ietf-dnsop-attrleaf-fix-04 19 Abstract 21 Original uses of an underscore character as a domain node name 22 prefix, which creates a space for constrained interpretation of 23 resource records, were specified without the benefit of an IANA 24 registry. This produced an entirely uncoordinated set of name- 25 creation activities, all drawing from the same namespace. A registry 26 now has been defined. However the existing specifications that use 27 underscore naming need to be modified, to be in line with the new 28 registry. This document specifies those changes. The changes 29 preserve existing software and operational practice, while adapting 30 the specifications for those practices to the newer underscore 31 registry model. 33 Status of This Memo 35 This Internet-Draft is submitted in full conformance with the 36 provisions of BCP 78 and BCP 79. 38 Internet-Drafts are working documents of the Internet Engineering 39 Task Force (IETF). Note that other groups may also distribute 40 working documents as Internet-Drafts. The list of current Internet- 41 Drafts is at https://datatracker.ietf.org/drafts/current/. 43 Internet-Drafts are draft documents valid for a maximum of six months 44 and may be updated, replaced, or obsoleted by other documents at any 45 time. It is inappropriate to use Internet-Drafts as reference 46 material or to cite them other than as "work in progress." 48 This Internet-Draft will expire on February 22, 2019. 50 Copyright Notice 52 Copyright (c) 2018 IETF Trust and the persons identified as the 53 document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents 57 (https://trustee.ietf.org/license-info) in effect on the date of 58 publication of this document. Please review these documents 59 carefully, as they describe your rights and restrictions with respect 60 to this document. Code Components extracted from this document must 61 include Simplified BSD License text as described in Section 4.e of 62 the Trust Legal Provisions and are provided without warranty as 63 described in the Simplified BSD License. 65 Table of Contents 67 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 68 2. Underscored RRset Use in Specifications . . . . . . . . . . . 3 69 2.1. TXT RRset Use . . . . . . . . . . . . . . . . . . . . . . 3 70 2.2. SRV RRset Use . . . . . . . . . . . . . . . . . . . . . . 4 71 2.3. URI RRset Use . . . . . . . . . . . . . . . . . . . . . . 5 72 3. Underscored Template Specifications . . . . . . . . . . . . . 6 73 3.1. SRV Specification Changes . . . . . . . . . . . . . . . . 6 74 3.2. URI Specification Changes . . . . . . . . . . . . . . . . 7 75 3.3. DNSSEC Signaling Specifiction Changes . . . . . . . . . . 9 76 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 77 5. Security Considerations . . . . . . . . . . . . . . . . . . . 10 78 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 79 6.1. Normative References . . . . . . . . . . . . . . . . . . 10 80 6.2. References -- Informative . . . . . . . . . . . . . . . . 10 81 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 13 82 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 14 84 1. Introduction 86 Original uses of an underscore character as a domain node name 87 [RFC1035] prefix, which creates a space for constrained 88 interpretation of resource records, were specified without the 89 benefit of an [IANA-reg] registry. This produced an entirely 90 uncoordinated set of name-creation activities, all drawing from the 91 same namespace. A registry has been now defined, and that document 92 discusses the background for underscored domain name use [Attrleaf]. 94 The basic model for underscored name registration, as specified in 95 [Attrleaf], is to have each registry entry be unique in terms of the 96 combination of a resource record type and a 'global' (highest-level) 97 underscored name; that is, the node name beginning with an 98 underscore, which is the closest to the DNS root. 100 The existing uses of underscored naming have specifications that do 101 not reflect the existence of this integrated registry. For the new 102 reader or the new editor of one of those documents, there is 103 currently nothing signaling that the underscore name(s) defined in 104 the document are now processed through an IANA registry. This 105 document remedies that, by marking such a published document with an 106 update, indicating the nature of the change. 108 Further, the documents that define the SRV [RFC2782] and URI 109 [RFC7553] DNS resource records provide a meta-template for 110 underscored name assignments, partially based on separate registries 111 [RFC6335]. For the portion that selects the global (highest-level) 112 underscored name, this perpetuates uncoordinated assignment 113 activities by separate technical specifications, out of the same name 114 space. This document remedies that by providing detail for revisions 115 to the SRV and URI specifications, to bring their use in line with 116 the single, integrated global underscore registry. 118 The result of these changes preserves existing software and 119 operations practices, while adapting the technical specifications to 120 the newer underscore registry model. 122 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 123 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 124 document are to be interpreted as described in [RFC2119]. 126 2. Underscored RRset Use in Specifications 128 The use of underscored node names is specific to each RRTYPE that is 129 being scoped. Each name defines a place, but does not define the 130 rules for what appears underneath that place, either as additional 131 underscored naming or as a leaf node with resource records. Details 132 for those rules are provided by specifications for individual 133 RRTYPEs. The sections below describe the way that existing 134 underscore labels are used with the RRTYPEs that they name. 136 2.1. TXT RRset Use 138 This section provides a generic approach for changes to existing 139 specifications that define straightforward use of underscored node 140 names, when scoping the use of a "TXT" RRset. The approach provides 141 the information needed for adapting such specifications to the use of 142 the IANA DNS Underscore Global Scoped Entry Registry [Attrleaf]. 143 Hence the approach is meant both as an update to these existing 144 specifications, and as guidance for changes when those documents are 145 revised. 147 For any document that specifies the use of a "TXT" RRset under one or 148 more underscored names, that 'global' name is expected to be 149 registered in the IANA DNS Underscore Global Scoped Entry Registry 150 [Attrleaf]. An effort has been made to locate existing drafts that 151 do this, register the global underscored names, and list them in this 152 document. 154 If a public specification that defines use of a "TXT" calls for the 155 use of an underscore-prefixed domain name, the global underscored 156 name -- the one closest to the root -- MUST be entered into this 157 registry, if it is not already registered. 159 Here is a template of suggested text for this to appear in the IANA 160 Considerations section of the specification: 162 "Per" [Attrleaf] "please add the following entry to the DNS 163 Underscore Global Scoped Entry Registry:" 165 +--------+----------------+-----------------------------------------+ 166 | RR | _NODE NAME | REFERENCE | 167 | Type | | | 168 +--------+----------------+-----------------------------------------+ 169 | TXT | _{DNS node | {citation for the document making the | 170 | | name} | addition.} | 171 +--------+----------------+-----------------------------------------+ 173 Table 1: Underscore Global Registry Entry 175 2.2. SRV RRset Use 177 Specification for the SRV [RFC2782] resource record provides a 178 template for use of underscored node names. The global name is 179 characterised as referencing the 'protocol' that is associated with 180 "SRV" RRset usage. 182 This section provides a generic approach for changes to existing 183 specifications that define the use of an "SRV" RRset. The approach 184 provides the information needed for adapting such specifications to 185 the use of the IANA DNS Underscore Global Scoped Entry Registry 186 [Attrleaf]. Hence the approach is meant both as an update to these 187 existing specifications, and as guidance for changes when those 188 documents are revised. 190 For any document that specifies the use of an "SRV" RRset, the global 191 ('protocol') underscored name is expected to be registered in the 192 IANA DNS Underscore Global Scoped Entry Registry [Attrleaf]. An 193 effort has been made to locate existing drafts that do this, register 194 the global underscored names, and list them in this document. 196 If a public specification that defines use of a "SRV" calls for the 197 use of an underscore-prefixed domain name, the global underscored 198 name -- the one closest to the root -- MUST be entered into this 199 registry, if it is not already registered. 201 Here is a template of suggested text for this to appear in the IANA 202 Considerations section of the specification: 204 "Per" [Attrleaf] "please add the following entry to the DNS 205 Underscore Global Scoped Entry Registry:" 207 +--------+----------------------+-----------------------------------+ 208 | RR | _NODE NAME | REFERENCE | 209 | Type | | | 210 +--------+----------------------+-----------------------------------+ 211 | SRV | _{DNS 'protocol' | {citation for the document making | 212 | | node name} | the addition.} | 213 +--------+----------------------+-----------------------------------+ 215 Table 2: Underscore Global Registry Entry 217 2.3. URI RRset Use 219 Specification for the URI [RFC7553] resource record provides a 220 template for use of underscored node names. The global name is 221 characterised as naming the 'protocol' that is associated with "URI" 222 RR usage or by reversing an Enumservice sequence [RFC6117]. 224 This section provides a generic approach for changes to existing 225 specifications that define use of a "URI" RRset. The approach 226 provides the information needed for adapting such specifications to 227 the use of the IANA DNS Underscore Global Scoped Entry Registry 228 [Attrleaf]. Hence the approach is meant both as an update to these 229 existing specifications, and as guidance for changes when those 230 documents are revised. 232 For any document that specifies the use of a "URI" RRset, the global 233 ('protocol' or highest-level enumservice) underscored name is 234 expected to be registered in the IANA DNS Underscore Global Scoped 235 Entry Registry [Attrleaf]. An effort has been made to locate 236 existing drafts that do this and register the associated 'protocol' 237 names. 239 If a public specification that defines use of a "URI" calls for the 240 use of an underscore-prefixed domain name, the global underscored 241 name -- the one closest to the root -- MUST be entered into this 242 registry, if it is not already registered. 244 Here is a template of suggested text for this to appear in the IANA 245 Considerations section of the specification: 247 "Per" [Attrleaf] "please add the following entry to the DNS 248 Underscore Global Scoped Entry Registry:" 250 +-------+---------------------------+-------------------------------+ 251 | RR | _NODE NAME | REFERENCE | 252 | Type | | | 253 +-------+---------------------------+-------------------------------+ 254 | URI | _{DNS 'protocol' or | {citation for the document | 255 | | Enumservice node name} | making the addition.} | 256 +-------+---------------------------+-------------------------------+ 258 Table 3: Underscore Global Registry Entry 260 3. Underscored Template Specifications 262 3.1. SRV Specification Changes 264 The specification for a domain name under, which an SRV [RFC2782] 265 resource record appears, provides a template for use of underscored 266 node names. The global underscored name, is characterised as 267 indicating the 'protocol' that is associated with "SRV" RR usage. 269 The text of that existing specification is hereby updated from: 271 The format of the SRV RR 273 Here is the format of the SRV RR, whose DNS type code is 33: 274 _Service._Proto.Name TTL Class SRV Priority Weight Port Target 275 ... 276 Proto 277 The symbolic name of the desired protocol, with an underscore 278 (_) prepended to prevent collisions with DNS labels that occur 279 in nature. _TCP and _UDP are at present the most useful values 280 for this field, though any name defined by Assigned Numbers or 281 locally may be used (as for Service). The Proto is case 282 insensitive. 284 And is to be updated to the new text: 286 The format of the SRV RR 288 Here is the format of the SRV RR, whose DNS type code is 33: 290 "_Service._Proto.Name TTL Class SRV Priority Weight Port 291 Target" _..._ 293 Proto 295 The symbolic name of the desired protocol, with an 296 underscore (_) prepended to prevent collisions with DNS 297 labels that occur in nature. _TCP and _UDP are at present 298 the most useful values for this field. The Proto is case 299 insensitive. 301 The SRV RRset protocol (global) underscored name SHOULD be 302 registered in the IANA DNS Underscore Global Scoped Entry 303 Registry [Attrleaf]. 305 3.2. URI Specification Changes 307 Specification for the domain name under which a URI [RFC7553] 308 resource record occurs is similar to that for the SRV [RFC2782] 309 resource record, although the text refers only to 'service' name, 310 rather than distinguishing 'service' from 'protocol'. Further, the 311 URI RR specification permits alternative underscored naming schemes: 313 One matches what is used for "SRV", with the global underscored 314 name called "protocol'. 316 The other is based on a reversing of an Enumservice [RFC6117] 317 sequence. 319 The text of the existing specification is hereby updated from: 321 4.1. Owner Name, Class, and Type 323 The URI owner name is subject to special conventions. 325 Just like the SRV RR [RFC2782], the URI RR has service information 326 encoded in its owner name. In order to encode the service for a 327 specific owner name, one uses service parameters. Valid service 328 parameters are those registered by IANA in the "Service Name and 329 Transport Protocol Port Number Registry" [RFC6335] or as "Enumservice 330 --- 331 Registrations [RFC6117]. The Enumservice Registration parameters are 332 reversed (i.e., subtype(s) before type), prepended with an underscore 333 (_), and prepended to the owner name in separate labels. The 334 underscore is prepended to the service parameters to avoid collisions 335 with DNS labels that occur in nature, and the order is reversed to 336 make it possible to do delegations, if needed, to different zones 337 (and therefore providers of DNS). 339 For example, suppose we are looking for the URI for a service with 340 ENUM Service Parameter "A:B:C" for host example.com. Then we would 341 query for (QNAME,QTYPE)=("_C._B._A.example.com","URI"). 343 As another example, suppose we are looking for the URI for a service 344 with Service Name "A" and Transport Protocol "B" for host 345 example.com. Then we would query for 346 (QNAME,QTYPE)=("_A._B.example.com","URI"). 348 And is to be updated to the new text: 350 4.1. Owner Name, Class, and Type 352 The URI owner name is subject to special conventions. 354 As for the SRV RRset [RFC2782], the URI RRset global (highest- 355 level) underscored name SHOULD be registered in the IANA DNS 356 Underscore Global Scoped Entry Registry [Attrleaf]. 358 Just like the SRV RRset, the URI RRset has service information 359 encoded in its owner name. In order to encode the service for 360 a specific owner name, one uses service parameters. Valid 361 service parameters are: 363 + Those registered by IANA in the "Service Name and Transport 364 Protocol Port Number Registry [RFC6335]" The underscore is 365 prepended to the service parameters to avoid collisions with 366 DNS labels that occur in nature, and the order is reversed 367 to make it possible to do delegations, if needed, to 368 different zones (and therefore providers of DNS). 370 + Those listed in "Enumservice Registrations [RFC6117]. The 371 Enumservice Registration parameters are reversed (i.e., 372 subtype(s) before type), prepended with an underscore (_), 373 and prepended to the owner name in separate labels. The 374 highest-level (global) underscored Enumservice name becomes 375 the global Attrleaf name to register. 377 For example, suppose we are looking for the URI for a service 378 with ENUM Service Parameter "A:B:C" for host example.com. Then 379 we would query for 380 (QNAME,QTYPE)=("_C._B._A.example.com","URI"). 382 As another example, suppose we are looking for the URI for a 383 service with Service Name "A" and Transport Protocol "B" for 384 host example.com. Then we would query for 385 (QNAME,QTYPE)=("_A._B.example.com","URI"). 387 3.3. DNSSEC Signaling Specifiction Changes 389 " Signaling Trust Anchor Knowledge in DNS Security Extensions 390 (DNSSEC)" [RFC8145] defines a use of DNS node names that effectively 391 consumes all names beginning with the string "_ta-", when using the 392 NUL RR in the query. 394 Section 5.1, "Query Format", of the specification is changed as 395 follows: 397 OLD: 399 For example, a validating DNS resolver ... QNAME=_ta-4444. 401 NEW: 403 For example, a validating DNS resolver ... QNAME=_ta-4444. 405 Under the NULL RR, an entry is registered in the IANA DNS 406 Underscore Global Scoped Entry Registry [Attrleaf] for all node 407 names beginning with "_ta-". 409 4. IANA Considerations 411 Although this document makes reference to IANA registries, it 412 introduces no new IANA registries or procedures. 414 5. Security Considerations 416 This memo raises no security issues. 418 6. References 420 6.1. Normative References 422 [Attrleaf] 423 Crocker, D., "DNS Scoped Data Through 'Underscore' Naming 424 of Attribute Leaves", I-D draft-ietf-dnsop-attrleaf, 2018. 426 [RFC6117] Hoeneisen, B., Mayrhofer, A., and J. Livingood, "IANA 427 Registration of Enumservices: Guide, Template, and IANA 428 Considerations", RFC 6117, March 2011. 430 [RFC6335] Cotton, M., Eggert, L., Tpuch, J., Westerlund, M., and S. 431 Cheshire, "Internet Assigned Numbers Authority (IANA) 432 Procedures for the Management of the Service Name and 433 Transport Protocol Port Number Registry", RFC 6335, Aug 434 2011. 436 [RFC7553] Falstrom, P. and O. Kolkman, "The Uniform Resource 437 Identifier (URI) DNS Resource Record", RFC 7553, 438 ISSN 2070-1721, June 2015. 440 [RFC8145] Wessels, D., Kumari, W., and P. Hoffman, "Signaling Trust 441 Anchor Knowledge in DNS Security Extensions (DNSSEC)", 442 RFC 8145, April 2017. 444 6.2. References -- Informative 446 [IANA-reg] 447 "Protocol Registries", URL https://www.iana.org/protocols, 448 2018. 450 [RFC1035] Mockapetris, P., "Domain names - implementation and 451 specification", STD 13, RFC 1035, November 1987. 453 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 454 Requirement Levels", BCP 14, RFC 2119, March 1997. 456 [RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for 457 specifying the location of services (DNS SRV)", RFC 2782, 458 February 2000. 460 [RFC3263] Rosenberg, J. and H. Schulzrinne, "Session Initiation 461 Protocol (SIP): Locating SIP Servers", RFC 3263, June 462 2002. 464 [RFC3404] Mealling, M., "Dynamic Delegation Discovery System (DDDS) 465 Part Four: The Uniform Resource Identifiers (URI) 466 Resolution Application", RFC 3404, October 2002. 468 [RFC3529] Harold, W., "Using Extensible Markup Language-Remote 469 Procedure Calling (XML-RPC) in Blocks Extensible Exchange 470 Protocol (BEEP)", RFC 3529, April 2003. 472 [RFC3620] New, D., "The TUNNEL Profile", RFC 3620, October 2003. 474 [RFC3832] Columbia University, Columbia University, Sun 475 Microsystems, IBM, and IBM, "Remote Service Discovery in 476 the Service Location Protocol (SLP) via DNS SRV", 477 RFC 3832, July 2004. 479 [RFC3861] Peterson, J., "Address Resolution for Instant Messaging 480 and Presence", RFC 3861, August 2004. 482 [RFC3887] "Message Tracking Query Protocol", RFC 3887, September 483 2007. 485 [RFC3921] Saint-Andre, P., Ed., "Extensible Messaging and Presence 486 Protocol (XMPP): Instant Messaging and Presence", 487 RFC 3921, DOI 10.17487/RFC3921, October 2004, 488 . 490 [RFC3958] Daigle, L. and A. Newton, "Domain-Based Application 491 Service Location Using SRV RRs and the Dynamic Delegation 492 Discovery Service (DDDS)", RFC 3958, January 2005. 494 [RFC4120] USC-ISI, MIT, MIT, and MIT, "The Kerberos Network 495 Authentication Service (V5)", RFC 4120, July 2005. 497 [RFC4227] O'Tuathail, E. and M. Rose, "Using the Simple Object 498 Access Protocol (SOAP) in Blocks Extensible Exchange 499 Protocol (BEEP)", RFC 4227, January 2006. 501 [RFC4386] Boeyen, S. and P. Hallam-Baker, "Internet X.509 Public Key 502 Infrastructure: Repository Locator Service", RFC 4386, 503 February 2006. 505 [RFC4387] Gutmann, P., Ed., "Internet X.509 Public Key 506 Infrastructure Operational Protocols: Certificate Store 507 Access via HTTP", RFC 4387, February 2006. 509 [RFC4976] Jennings, C., Mahy, R., and Roach, "Relay Extensions for 510 the Message Session Relay Protocol (MSRP)", RFC 4976, 511 September 2007. 513 [RFC5026] Giaretta, G., Ed., Kempf, J., and V. Devarapalli, Ed., 514 "Mobile IPv6 Bootstrapping in Split Scenario", RFC 5026, 515 DOI 10.17487/RFC5026, October 2007, 516 . 518 [RFC5328] Adolf, A. and P. MacAvock, "A Uniform Resource Name (URN) 519 Namespace for the Digital Video Broadcasting Project 520 (DVB)", RFC 5328, September 2008. 522 [RFC5389] Rosenberg, Mahy, Matthews, and Wing, "Session Traversal 523 Utilities for NAT (STUN)", RFC 5389, October 2008. 525 [RFC5415] Calhoun, P., Ed., Montemurro, M., Ed., and D. Stanley, 526 Ed., "Control And Provisioning of Wireless Access Points 527 (CAPWAP) Protocol Specification", RFC 5415, March 2009. 529 [RFC5509] Loreto, S., "Internet Assigned Numbers Authority (IANA) 530 Registration of Instant Messaging and Presence DNS SRV RRs 531 for the Session Initiation Protocol (SIP)", RFC 5509, 532 DOI 10.17487/RFC5509, April 2009, 533 . 535 [RFC5518] Hoffman, P., Levine, J., and A. Hathcock, "Vouch By 536 Reference", RFC 5518, April 2009. 538 [RFC5555] Soliman, H., Ed., "Mobile IPv6 Support for Dual Stack 539 Hosts and Routers", RFC 5555, June 2009. 541 [RFC5617] Sendmail, Inc., Cisco Systems, Inc., Yahoo! Inc., and 542 Taughannock Networks, "DomainKeys Identified Mail (DKIM) 543 Author Domain Signing Practices (ADSP)", RFC 5617, August 544 2009. 546 [RFC5679] Bajko, G., "Locating IEEE 802.21 Mobility Services Using 547 DNS", RFC 5679, December 2009. 549 [RFC5766] Mahy, R., Matthews, P., and J. Rosenberg, "Traversal Using 550 Relays around NAT (TURN): Relay Extensions to Session 551 Traversal Utilities for NAT (STUN)", RFC 5766, April 2010. 553 [RFC5780] MacDonald, D. and B. Lowekamp, "NAT Behavior Discovery 554 Using Session Traversal Utilities for NAT (STUN)", 555 RFC 5780, May 2010. 557 [RFC5804] Melnikov, A., Ed. and T. Martin, "A Protocol for Remotely 558 Managing Sieve Scripts", RFC 5804, July 2010. 560 [RFC5864] Allbery, R., "NS SRV Resource Records for AFS", RFC 5864, 561 April 2010. 563 [RFC5928] Petit-Huguenin, M., "Traversal Using Relays around NAT 564 (TURN) Resolution Mechanism", RFC 5928, August 2010. 566 [RFC6011] Lawrence, S., Ed. and J. Elwell, "Session Initiation 567 Protocol (SIP) User Agent Configuration", RFC 6011, 568 October 2010. 570 [RFC6120] Saint-Andre, P., "Extensible Messaging and Presence 571 Protocol (XMPP): Core", RFC 6120, March 2011. 573 [RFC6186] Daboo, C., "Use of SRV Records for Locating Email 574 Submission/Access Services", RFC 6186, March 2011. 576 [RFC6376] Crocker, D., Hansen, T., and M. Kucherawy, "DomainKeys 577 Identified Mail (DKIM) Signatures", RFC 6376, Sept 2011. 579 [RFC6733] Fajardo, V., Ed., Arkko, J., Loughney, J., and G. Zorn, 580 Ed., "Diameter Base Protocol", RFC 6733, 581 DOI 10.17487/RFC6733, October 2012, 582 . 584 [RFC7208] Kitterman, S., "Sender Policy Framework (SPF) for 585 Authorizing Use of Domains in E-Mail, Version 1", 586 RFC 7208, April 2014. 588 [RFC7489] Kucherawy, M., Ed. and E. Zwicky, Ed., "Domain-based 589 Message Authentication, Reporting, and Conformance 590 (DMARC)", RFC 7489, March 2015. 592 [RFC7671] Dukhovni, V. and W. Hardaker, "The DNS-Based 593 Authentication of Named Entities (DANE) Protocol: Updates 594 and Operational Guidance", RFC 7671, DOI 10.17487/RFC7671, 595 October 2015, . 597 Appendix A. Acknowledgements 599 Thanks go to Bill Fenner, Dick Franks, Tony Hansen, Peter Koch, Olaf 600 Kolkman, and Andrew Sullivan for diligent review of the (much) 601 earlier drafts. For the later enhancements, thanks to: Tim Wicinski, 602 John Levine, Bob Harold, Joel Jaeggli, Ondřej Sury and Paul 603 Wouters. 605 Special thanks to Ray Bellis for his persistent encouragement to 606 continue this effort, as well as the suggestion for an essential 607 simplification to the registration model. 609 Author's Address 611 Dave Crocker 612 Brandenburg InternetWorking 613 675 Spruce Dr. 614 Sunnyvale, CA 94086 615 USA 617 Phone: +1.408.246.8253 618 Email: dcrocker@bbiw.net 619 URI: http://bbiw.net/