idnits 2.17.1 draft-faltstrom-uri-11.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 : ---------------------------------------------------------------------------- No issues found here. 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 (February 19, 2015) is 3353 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 477, but not defined ** Obsolete normative reference: RFC 6195 (Obsoleted by RFC 6895) Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 2 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, 3958 (if approved) O. Kolkman 5 Intended status: Standards Track ISOC 6 Expires: August 23, 2015 February 19, 2015 8 The Uniform Resource Identifier (URI) DNS Resource Record 9 draft-faltstrom-uri-11 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 3404 and RFC 3958. 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 August 23, 2015. 36 Copyright Notice 38 Copyright (c) 2015 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 . . . . . . . . . . . . . . . . . . . . . 8 69 10.1. Registration of the URI Resource Record Type . . . . . . 8 70 10.2. Registration of services . . . . . . . . . . . . . . . . 8 71 11. Security Considerations . . . . . . . . . . . . . . . . . . . 8 72 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 73 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 74 13.1. Normative References . . . . . . . . . . . . . . . . . . 9 75 13.2. Non-normative references . . . . . . . . . . . . . . . . 10 76 Appendix A. The original RRTYPE Allocation Request . . . . . . . 11 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 do the equivalence of selecting which ones of the 96 NAPTR records one is interested in, and have only those returned. 97 This because data in the service field of the NAPTR record is 98 included in the owner part of the URI resource record type. It is 99 also the case that as the URI resource record type include the target 100 URI directly as part of the RDATA, it is very easy to extract the 101 correct target URI, instead of applying rewrite rules as in NAPTR. 103 Querying for URI resource records is not replacing querying for NAPTR 104 resource records (or use of S-NAPTR [RFC3958]). Instead, the URI 105 resource record type provides a complementary mechanism to use when 106 one already knows what service field is interesting. With it, one 107 can directly query for the specific subset of the otherwise possibly 108 large RRSet given back when querying for NAPTR resource records. 110 This document updates RFC 3404 and RFC 3958 by adding the flag "D" to 111 the list of defined terminal flags in section 4.3 of RFC 3404 and 112 section 2.2.3 of RFC 3958. 114 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 115 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 116 document are to be interpreted as described in BCP 14, RFC 2119 117 [RFC2119]. 119 2. Applicability Statement 121 In general, it is expected that URI records will be used by clients 122 for applications where the relevant protocol to be used is known, 123 but, for example, an extra abstraction is needed in order to separate 124 a domain name from a point of service (as addressed by the URI). One 125 example of such a situation is when an organisation has many domain 126 names, but only one official web page. 128 Applications MUST know the specific service fields to prepend the 129 hostname with. Using repetitive queries for URI records MUST NOT be 130 a replacement for querying for NAPTR records according to the NAPTR 131 (DDDS) or S-NAPTR algorithms. NAPTR records serve the purpose to 132 discover the various services and URIs for looking up access points 133 for a given service. Those are two very different kinds of needs. 135 3. DNS considerations 137 Using prefix labels, such as underscored service tags, for a specific 138 owner name may cause a counter-intuitive effect when the owner name 139 is a wildcard name. For example, _s2._s1.*.example.net. is not a 140 wildcard name and cannot be used to return a synthesized answer for a 141 query name of _s2._s1.a.example.net. See Section 4.5 of RFC4592 142 [RFC4592] for more details. Besides, underscored service tags used 143 for the URI RR (based on the Service Name and Transport Protocol Port 144 Number Registry) may have slightly different semantics than service 145 tags used for underscored prefix labels that are used in combination 146 with other (yet unspecified) RR types. This may cause subtle 147 management problems when delegation structure that has developed 148 within the context of URI RRs is also to be used for other RR types. 149 Since the service labels might be overloaded, applications should 150 carefully check that the application level protocol is indeed the 151 protocol they expect. 153 Subtle management issues may also arise when the delegations from 154 service to sub service label involves several parties and different 155 stake holders. 157 4. The format of the URI RR 159 This is the presentation format of the URI RR: 161 Ownername TTL Class URI Priority Weight Target 163 The URI RR does not cause any kind of Additional Section processing. 165 4.1. Ownername, class and type 167 The URI ownername is subject to special conventions. 169 Just like the SRV RR [RFC2782] the URI RR has service information 170 encoded in its ownername. In order to encode the service for a 171 specific owner name one uses service parameters. Valid service 172 parameters used are those registered by IANA in the Service Name and 173 Transport Protocol Port Number Registry [RFC6335], or as Enumservice 174 Registrations [RFC6117]. The Enumservice Registration parameters are 175 reversed (subtype(s) before type), prepended with an underscore (_) 176 and prepended to the owner name in separate labels. The underscore 177 is prepended to the service parameters to avoid collisions with DNS 178 labels that occur in nature, and the order is reversed to make it 179 possible to do delegations, if needed, to different zones (and 180 therefore providers of DNS). 182 For example, suppose we are looking for the URI for a service with 183 ENUM Service Parameter "A:B:C" for host example.com. Then we would 184 query for (QNAME,QTYPE)=("_C._B._A.example.com","URI") 186 As another example, suppose we are looking for the URI for a service 187 with Service Name "A" and Transport Protocol "B" for host 188 example.com. Then we would query for 189 (QNAME,QTYPE)=("_A._B.example.com","URI") 190 The type number for the URI record is 256. 192 The URI resource record is class independent. 194 The URI RR has no special TTL requirements. 196 4.2. Priority 198 The priority of the target URI in this RR. Its range is 0-65535. A 199 client MUST attempt to contact the URI with the lowest-numbered 200 priority it can reach; URIs with the same priority SHOULD be tried in 201 the order defined by the weight field. 203 4.3. Weight 205 A server selection mechanism. The weight field specifies a relative 206 weight for entries with the same priority. Larger weights SHOULD be 207 given a proportionately higher probability of being selected. The 208 range of this number is 0-65535. 210 4.4. Target 212 The URI of the target, enclosed in double-quote characters ('"'). 213 Resolution of the URI is according to the definitions for the Scheme 214 of the URI. 216 Since the URI will not be encoded as a (see 217 RFC1035 section 3.3 [RFC1035]) there is no 255 character size 218 limitation. 220 The Target MUST NOT be empty (""). 222 4.5. URI RDATA Wire Format 224 The RDATA for a URI RR consists of a 2 octet Priority field, a two 225 octet Weight field, and a variable length target field. 227 Priority and Weight are unsigned integers in network byte order. 229 The remaining data in the RDATA contains the Target field. The 230 Target field contains the URI as a sequence of octets (without the 231 enclosing double- quote characters used in the presentation format). 233 The Target field can also contain an IRI, but with the additional 234 requirements that it are in UTF-8 [RFC3629], and the requirement that 235 it be possible to convert to a URI according to section 3.1 of RFC 236 3987 [RFC3987] and back again to an IRI according to section 3.2. 237 Other character sets than UTF-8 are not allowed. The domain name 238 part of the IRI can be either an U-LABEL or A-LABEL as defined in RFC 239 5890 [RFC5890]. 241 The length of the target field MUST be greater than zero. 243 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 244 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 245 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 246 | Priority | Weight | 247 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 248 / / 249 / Target / 250 / / 251 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 253 5. Definition of the flag 'D' for NAPTR records 255 This document specifies the flag "D" for use as a flag in NAPTR 256 records. The flag indicate a terminal NAPTR record because it 257 denotes the end of the DDDS/NAPTR processing rules. In the case of a 258 "D" flag, the Replacement field in the NAPTR record, prepended with 259 the service flags, is used as the Owner of a DNS query for URI 260 records, and normal URI processing as defined in this document is 261 applied. 263 The replacement field MUST NOT include any of the service parameters. 264 Those are to be prepended (together with underscore) as described in 265 other places in this document. 267 The Regexp field in the NAPTR record MUST be empty when the 'D' flag 268 is in use. 270 6. Examples 272 6.1. Homepage at one domain, but two domains in use 274 An organisation has the domain names example.com and example.net, but 275 the official URI http://www.example.com/path. Given the Service Name 276 "http" and Trabsport Protocol "tcp" (from the IANA registry of 277 Service Name and Transport Protocol Port Numbers), the following URI 278 Resource Records could be made available in the respective zones 279 (example.com and example.net): 281 $ORIGIN example.com. 282 _http._tcp IN URI 10 1 "http://www.example.com/path" 284 $ORIGIN example.net. 285 _http._tcp IN URI 10 1 "http://www.example.com/path" 287 7. Relation to S-NAPTR 289 The URI resource record type is not a replacement for the S-NAPTR. 290 It is instead an extension and the second step of the S-NAPTR 291 resolution can resolve a URI resource record instead of using SRV 292 records and yet another algorithm for how to use SRV records for the 293 specific protocol. 295 $ORIGIN example.com. 296 ;; order pref flags 297 IN NAPTR 100 10 "D" "EM:ProtA" ( ; service 298 "" ; regexp 299 _http._tcp.example.com. ; replacement 300 _http._tcp IN URI 10 1 "http://www.example.com/path" 302 8. Relation to U-NAPTR 304 The URI Resource Record Type, together with S-NAPTR, can be viewed as 305 a replacement for U-NAPTR [RFC4848]. The URI Resource Record Type is 306 though only interesting when one know a base domain name, a protocol 307 and service so that one can compose the record to look up. NAPTR 308 records of any kind are used to look up what services exists for a 309 certain domain, which is one step before the URI resource record is 310 used. 312 9. Relation to SRV 314 The URI Resource Record Type can be viewed as a replacement for the 315 SRV record. This because it like the SRV record can only be looked 316 up if one know the base domain, the protocol and the service. It has 317 a similar functionality, and uses the same registry for Service 318 Names, but instead of returning a hostname and port number, the URI 319 record return a full URI. As such, it can be viewed as a more 320 powerful resource record than SRV. 322 10. IANA Considerations 324 10.1. Registration of the URI Resource Record Type 326 After an expert review in February 2011 (see Appendix A) IANA has 327 allocated RRTYPE 256 for the URI Resource Record Type in the registry 328 named Resource Record (RR) TYPEs and QTYPEs as defined in BCP 42 (at 329 the time RFC 6195 [RFC6195]), located at 330 http://www.iana.org/assignments/dns-parameters. 332 IANA is requested to update the reference with that registration to 333 this RFC. 335 10.2. Registration of services 337 No new registry is needed for the registration of services as the 338 Service Name and Transport Protocol Port Numbers and Enumservices 339 registry are used also for the URI resource record type. 341 11. Security Considerations 343 The authors do not believe this resource record cause any new 344 security problems. Deployment must though be done in a proper way as 345 misconfiguration of this resource record might make it impossible to 346 reach the service that was originally intended to be accessed. 348 Using the URI resource record together with security mechanisms that 349 relies on verification of authentication of hostnames, like TLS, 350 makes it important to choose the correct domain name when doing the 351 comparison. 353 The basic mechanism works as follows: 355 1. Announce the fact example.com is hosted at example.org (with 356 some URL) in DNS 358 2. Secure the URI resource record with DNSSEC. 360 3. Verify the TLS (for example) certificate for the connection to 361 example.org matches, i.e. use the hostname in the URI and not 362 the hostname used originally when looking up the URI resource 363 record. 365 4. If needed, do application layer authentication etc over the then 366 encrypted connection. 368 What also can happen is that the URI in the resource record type has 369 errors in it. Applications using the URI resource record type for 370 resolution should behave similarly as if the user typed (or copy and 371 pasted) the URI. At least it must be clear to the user that the 372 error is not due to any error from his side. 374 One SHOULD NOT include userinfo (see User Information, Section 3.2.1, 375 in RFC 3986 [RFC3986]) in a URI that is used in a URI resource record 376 as DNS data must be viewed as publicly available information. 378 12. Acknowledgements 380 Ideas on how to split the two different kind of queries "What 381 services exists for this domain name" and "What is the URI for this 382 service" came from Scott Bradner and Lawrence Conroy. Other people 383 that have contributed to this document include Richard Barnes, Leslie 384 Daigle, Olafur Gudmundsson, Ted Hardie, Evan Hunt, Peter Koch, Mark 385 Nottingham, Penn Pfautz, Jinmei Tatuya and Willem Toorop. 387 Cisco is acknowledged as mr Faltstrom's employer at the time this 388 document was developed. 390 The NLnet Labs is acknowledged as mr Kolkman's employer at the time 391 this document was developed. 393 13. References 395 13.1. Normative References 397 [RFC1035] Mockapetris, P., "Domain names - implementation and 398 specification", STD 13, RFC 1035, November 1987. 400 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 401 Requirement Levels", BCP 14, RFC 2119, March 1997. 403 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 404 10646", STD 63, RFC 3629, November 2003. 406 [RFC3958] Daigle, L. and A. Newton, "Domain-Based Application 407 Service Location Using SRV RRs and the Dynamic Delegation 408 Discovery Service (DDDS)", RFC 3958, January 2005. 410 [RFC3987] Duerst, M. and M. Suignard, "Internationalized Resource 411 Identifiers (IRIs)", RFC 3987, January 2005. 413 [RFC5890] Klensin, J., "Internationalized Domain Names for 414 Applications (IDNA): Definitions and Document Framework", 415 RFC 5890, August 2010. 417 [RFC6117] Hoeneisen, B., Mayrhofer, A., and J. Livingood, "IANA 418 Registration of Enumservices: Guide, Template, and IANA 419 Considerations", RFC 6117, March 2011. 421 [RFC6195] Eastlake, D., "Domain Name System (DNS) IANA 422 Considerations", RFC 6195, March 2011. 424 [RFC6335] Cotton, M., Eggert, L., Touch, J., Westerlund, M., and S. 425 Cheshire, "Internet Assigned Numbers Authority (IANA) 426 Procedures for the Management of the Service Name and 427 Transport Protocol Port Number Registry", BCP 165, RFC 428 6335, August 2011. 430 13.2. Non-normative references 432 [RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for 433 specifying the location of services (DNS SRV)", RFC 2782, 434 February 2000. 436 [RFC3401] Mealling, M., "Dynamic Delegation Discovery System (DDDS) 437 Part One: The Comprehensive DDDS", RFC 3401, October 2002. 439 [RFC3403] Mealling, M., "Dynamic Delegation Discovery System (DDDS) 440 Part Three: The Domain Name System (DNS) Database", RFC 441 3403, October 2002. 443 [RFC3404] Mealling, M., "Dynamic Delegation Discovery System (DDDS) 444 Part Four: The Uniform Resource Identifiers (URI)", RFC 445 3404, October 2002. 447 [RFC3597] Gustafsson, A., "Handling of Unknown DNS Resource Record 448 (RR) Types", RFC 3597, September 2003. 450 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 451 Resource Identifier (URI): Generic Syntax", STD 66, RFC 452 3986, January 2005. 454 [RFC4592] Lewis, E., "The Role of Wildcards in the Domain Name 455 System", RFC 4592, July 2006. 457 [RFC4848] Daigle, L., "Domain-Based Application Service Location 458 Using URIs and the Dynamic Delegation Discovery Service 459 (DDDS)", RFC 4848, April 2007. 461 [RFC5507] IAB, Faltstrom, P., Austein, R., and P. Koch, "Design 462 Choices When Expanding the DNS", RFC 5507, April 2009. 464 Appendix A. The original RRTYPE Allocation Request 466 On February 22, 2011 IANA assigned RRTYPE 256 for the URI resource 467 record based on a request that followed the procedure documented in 468 RFC 6195 [RFC6195]. The DNS RRTYPE PARAMETER ALLOCATION form as 469 submitted to IANA at thet time is replicated below for reference. 471 A. Submission Date: 473 May 23, 2009 475 B. Submission Type: 477 [X] New RRTYPE 478 [ ] Modification to existing RRTYPE 480 C. Contact Information for submitter: 482 Name: Patrik Faltstrom 483 Email Address: paf@cisco.com 484 International telephone number: +46-8-6859131 485 Other contact handles: 486 (Note: This information will be publicly posted.) 488 D. Motivation for the new RRTYPE application? 490 There is no easy way to get from a domain name to a URI (or 491 IRI). Some mechanisms exists via use of the NAPTR [RFC3403] 492 resource record. That implies quite complicated rules that are 493 simplified via the S-NAPTR [RFC3958] specification. But, the 494 ability to directly look up a URI still exists. This 495 specification uses a prefix based naming mechanism originated in 496 the definition of the SRV [RFC2782] resource record, and the 497 RDATA is a URI, encoded as one text field. 499 See also above (Section 1). 501 E. Description of the proposed RR type. 503 The format of the URI resource record is as follows: 505 Ownername TTL Class URI Priority Weight Target 507 The URI RR has service information encoded in its ownername. In 508 order to encode the service for a specific owner name one uses 509 service parameters. Valid service parameters used are either 510 Enumservice Registrations registered by IANA, or prefixes used 511 for the SRV resource record. 513 The wire format of the RDATA is as follows: 515 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 516 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 517 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 518 | Priority | Weight | 519 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 520 / / 521 / Target / 522 / / 523 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 525 F. What existing RRTYPE or RRTYPEs come closest to filling that 526 need and why are they unsatisfactory? 528 The RRTYPE that come closest is the NAPTR resource record. It 529 is for example used in the DDDS and S-NAPTR algorithms. The 530 main problem with the NAPTR is that selection of what record (or 531 records) one is interested in is based on data stored in the 532 RDATA portion of the NAPTR resource record. This, as explained 533 in RFC 5507 [RFC5507], is not optimal for DNS lookups. Further, 534 most applications using NAPTR resource records uses regular 535 expression based rewrite rules for creation of the URI, and that 536 has shown be complicated to implement. 538 The second closest RRTYPE is the SRV record that given a 539 prefixed based naming just like is suggested for the URI 540 resource record, one get back a port number and domain name. 541 This can also be used for creation of a URI, but, only URIs 542 without path components. 544 G. What mnemonic is requested for the new RRTYPE (optional)? 545 URI 547 H. Does the requested RRTYPE make use of any existing IANA Registry 548 or require the creation of a new IANA sub-registry in DNS 549 Parameters? 551 Yes, partially. 553 One of the mechanisms to select a service is to use the 554 Enumservice Registry managed by IANA. Another is to use 555 services and protocols used for SRV records. 557 I. Does the proposal require/expect any changes in DNS servers/ 558 resolvers that prevent the new type from being processed as an 559 unknown RRTYPE (see RFC 3597 [RFC3597])? 561 No 563 J. Comments: 565 None 567 Authors' Addresses 569 Patrik Faltstrom 570 Netnod 572 Email: paf@netnod.se 574 Olaf Kolkman 575 Internet Society 577 Email: kolkman@isoc.org