idnits 2.17.1 draft-cheshire-dnsext-nias-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing document type: Expected "INTERNET-DRAFT" in the upper left hand corner of the first page ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. == There are 2 instances of lines with private range IPv4 addresses in the document. If these are generic example addresses, they should be changed to use any of the ranges defined in RFC 6890 (or successor): 192.0.2.x, 198.51.100.x or 203.0.113.x. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 212: '...than one SRV is returned, clients MUST...' Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 369 has weird spacing: '...ple.com name...' == Line 370 has weird spacing: '...ple.com name...' == Line 371 has weird spacing: '...ple.com name...' == Line 378 has weird spacing: '...ple.com name ...' == Line 388 has weird spacing: '...ple.com inte...' -- 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 (July 2001) is 8322 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: 'RFC 1034' is mentioned on line 126, but not defined == Missing Reference: 'RFC 1033' is mentioned on line 126, but not defined ** Obsolete normative reference: RFC 2279 (Obsoleted by RFC 3629) ** Obsolete normative reference: RFC 2535 (Obsoleted by RFC 4033, RFC 4034, RFC 4035) == Outdated reference: A later version (-12) exists of draft-ietf-zeroconf-reqts-08 ** Downref: Normative reference to an Informational draft: draft-ietf-zeroconf-reqts (ref. 'ZC') == Outdated reference: A later version (-01) exists of draft-ietf-zeroconf-host-prof-00 -- Possible downref: Normative reference to a draft: ref. 'ZCHP' Summary: 8 errors (**), 0 flaws (~~), 11 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Stuart Cheshire 2 Document: draft-cheshire-dnsext-nias-00.txt Apple Computer 3 Expires 13th January 2002 13th July 2001 5 Discovering Named Instances of Abstract Services using DNS 7 9 Status of this Memo 11 This document is an Internet-Draft and is in full conformance with 12 all provisions of Section 10 of RFC2026. Internet-Drafts are 13 working documents of the Internet Engineering Task Force (IETF), 14 its areas, and its working groups. Note that other groups may 15 also distribute working documents as Internet-Drafts. 17 Internet-Drafts are draft documents valid for a maximum of six 18 months and may be updated, replaced, or obsoleted by other documents 19 at any time. It is inappropriate to use Internet-Drafts as 20 reference material or to cite them other than as "work in progress." 22 The list of current Internet-Drafts can be accessed at 23 http://www.ietf.org/ietf/1id-abstracts.txt 25 The list of Internet-Draft Shadow Directories can be accessed at 26 http://www.ietf.org/shadow.html 28 Distribution of this memo is unlimited. 30 Abstract 32 This document proposes a convention for naming and structuring DNS 33 resource records that allows clients to discover a list of named 34 instances of a particular given desired type of service. 36 1. Acknowledgements 38 This concepts described in this draft have been explored and 39 developed with help from Bill Woodcock, Erik Guttman, and others. 41 2. Introduction 43 This is a rough first draft. Its purpose is to describe the proposed 44 idea well enough for meaningful discussion to take place. As such, 45 while feedback concerning typographical mistakes and similar minutiae 46 is always appreciated, the reader is advised that it is probably 47 unwise to waste a lot of time on such trivia until after we find out 48 whether this proposal will even live long enough to become a 49 'draft-01'. 51 This document proposes a convention for naming and structuring DNS 52 resource records that allows clients to discover a list of named 53 instances of a particular given desired type of service. 55 This document proposes no change to the structure of DNS messages, 56 and no new operation codes, response codes, resource record types, or 57 any other new DNS protocol values. This document simply proposes a 58 convention for how existing resource record types can be named and 59 structured to facilitate service discovery. 61 This proposal is entirely compatible with today's existing unicast 62 DNS server and client software. 64 This proposal is also compatible with the proposal for Multicast DNS 65 outlined in "Performing DNS queries via IP Multicast" [mDNS-SC]. 67 3. Design Goals 69 A good service discovery protocol needs to have three properties: 71 (i) The ability to query for services of a certain type in a certain 72 logical domain and receive in response a list of named instances 73 (network browsing, or "Service Instance Enumeration"). 75 (ii) Given a particular named instance, the ability to efficiently 76 resolve that instance name to the required information a client needs 77 to actually use the service, i.e. IP address and port number, at the 78 very least (Service Name Resolution). 80 (iii) Instance names should be relatively persistent. If a user 81 selects their default printer from a list of available choices today, 82 then tomorrow they should still be able to print on that printer -- 83 even if the IP address and/or port number where the service resides 84 have changed -- without the user (or their software) having to repeat 85 the network browsing step a second time. 87 These goals are discussed in detail below. 89 In addition, if it is to become successful, a service discovery 90 protocol should be simple enough to implement that virtually any 91 device capable of implementing IP should not have any trouble 92 implementing the service discovery software as well. 94 4. Service Instance Enumeration 96 DNS SRV records [RFC 2782] are useful for locating instances of a 97 particular type of service when all the instances are effectively 98 indistinguishable and provide the same service to the client. 100 For example, SRV records with the (hypothetical) name 101 "_http._tcp.example.com." would allow a client to discover a list of 102 all servers implementing the "_http._tcp" service (i.e. Web servers) 103 for the "example.com." domain. The unstated assumption is that all 104 these servers offer an identical set of Web pages, and it doesn't 105 matter to the client which of the servers it uses, as long as it 106 selects one at random according to the weight and priority rules laid 107 out in RFC 2782. 109 Instances of other kinds of service are less easily interchangeable. 110 If a word processing application were to look up the (hypothetical) 111 SRV record "_lpr._tcp.example.com." to find the list of printers at 112 Example Co., then picking one at random and printing on it would 113 probably not be what the user wanted. 115 This proposal borrows the logical service naming syntax and semantics 116 from DNS SRV records, but adds one level of indirection. Instead of 117 requesting records of type "SRV" with name "_lpr._tcp.example.com.", 118 the client requests records of type "PTR" (pointer from one name in 119 the DNS namespace to another). The result of this PTR lookup is a 120 list of zero or more Service Instance Names of the form: 122 Service Instance Name = . . 124 The portion of the name is a single DNS label, containing 125 arbitrary UTF-8-encoded text [RFC 2279]. DNS recommends guidelines 126 for allowable characters for host names [RFC 1034][RFC 1033], but 127 Service Instance Names are not host names. Service Instance Names are 128 not intended to ever be typed in by a normal user; the user selects a 129 Service Instance Name by selecting it from a list of choices 130 presented on the screen. Note that just because this protocol 131 supports arbitrary UTF-8-encoded names doesn't mean that any 132 particular user or administrator setting up a service is obliged to 133 name that service using any characters outside the standard US-ASCII 134 range. 136 The names resulting from the PTR lookup are presented to the user in 137 a list for the user to select one (or more). Having chosen the 138 desired named instance, the Service Instance Name may then be 139 used immediately, or saved away in some persistent user-preference 140 data structure for future use. 142 DNS labels are limited to 63 octets in length. UTF-8 encoding can 143 require up to six octets per 31-bit UCS-4 character, which means that 144 in the worst case, the portion of a name could be limited 145 to ten characters. However, the UCS-4 characters with longer UTF-8 146 encodings tend to be the ones which convey greater meaning. A printer 147 name consisting of ten ancient Egyptian Hieroglyphs may well be far 148 more descriptive (to an ancient Egyptian) than a name written in 149 English consisting of just 63 characters. 151 I welcome input from the IDN Working Group about whether this method 152 of encoding international text is the most appropriate for this 153 particular usage. 155 There have been proposals to keep the true DNS name of the service 156 typically terse and cryptic, and to use a TXT records attached to 157 that DNS name to hold the 'user-friendly' name which is displayed to 158 the user. The problem with this is that it decouples user perception 159 from reality. Two different instances of services with different DNS 160 names could inadvertently have the same TXT record name, which could 161 be very confusing to users. Maintaining a tight one-to-one mapping 162 between the true DNS name and the 'user-friendly' name as displayed 163 on the screen avoids these anomalies. 165 There have been questions about why services are not named using 166 Service Instance Names of the form: . . 168 There are three reasons why it is beneficial to name service 169 instances as: 171 Service Instance Name = . . 173 The first reason is that, the logical decomposition is that a domain 174 has various services; a service has various instances of that 175 service. It does not make sense to say that an instance has various 176 services. These are not host names. The usage model is not, first, 177 what's the name of the host, and then second, what services is it 178 running? The usage model is, first, what's the name of the service, 179 and then second, what are the names of the specific instances of that 180 service? 182 The second reason is that, when a DNS response contains multiple 183 answers, name compression works more effectively if all the names 184 contain a common suffix. If all the answers in the packet have the 185 same and , then each PTR's rdata only has to 186 give the part followed by a two-byte compression pointer. 188 The third reason is that, this allows subdomains to be delegated 189 along logical service boundaries. For example, the network 190 administrator at Example Co. could choose to delegate the 191 _lpr._tcp.example.com subdomain to a particular machine that has the 192 responsibility to know about all the printers at Example Co. If the 193 service name were the least significant component of the Service 194 Instance Name, then there would be no way to separate the printers 195 from the file servers. 197 5. Service Name Resolution 199 Given a particular Service Instance Name, when a client needs to 200 contact that service, it sends a DNS request for the SRV record of 201 that name. 203 The result of the DNS request is a SRV record giving the port number 204 and target host where the service may be found. 206 In some environments such as Zeroconf, the host providing the named 207 service may itself not have a well-defined host name. In this case, 208 the 'target' name in the SRV record may simply repeat the same name 209 as the SRV record itself, with an address record attached to the same 210 name giving the appropriate IP address. 212 In the event that more than one SRV is returned, clients MUST 213 correctly interpret the priority and weight fields -- i.e. Lower 214 numbered priority servers should be used in preference to higher 215 numbered priority servers, and servers with equal priority should be 216 selected randomly in proportion to their relative weights. 218 Some services discovered via Service Instance Enumeration may need 219 more than just an IP address and port number to properly identify the 220 service. For example, printing via lpr typically specifies a queue 221 name. A file server may have multiple volumes, each identified by its 222 own volume name. A Web server typically has multiple pages, each 223 identified by its own URL. In these cases, the necessary additional 224 data is stored in a TXT record with the same name as the SRV record. 225 The specific nature of that additional data, and how it is to be 226 used, is service-dependent. 228 6. Selective Queries 230 This proposal does not attempt to define an arbitrary query language 231 for service discovery, nor do we believe one is necessary. 233 However, there are some circumstances where narrowing the list of 234 results may be useful. A printing client that wishes to discover only 235 printers that accept Postscript over lpr over TCP should issue a PTR 236 query for the name "_postscript._lpr._tcp.example.com." Only printers 237 that support Postscript should register this PTR record pointing to 238 their name. 240 Note that the printer's Service Instance Name which this PTR record 241 points to is unchanged -- it is still something of the form 242 "ThePrinter._lpr._tcp.example.com." The domain in which printer SRV 243 records are registered defines the namespace within which printer 244 names are unique. Additional subtypes (e.g. "_postscript") of the 245 basic service type (e.g. "_lpr._tcp") serve to narrow the list of 246 results, not to create more namespace. 248 The list of possible subtypes, if any, and the additional data stored 249 in TXT records, if any, are defined separately for each basic service 250 type. 252 7. Populating the DNS with information. 254 How the SRV and PTR records that describe services and allow them to 255 be enumerated make their way into the DNS is outside the scope of 256 this document. However, it can happen easily in any of a number of 257 ways, for example: 259 On some networks, the administrator might manually enter the records 260 into the name server's configuration file. 262 A network monitoring tool could output a standard zone file to be 263 read into a conventional DNS server. 265 Future IP printers could use Dynamic DNS Update [RFC 2136] to 266 automatically register their SRV and PTR records with the DNS server. 268 A printer manager device which has knowledge of printers on the 269 network through some other management protocol could also use Dynamic 270 DNS Update [RFC 2136]. 272 Alternatively, a printer manager device could implement enough of the 273 DNS protocol that it is able to answer DNS requests directly, and 274 Example Co.'s main DNS server could delegate the 275 _lpr._tcp.example.com subdomain to the printer manager device. 277 Zeroconf printers on an unconfigured ad-hoc network answer Multicast 278 DNS requests on their own behalf for appropriate PTR and SRV names 279 within the "local.arpa." domain [mDNS-SC]. 281 8. Relationship to Multicast DNS 283 This proposal is not strictly related to Multicast DNS, but the two 284 are highly complementary, particularly in Zeroconf environments [ZC]. 286 Lookups for PTR records of the form ".local.arpa." are 287 defined to use multicast, and return a list of named instances of the 288 form "..local.arpa." 290 In Zeroconf environments where state can be transient and 291 configuration information like IP addresses can change at any time, 292 the DNS TTL on SRV and A records should be short, on the order of 293 seconds. However, the DNS TTL on the PTR records pointing to those 294 SRV names should be long, on the order of hours or days, so that once 295 a name has been displayed in some other host's network browser 296 window, the browsing client doesn't have to keep repeatedly asking 297 for the PTR record to make sure it hasn't disappeared. 299 9. Comparison to Alternative Service Discovery Protocols 301 At the present time there are many proposed ways to do network 302 service discovery. 304 The advantage of using DNS is that it makes use of existing software, 305 protocols, infrastructure, and expertise. Existing network analyser 306 tools already know how to decode and display DNS packets for network 307 debugging. 309 For ad-hoc networks such as Zeroconf environments, peer-to-peer 310 multicast protocols are appropriate. It is almost certain that the 311 Zeroconf host profile [ZCHP] will specify the use of Multicast DNS 312 for host name resolution in the absence of DNS servers. Given that 313 Zeroconf hosts will have to implement Multicast DNS anyway, it makes 314 sense for them to also perform service discovery using that same 315 Multicast DNS software instead of also having to implement an 316 entirely different service discovery protocol. 318 In larger networks, a high volume of enterprise-wide IP multicast 319 traffic may not be desirable, so any credible service discovery 320 protocol intended for larger networks has to provide some facility to 321 aggregate registrations and lookups at a central server (or servers) 322 instead of working exclusively using multicast. This requires some 323 service discovery aggregation server software to be written, 324 debugged, deployed, and maintained. This also requires some service 325 discovery registration protocol to be implemented and deployed for 326 clients to register with the central aggregation server. Virtually 327 every company with an IP network already runs DNS server, and DNS 328 already has a dynamic registration protocol [RFC 2136]. Given that 329 virtually every company already has to operate and maintain a DNS 330 server anyway, it makes sense to take advantage of this instead of 331 also having to learn, operate and maintain a different service 332 registration server. 334 Service discovery needs to be able to provide appropriate security. 335 DNS already has existing mechanisms for security [RFC 2535]. 337 In summary: 339 Service discovery requires a central aggregation server. 340 DNS already has one: It's called a DNS server. 342 Service discovery requires a service registration protocol. 343 DNS already has one: It's called DNS Dynamic Update. 345 Service discovery requires a security model. 346 DNS already has one: It's called DNSSEC. 348 Service discovery requires a query protocol 349 DNS already has one: It's called DNS. 351 Service discovery requires a multicast mode for ad-hoc networks. 352 DNS doesn't have one right now, but it will soon, to meet Zeroconf 353 requirements. 355 It makes more sense to use the existing software that every network 356 needs already, instead of deploying an entire parallel system just 357 for service discovery. 359 10. Real Example 361 The following examples were prepared using standard unmodified 362 nslookup and standard unmodified BIND running on GNU/Linux. 363 Note: In real life, this information is obtained using graphical 364 network browser software, not command-line tools. 366 10.1 Question: What printers do we have at example.com? 368 nslookup -q=ptr _lpr._tcp.example.com 369 _lpr._tcp.example.com name = Sales._lpr._tcp.example.com 370 _lpr._tcp.example.com name = Marketing._lpr._tcp.example.com 371 _lpr._tcp.example.com name = Engineering._lpr._tcp.example.com 373 Answer: We have three, called Sales, Marketing, and Engineering. 375 10.2 Question: What postscript printers do we have at example.com? 377 nslookup -q=ptr _postscript._lpr._tcp.example.com 378 _postscript._lpr._tcp.example.com name = Sales._lpr._tcp.example.com 380 Answer: Only Sales is a postscript printer. 382 10.3 Question: How do I print on Sales? 384 nslookup -q=any Sales._lpr._tcp.example.com 385 Sales._lpr._tcp.example.com text = "SPQ" 386 Sales._lpr._tcp.example.com priority = 0, weight = 0, port= 49152 387 host = bigserver.example.com 388 bigserver.example.com internet address = 10.1.2.3 390 Answer: You need to connect to 10.1.2.3, port 49152, queue name "SPQ" 392 11. IPv6 Considerations 394 IPv6 has no significant differences, except that the address of the 395 SRV record's target host is given by the appropriate IPv6 address 396 records instead of the IPv4 "A" record. 398 12. Security Considerations 400 DNSSEC [RFC 2535] should be used where the authenticity of 401 information is important. 403 13. IANA Considerations 405 The IANA will have to allocate symbolic service/protocol names, much 406 as they allocate TCP port numbers today. However, the textual nature 407 of service/protocol names means that there are almost infinitely many 408 more of them available than the finite set of 65535 possible port 409 numbers. It may also be appropriate to allow use of temporary 410 self-assigned service/protocol names, much like the "x-foo/bar" 411 self-assigned experimental MIME types. 413 14. Copyright 415 Copyright (C) The Internet Society 8th March 2000. 416 All Rights Reserved. 418 This document and translations of it may be copied and furnished to 419 others, and derivative works that comment on or otherwise explain it 420 or assist in its implementation may be prepared, copied, published 421 and distributed, in whole or in part, without restriction of any 422 kind, provided that the above copyright notice and this paragraph are 423 included on all such copies and derivative works. However, this 424 document itself may not be modified in any way, such as by removing 425 the copyright notice or references to the Internet Society or other 426 Internet organizations, except as needed for the purpose of 427 developing Internet standards in which case the procedures for 428 copyrights defined in the Internet Standards process must be 429 followed, or as required to translate it into languages other than 430 English. 432 The limited permissions granted above are perpetual and will not be 433 revoked by the Internet Society or its successors or assigns. 435 This document and the information contained herein is provided on an 436 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 437 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 438 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 439 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 440 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 442 15. References 444 [mDNS-SC] S. Cheshire, "Performing DNS queries via IP Multicast", 445 Internet-Draft (work in progress), 446 draft-cheshire-dnsext-multicastdns-00.txt, July 2001. 448 [RFC 2136] P. Vixie, et al., "Dynamic Updates in the Domain Name 449 System (DNS UPDATE)", RFC 2136, April 1997. 451 [RFC 2279] F. Yergeau, "UTF-8, a transformation format of ISO 10646", 452 RFC 2279, January 1998. 454 [RFC 2535] D. Eastlake, "Domain Name System Security Extensions", 455 RFC 2535, March 1999. 457 [RFC 2782] A. Gulbrandsen, et al., "A DNS RR for specifying the 458 location of services (DNS SRV)", RFC 2782, February 2000. 460 [ZC] M. Hattig, "Zeroconf Requirements", Internet-Draft (work 461 in progress), draft-ietf-zeroconf-reqts-08.txt, May 2001. 463 [ZCHP] E. Guttman, "Zeroconf Host Profile", Internet-Draft (work 464 in progress), draft-ietf-zeroconf-host-prof-00.txt, July 465 2001. 467 16. Author's Address 469 Stuart Cheshire 470 Apple Computer, Inc. 471 1 Infinite Loop 472 Cupertino 473 California 95014 474 USA 476 Phone: +1 408 974 3207 477 EMail: rfc@stuartcheshire.org 479 Stuart Cheshire 480 * Wizard Without Portfolio, Apple Computer 481 * Chairman, IETF ZEROCONF 482 * www.stuartcheshire.org