idnits 2.17.1 draft-faltstrom-uri-09.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 RFC3959, but the abstract doesn't seem to mention this, which it should. -- The abstract seems to indicate that this document updates RFC3958, but the header doesn't have an 'Updates:' line to match this. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year (Using the creation date from RFC3404, updated by this document, for RFC5378 checks: 2000-07-19) -- 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 8, 2014) is 3546 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) == Missing Reference: 'X' is mentioned on line 463, but not defined ** Obsolete normative reference: RFC 6195 (Obsoleted by RFC 6895) Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group P. Faltstrom 3 Internet-Draft Netnod 4 Updates: 3404, 3959 (if approved) O. Kolkman 5 Intended status: Standards Track ISOC 6 Expires: February 9, 2015 August 8, 2014 8 The Uniform Resource Identifier (URI) DNS Resource Record 9 draft-faltstrom-uri-09 11 Abstract 13 This document defines a new DNS resource record, called the Uniform 14 Resource Identifier (URI) RR, for publishing mappings from hostnames 15 to URIs. 17 This document updates RFC 3958 and RFC 3404. 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 http://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 February 9, 2015. 36 Copyright Notice 38 Copyright (c) 2014 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 (http://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. Applicability Statement . . . . . . . . . . . . . . . . . . . 3 55 3. DNS considerations . . . . . . . . . . . . . . . . . . . . . 3 56 4. The format of the URI RR . . . . . . . . . . . . . . . . . . 4 57 4.1. Ownername, class and type . . . . . . . . . . . . . . . . 4 58 4.2. Priority . . . . . . . . . . . . . . . . . . . . . . . . 5 59 4.3. Weight . . . . . . . . . . . . . . . . . . . . . . . . . 5 60 4.4. Target . . . . . . . . . . . . . . . . . . . . . . . . . 5 61 4.5. URI RDATA Wire Format . . . . . . . . . . . . . . . . . . 5 62 5. Definition of the flag 'D' for NAPTR records . . . . . . . . 6 63 6. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 6 64 6.1. Homepage at one domain, but two domains in use . . . . . 6 65 7. Relation to S-NAPTR . . . . . . . . . . . . . . . . . . . . . 7 66 8. Relation to U-NAPTR . . . . . . . . . . . . . . . . . . . . . 7 67 9. Relation to SRV . . . . . . . . . . . . . . . . . . . . . . . 7 68 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 69 10.1. Registration of the URI Resource Record Type . . . . . . 7 70 10.2. Registration of services . . . . . . . . . . . . . . . . 8 71 11. Security Considerations . . . . . . . . . . . . . . . . . . . 8 72 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 73 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 74 13.1. Normative References . . . . . . . . . . . . . . . . . . 9 75 13.2. Non-normative references . . . . . . . . . . . . . . . . 9 76 Appendix A. The original RRTYPE Allocation Request . . . . . . . 10 77 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 79 1. Introduction 81 This document explains the use of the Domain Name System (DNS) for 82 the storage of URIs, and how to resolve hostnames to such URIs that 83 can be used by various applications. For resolution the application 84 need to know both the hostname and the protocol that the URI is to be 85 used for. The protocol is registered by IANA. 87 Currently, looking up URIs given a hostname uses the DDDS [RFC3401] 88 application framework with the DNS as a database as specified in RFC 89 3404 [RFC3404]. This has a number of implications such as the 90 inability to select what NAPTR records that match the query are 91 interesting. The RRSet returned will always consist of all URIs 92 "connected" with the domain in question. 94 The URI resource record specified in this document enables the 95 querying party to select which ones of the NAPTR records one is 96 interested in. This because data in the service field of the NAPTR 97 record is included in the owner part of the URI resource record type. 99 Querying for URI resource records is not replacing querying for NAPTR 100 resource records (or use of S-NAPTR [RFC3958]). Instead, the URI 101 resource record type provides a complementary mechanism to use when 102 one already knows what service field is interesting. With it, one 103 can directly query for the specific subset of the otherwise possibly 104 large RRSet given back when querying for NAPTR resource records. 106 This document updates RFC 3958 and RFC 3404 by adding the flag "D" to 107 the list of defined terminal flags in section 2.2.3 of RFC 3958 and 108 4.3 of RFC 3404. 110 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 111 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 112 document are to be interpreted as described in BCP 14, RFC 2119 113 [RFC2119]. 115 2. Applicability Statement 117 In general, it is expected that URI records will be used by clients 118 for applications where the relevant protocol to be used is known, 119 but, for example, an extra abstraction is needed in order to separate 120 a domain name from a point of service (as addressed by the URI). One 121 example of such a situation is when an organisation has many domain 122 names, but only one official web page. 124 Applications MUST know the specific service fields to prepend the 125 hostname with. Using repetitive queries for URI records MUST NOT be 126 a replacement for querying for NAPTR records according to the NAPTR 127 (DDDS) or S-NAPTR algorithms. NAPTR records serve the purpose to 128 discover the various services and URIs for looking up access points 129 for a given service. Those are two very different kinds of needs. 131 3. DNS considerations 133 Using prefix labels, such as underscored service tags, for a specific 134 owner name may cause a counter-intuitive effect when the owner name 135 is a wildcard name. For example, _s2._s1.*.example.net. is not a 136 wildcard name and cannot be used to return a synthesized answer for a 137 query name of _s2._s1.a.example.net. See Section 4.5 of RFC4592 138 [RFC4592] for more details. Besides, underscored service tags used 139 for the URI RR (based on the NAPTR service descriptions) may have 140 slightly different semantics than service tags used for underscored 141 prefix labels that are used in combination with other (yet 142 unspecified) RR types. This may cause subtle management problems 143 when delegation structure that has developed within the context of 144 URI RRs is also to be used for other RR types. Since the service 145 labels might be overloaded, applications should carefully check that 146 the application level protocol is indeed the protocol they expect. 148 Subtle management issues may also arise when the delegations from 149 service to sub service label involves several parties and different 150 stake holders. 152 4. The format of the URI RR 154 This is the presentation format of the URI RR: 156 Ownername TTL Class URI Priority Weight Target 158 The URI RR does not cause any kind of Additional Section processing. 160 4.1. Ownername, class and type 162 The URI ownername is subject to special conventions. 164 Just like the SRV RR [RFC2782] the URI RR has service information 165 encoded in its ownername. In order to encode the service for a 166 specific owner name one uses service parameters. Valid service 167 parameters used are those used for SRV resource records, or 168 registered by IANA for Enumservice Registrations. The Enumservice 169 Registration parameters are reversed (subtype(s) before type), 170 prepended with an underscore (_) and prepended to the owner name in 171 separate labels. The underscore is prepended to the service 172 parameters to avoid collisions with DNS labels that occur in nature, 173 and the order is reversed to make it possible to do delegations, if 174 needed, to different zones (and therefore providers of DNS). 176 It should be noted that the usage of a prefix must be described in 177 detail in for example the Enumservice Registration documentation, or 178 in a specific document that clarifies potential overload of 179 parameters in the same URI. Specifically, registered URI schemes are 180 not automatically acceptable as a service. With the HTTP scheme, one 181 can for example have multiple methods (GET, PUT, etc), and this with 182 the same URI. 184 For example, suppose we are looking for the URI for a service with 185 Service Parameter "A:B:C" for host example.com.. Then we would query 186 for (QNAME,QTYPE)=("_C._B._A.example.com","URI") 188 The type number for the URI record is 256. 190 The URI resource record is class independent. 192 The URI RR has no special TTL requirements. 194 4.2. Priority 196 The priority of the target URI in this RR. Its range is 0-65535. A 197 client MUST attempt to contact the URI with the lowest-numbered 198 priority it can reach; URIs with the same priority SHOULD be tried in 199 the order defined by the weight field. 201 4.3. Weight 203 A server selection mechanism. The weight field specifies a relative 204 weight for entries with the same priority. Larger weights SHOULD be 205 given a proportionately higher probability of being selected. The 206 range of this number is 0-65535. 208 4.4. Target 210 The URI of the target, enclosed in double-quote characters ('"'). 211 Resolution of the URI is according to the definitions for the Scheme 212 of the URI. 214 Since the URI will not be encoded as a (see 215 RFC1035 section 3.3 [RFC1035]) there is no 255 character size 216 limitation. 218 The Target MUST NOT be empty (""). 220 4.5. URI RDATA Wire Format 222 The RDATA for a URI RR consists of a 2 octet Priority field, a two 223 octet Weight field, and a variable length target field. 225 Priority and Weight are unsigned integers in network byte order. 227 The remaining data in the RDATA contains the Target field. The 228 Target field contains the URI as a sequence of octets (without the 229 enclosing double- quote characters used in the presentation format). 231 The Target field can also contain an IRI, but with the additional 232 requirements that it are in UTF-8 [RFC3629], and the requirement that 233 it be possible to convert to a URI according to section 3.1 of RFC 234 3987 [RFC3987] and back again to an IRI according to section 3.2. 235 Other character sets than UTF-8 are not allowed. The domain name 236 part of the IRI can be either an U-LABEL or A-LABEL as defined in RFC 237 5890 [RFC5890]. 239 The length of the target field MUST be greater than zero. 241 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 242 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 243 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 244 | Priority | Weight | 245 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 246 / / 247 / Target / 248 / / 249 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 251 5. Definition of the flag 'D' for NAPTR records 253 This document specifies the flag "D" for use as a flag in NAPTR 254 records. The flag indicate a terminal NAPTR record because it 255 denotes the end of the DDDS/NAPTR processing rules. In the case of a 256 "D" flag, the Replacement field in the NAPTR record, prepended with 257 the service flags, is used as the Owner of a DNS query for URI 258 records, and normal URI processing as defined in this document is 259 applied. 261 The replacement field MUST NOT include any of the service parameters. 262 Those are to be prepended (together with underscore) as described in 263 other places in this document. 265 The Regexp field in the NAPTR record MUST be empty when the 'D' flag 266 is in use. 268 6. Examples 270 6.1. Homepage at one domain, but two domains in use 272 An organisation has the domain names example.com and example.net, but 273 the official URI http://www.example.com/. Given the service type 274 "web" and subtype "http" (from the IANA registry), the following URI 275 Resource Records could be made available in the respective zones 276 (example.com and example.net): 278 $ORIGIN example.com. 279 _http._web IN URI 10 1 "http://www.example.com/" 281 $ORIGIN example.net. 282 _http._web IN URI 10 1 "http://www.example.com/" 284 7. Relation to S-NAPTR 286 The URI resource record type is not a replacement for the S-NAPTR. 287 It is instead an extension and the seond step of the S-NAPTR 288 resolution can resolve a URI resource record instead of using SRV 289 records and yet another algorithm for how to use SRV records for the 290 specific protocol. 292 $ORIGIN example.com. 293 ;; order pref flags 294 IN NAPTR 100 10 "s" "EM:ProtA" ( ; service 295 "" ; regexp 296 _ProtA._tcp.example.com. ; replacement 297 _ProtA._tcp IN URI "schemeA:service.example.com/example" 299 8. Relation to U-NAPTR 301 The URI Resource Record Type, together with S-NAPTR, can be viewed as 302 a replacement for U-NAPTR [RFC4848]. The URI Resource Record Type is 303 though only interesting when one know a base domain name, a protocol 304 and service so that one can compose the record to look up. NAPTR 305 records of any kind are used to look up what services exists for a 306 certain domain, which is one step before the URI resource record is 307 used. 309 9. Relation to SRV 311 The URI Resource Record Type can be viewed as a replacement for the 312 SRV record. This because it like the SRV record can only be looked 313 up if one know the base domain, the protocol and the service. It has 314 a similar functionality, but instead of returning a hostname and port 315 number, the URI record return a full URI. As such, it can be viewed 316 as a more powerful resource record than SRV. 318 10. IANA Considerations 320 10.1. Registration of the URI Resource Record Type 322 After an expert review in February 2011 (see Appendix A) IANA has 323 allocated RRTYPE 256 for the URI Resource Record Type in the registry 324 named Resource Record (RR) TYPEs and QTYPEs as defined in BCP 42 (at 325 the time RFC 6195 [RFC6195]), located at 326 http://www.iana.org/assignments/dns-parameters. 328 IANA is requested to update the reference with that registration to 329 this RFC. 331 10.2. Registration of services 333 No new registry is needed for the registration of services as the 334 Enumservice Registrations registry is used also for the URI resource 335 record type. 337 11. Security Considerations 339 The authors do not believe this resource record cause any new 340 security problems. Deployment must though be done in a proper way as 341 misconfiguration of this resource record might make it impossible to 342 reach the service that was originally intended to be accessed. 344 Using the URI resource record together with security mechanisms that 345 relies on verification of authentication of hostnames, like TLS, 346 makes it important to choose the correct domain name when doing the 347 comparison. 349 The basic mechanism works as follows: 351 1. Announce the fact example.com is hosted at example.org (with 352 some URL) in DNS 354 2. Secure the URI resource record with DNSSEC. 356 3. Verify the TLS (for example) certificate for the connection to 357 example.org matches, i.e. use the hostname in the URI and not 358 the hostname used originally when looking up the URI resource 359 record. 361 4. If needed, do application layer authentication etc over the then 362 encrypted connection. 364 What also can happen is that the URI in the resource record type has 365 errors in it. Applications using the URI resource record type for 366 resolution should behave similarly as if the user typed (or copy and 367 pasted) the URI. At least it must be clear to the user that the 368 error is not due to any error from his side. 370 One SHOULD NOT include userinfo (see User Information, Section 3.2.1, 371 in RFC 3986 [RFC3986]) in a URI that is used in a URI resource record 372 as DNS data must be viewed as publicly available information. 374 12. Acknowledgements 376 Ideas on how to split the two different kind of queries "What 377 services exists for this domain name" and "What is the URI for this 378 service" came from Scott Bradner and Lawrence Conroy. Other people 379 that have contributed to this document include Richard Barnes, Leslie 380 Daigle, Olafur Gudmundsson, Ted Hardie, Evan Hunt, Peter Koch, Penn 381 Pfautz, Jinmei Tatuya and Willem Toorop. 383 Cisco is acknowledged as mr Faltstrom's employer at the time this 384 document was developed. 386 NLnet Labs is acknowledged as mr Kolkman's employer at the time this 387 document was developed. 389 13. References 391 13.1. Normative References 393 [RFC1035] Mockapetris, P., "Domain names - implementation and 394 specification", STD 13, RFC 1035, November 1987. 396 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 397 Requirement Levels", BCP 14, RFC 2119, March 1997. 399 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 400 10646", STD 63, RFC 3629, November 2003. 402 [RFC3958] Daigle, L. and A. Newton, "Domain-Based Application 403 Service Location Using SRV RRs and the Dynamic Delegation 404 Discovery Service (DDDS)", RFC 3958, January 2005. 406 [RFC3987] Duerst, M. and M. Suignard, "Internationalized Resource 407 Identifiers (IRIs)", RFC 3987, January 2005. 409 [RFC5890] Klensin, J., "Internationalized Domain Names for 410 Applications (IDNA): Definitions and Document Framework", 411 RFC 5890, August 2010. 413 [RFC6195] Eastlake, D., "Domain Name System (DNS) IANA 414 Considerations", RFC 6195, March 2011. 416 13.2. Non-normative references 418 [RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for 419 specifying the location of services (DNS SRV)", RFC 2782, 420 February 2000. 422 [RFC3401] Mealling, M., "Dynamic Delegation Discovery System (DDDS) 423 Part One: The Comprehensive DDDS", RFC 3401, October 2002. 425 [RFC3403] Mealling, M., "Dynamic Delegation Discovery System (DDDS) 426 Part Three: The Domain Name System (DNS) Database", RFC 427 3403, October 2002. 429 [RFC3404] Mealling, M., "Dynamic Delegation Discovery System (DDDS) 430 Part Four: The Uniform Resource Identifiers (URI)", RFC 431 3404, October 2002. 433 [RFC3597] Gustafsson, A., "Handling of Unknown DNS Resource Record 434 (RR) Types", RFC 3597, September 2003. 436 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 437 Resource Identifier (URI): Generic Syntax", STD 66, RFC 438 3986, January 2005. 440 [RFC4592] Lewis, E., "The Role of Wildcards in the Domain Name 441 System", RFC 4592, July 2006. 443 [RFC4848] Daigle, L., "Domain-Based Application Service Location 444 Using URIs and the Dynamic Delegation Discovery Service 445 (DDDS)", RFC 4848, April 2007. 447 [RFC5507] IAB, Faltstrom, P., Austein, R., and P. Koch, "Design 448 Choices When Expanding the DNS", RFC 5507, April 2009. 450 Appendix A. The original RRTYPE Allocation Request 452 On February 22, 2011 IANA assigned RRTYPE 256 for the URI resource 453 record based on a request that followed the procedure documented in 454 RFC 6195 [RFC6195]. The DNS RRTYPE PARAMETER ALLOCATION form as 455 submitted to IANA at thet time is replicated below for reference. 457 A. Submission Date: 459 May 23, 2009 461 B. Submission Type: 463 [X] New RRTYPE 464 [ ] Modification to existing RRTYPE 466 C. Contact Information for submitter: 468 Name: Patrik Faltstrom 469 Email Address: paf@cisco.com 470 International telephone number: +46-8-6859131 471 Other contact handles: 472 (Note: This information will be publicly posted.) 474 D. Motivation for the new RRTYPE application? 476 There is no easy way to get from a domain name to a URI (or 477 IRI). Some mechanisms exists via use of the NAPTR [RFC3403] 478 resource record. That implies quite complicated rules that are 479 simplified via the S-NAPTR [RFC3958] specification. But, the 480 ability to directly look up a URI still exists. This 481 specification uses a prefix based naming mechanism originated in 482 the definition of the SRV [RFC2782] resource record, and the 483 RDATA is a URI, encoded as one text field. 485 See also above (Section 1). 487 E. Description of the proposed RR type. 489 The format of the URI resource record is as follows: 491 Ownername TTL Class URI Priority Weight Target 493 The URI RR has service information encoded in its ownername. In 494 order to encode the service for a specific owner name one uses 495 service parameters. Valid service parameters used are either 496 Enumservice Registrations registered by IANA, or prefixes used 497 for the SRV resource record. 499 The wire format of the RDATA is as follows: 501 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 502 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 503 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 504 | Priority | Weight | 505 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 506 / / 507 / Target / 508 / / 509 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 511 F. What existing RRTYPE or RRTYPEs come closest to filling that 512 need and why are they unsatisfactory? 514 The RRTYPE that come closest is the NAPTR resource record. It 515 is for example used in the DDDS and S-NAPTR algorithms. The 516 main problem with the NAPTR is that selection of what record (or 517 records) one is interested in is based on data stored in the 518 RDATA portion of the NAPTR resource record. This, as explained 519 in RFC 5507 [RFC5507], is not optimal for DNS lookups. Further, 520 most applications using NAPTR resource records uses regular 521 expression based rewrite rules for creation of the URI, and that 522 has shown be complicated to implement. 524 The second closest RRTYPE is the SRV record that given a 525 prefixed based naming just like is suggested for the URI 526 resource record, one get back a port number and domain name. 527 This can also be used for creation of a URI, but, only URIs 528 without path components. 530 G. What mnemonic is requested for the new RRTYPE (optional)? 532 URI 534 H. Does the requested RRTYPE make use of any existing IANA Registry 535 or require the creation of a new IANA sub-registry in DNS 536 Parameters? 538 Yes, partially. 540 One of the mechanisms to select a service is to use the 541 Enumservice Registry managed by IANA. Another is to use 542 services and protocols used for SRV records. 544 I. Does the proposal require/expect any changes in DNS servers/ 545 resolvers that prevent the new type from being processed as an 546 unknown RRTYPE (see [RFC3597])? 548 No 550 J. Comments: 552 None 554 Authors' Addresses 556 Patrik Faltstrom 557 Netnod 559 Email: paf@netnod.se 561 Olaf Kolkman 562 Internet Society 564 Email: kolkman@isoc.org