idnits 2.17.1 draft-ietf-ids-dnsnames-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-26) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == 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 an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There is 1 instance of too long lines in the document, the longest one being 3 characters in excess of 72. ** The abstract seems to contain references ([3], [4], [5], [1,2]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. == There are 5 instances of lines with non-RFC2606-compliant FQDNs in the document. == There are 1 instance of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The "Author's Address" (or "Authors' Addresses") section title is misspelled. == Line 170 has weird spacing: '... archie arc...' -- 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 1996) is 10116 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) ** Downref: Normative reference to an Informational RFC: RFC 1436 (ref. '4') ** Downref: Normative reference to an Informational RFC: RFC 1945 (ref. '5') ** Obsolete normative reference: RFC 793 (ref. '6') (Obsoleted by RFC 9293) ** Obsolete normative reference: RFC 974 (ref. '8') (Obsoleted by RFC 2821) ** Obsolete normative reference: RFC 1590 (ref. '10') (Obsoleted by RFC 2045, RFC 2046, RFC 2047, RFC 2048, RFC 2049) ** Obsolete normative reference: RFC 1700 (ref. '11') (Obsoleted by RFC 3232) ** Obsolete normative reference: RFC 1777 (ref. '13') (Obsoleted by RFC 3494) ** Obsolete normative reference: RFC 1305 (ref. '14') (Obsoleted by RFC 5905) ** Obsolete normative reference: RFC 1714 (ref. '15') (Obsoleted by RFC 2167) ** Obsolete normative reference: RFC 954 (ref. '16') (Obsoleted by RFC 3912) -- Possible downref: Non-RFC (?) normative reference: ref. '17' -- Possible downref: Non-RFC (?) normative reference: ref. '18' -- Possible downref: Non-RFC (?) normative reference: ref. '19' ** Obsolete normative reference: RFC 977 (ref. '20') (Obsoleted by RFC 3977) ** Downref: Normative reference to an Informational RFC: RFC 1625 (ref. '21') -- Possible downref: Non-RFC (?) normative reference: ref. '22' Summary: 22 errors (**), 0 flaws (~~), 5 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IDS Working Group Martin Hamilton 3 INTERNET-DRAFT Loughborough University 4 Russ Wright 5 Lawrence Berkeley Laboratory 6 August 1996 8 Use of DNS Aliases for Network Services 9 Filename: draft-ietf-ids-dnsnames-01.txt 11 Status of this Memo 13 This document is an Internet-Draft. Internet-Drafts are working 14 documents of the Internet Engineering Task Force (IETF), its 15 areas, and its working groups. Note that other groups may also 16 distribute working documents as Internet-Drafts. 18 Internet-Drafts are draft documents valid for a maximum of six 19 months and may be updated, replaced, or obsoleted by other 20 documents at any time. It is inappropriate to use Internet- 21 Drafts as reference material or to cite them other than as ``work 22 in progress.'' 24 To learn the current status of any Internet-Draft, please check 25 the ``1id-abstracts.txt'' listing contained in the Internet- 26 Drafts Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net 27 (Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East 28 Coast), or ftp.isi.edu (US West Coast). 30 Distribution of this document is unlimited. Editorial comments 31 should be sent directly to the authors. Technical discussion will 32 take place on the IETF Integrated Directory Services mailing list, 33 ietf-ids@umich.edu. 35 This Internet Draft expires February 12th, 1997. 37 Abstract 39 It has become a common practice to use symbolic names (usually 40 CNAMEs) in the Domain Name Service (DNS - [1,2]) to refer to network 41 services such as anonymous FTP [3] servers, Gopher [4] servers, and 42 most notably World-Wide Web HTTP [5] servers. This is desirable for 43 a number of reasons. It provides a way of moving services from one 44 machine to another transparently, and a mechanism by which people or 45 agents may programatically discover that an organization runs, say, a 46 World-Wide Web server. 48 Although this approach has been almost universally adopted, there is 49 no standards document or similar specification for these commonly 50 used names. This document seeks to rectify this situation by 51 gathering together the extant "folklore" on naming conventions, and 52 proposes a mechanism for accommodating new protocols. 54 It is important to note that these naming conventions do not provide 55 a complete long term solution to the problem of finding a particular 56 network service for a site. There are efforts in other IETF working 57 groups to address the long term solution to this problem, such as the 58 Server Location Resource Records (DNS SRV) work. 60 1. Rationale 62 In order to locate the network services offered at a particular 63 Internet domain one is faced with the choice of selecting from a 64 growing number of centralized databases - typically Web or Usenet 65 News "wanderers", or attempting to infer the existence of network 66 services from whatever DNS information may be available. The former 67 approach is not practical in some cases, notably when the entity 68 seeking service information is a program. 70 Perhaps the most visible example of the latter approach at work is in 71 the case of World-Wide Web HTTP servers. It is common practice to 72 try prefixing the domain name of an organization with "http://www." 73 in order to reach its World-Wide Web site, e.g. taking "hivnet.fr" 74 and arriving at "http://www.hivnet.fr." Some popular World-Wide Web 75 browsers have gone so far as to provide automatic support for this 76 domain name expansion. 78 Ideally, the DNS or some complementary directory service would 79 provide a means for programs to determine automatically the network 80 services which are offered at a particular Internet domain, the 81 protocols which are used to deliver them, and other technical 82 information such as TCP [6] and UDP [7] port numbers. 84 Unfortunately, although much work has been done on developing "yellow 85 pages" directory service technologies, and on attempting to define 86 new types of DNS resource record to provide this type of information, 87 there is no widely agreed upon or widely deployed solution to the 88 problem - except in a small number of cases. 90 The first case is where the DNS already provides a lookup capability 91 for the type of information being sought after. For example: Mail 92 Exchanger (MX) records specify how mail to a particular domain should 93 be routed [8], the Start of Authority (SOA) records make it possible 94 to determine who is responsible for a given domain, and Name Server 95 (NS) records indicate which hosts provide DNS name service for a 96 given domain. 98 The second case is where the DNS does not provide an appropriate 99 lookup capability, but there is some widely accepted convention for 100 finding this information. Some use has been made of Text (TXT) 101 records in this scenario, but in the vast majority of cases a 102 Canonical Name (CNAME) or Address (A) record pointer is used to 103 indicate the host or hosts which provide the service. This document 104 proposes a slight formalization of this well-known alias approach. 106 It should be noted that the DNS provides a Well Known Services (WKS) 107 lookup capability, which makes it possible to determine the network 108 services offered at a given domain name. In practice this is not 109 widely used, perhaps because of the absence of a suitable programming 110 interface. Use of WKS for mail routing was deprecated in the Host 111 Requirements specification [9] in favour of the MX record, and in the 112 long term it is conceivable that SRV records will supercede both WKS 113 and MX. 115 2. A generic framework 117 One approach to dealing with aliases for new protocols would be to 118 define a standard set of DNS aliases for the most popular network 119 services, and an accompanying review procedure for registering new 120 protocols - such as has been attempted with Internet Media (MIME) 121 Types [10]. We suggest that in the rapidly changing world of 122 computer networking this may not be the most appropriate way of 123 tackling the problem. 125 The Internet Assigned Numbers Authority (IANA) maintains a registry 126 of well known port numbers, registered port numbers, protocol and 127 service names [11]. We propose that this list be used to determine 128 the DNS alias for a given application protocol. 130 e.g. 132 ----------------------------------------------------------- 133 Name Protocol 134 ----------------------------------------------------------- 135 finger Finger [12] 136 ftp File Transfer Protocol 137 gopher Internet Gopher Protocol 138 ldap Lightweight Directory Access Protocol [13] 139 ntp Network Time Protocol [14] 140 rwhois Referral WHOIS [15] 141 whois NICNAME/WHOIS [16] 142 ----------------------------------------------------------- 144 We suggest that the DNS alias to be used for a service be taken 145 initially from the IANA lists of well known port numbers (in the 146 traditionally "restricted" rage 0 to 1023) and registered port 147 numbers (1024 to 65535). In the event that the name in the IANA port 148 registry contains the underscore character "_", the plus character 149 "+", or the dot character ".", the list of protocol and service names 150 should be used since these characters are not legal as domain name 151 components. 153 If it is not appropriate to use the information registered with IANA 154 for a particular application protocol, we suggest the protocol 155 specification should indicate why this is the case and propose an 156 alternative name. 158 3. Special cases 160 In addition to the character set problems outlined above, there are a 161 small number of special cases which are not currently catered for in 162 the IANA registry. This is a static list and will not be added to in 163 the future. 165 Special Cases: 167 ----------------------------------------------------------- 168 Alias Service 169 ----------------------------------------------------------- 170 archie archie [17] (alias for "prospero") 171 ph CCSO nameserver [18] (alias for "csnet-ns") 172 fsp File Service Protocol [19] 173 news Usenet News via NNTP [20] (alias for "nntp") 174 ns DNS servers 175 wais Wide Area Information Server [21] 176 www World-Wide Web HTTP (alias for "http") 177 ----------------------------------------------------------- 179 4. (Ab)Use of the DNS as a directory service 181 The widespread use of these common aliases effectively means that it 182 is sometimes possible to "guess" the domain names associated with an 183 organization's network services, though this is becoming more 184 difficult as the number of organizations registered in the DNS 185 increases. 187 It should be understood by implementors that the existence of a DNS 188 entry such as 190 www.hivnet.fr 192 does not constitute a registration of a World-Wide Web service. 193 There is no requirement that the domain name resolve to an IP address 194 or addresses. There is no requirement that a host be listening for 195 HTTP connections, or if it is, that the HTTP server be running on 196 port 80. Finally, even if all of these things are true, there can be 197 no guarantee that the World-Wide Web server will be prepared to honor 198 requests from arbitrary clients. 200 Having said this, the aliases do provide useful "hints" about the 201 services offered. We propose that they be taken in this spirit. 203 The conventions described in this document are, essentially, only 204 useful when the organization's domain name can be determined - e.g. 205 from some external database. A number of groups, including the IETF, 206 have been working on ways of finding domain names given a set of 207 information such as organization name, location, and business type. 208 It is hoped that one or more of these will eventually make it 209 possible to augment the basic lookup service which the DNS provides 210 with a more generalised search and retrieval capability. 212 5. DNS server configuration 214 In the short term, whilst directory service technology and further 215 types of DNS resource record are being developed, domain name 216 administrators are encouraged to use these common names for the 217 network services they run. They will make it easier for outsiders to 218 find information about your organization, and also make it easier for 219 you to move services from one machine to another. 221 There are two conventional approaches to creating these DNS entries. 222 One is to add a single CNAME record to your DNS server's 223 configuration, e.g. 225 ph.hivnet.fr. IN CNAME baby.hivnet.fr. 227 Note that in this scenario no information about ph.hivnet.fr should 228 exist in the DNS other than the CNAME record. 230 An alternative approach would be to create an A record for each of 231 the IP addresses associated with ph.hivnet.fr, e.g. 233 ph.hivnet.fr. IN A 194.167.157.2 235 Recent DNS server implementations provide a "round-robin" feature 236 which causes the host's IP addresses to be returned in a different 237 order each time the address is looked up. 239 Network clients are starting to appear which, when they encounter a 240 host with multiple addresses, use heuristics to determine the address 241 to contact - e.g. picking the one which has the shortest round-trip- 242 time. Thus, if a server is mirrored (replicated) at a number of 243 locations, it may be desirable to list the IP addresses of the mirror 244 servers as A records of the primary server. This is only likely to 245 be appropriate if the mirror servers are exact copies of the original 246 server. 248 6. Limitations of this approach 250 Some services require that a client have more information than the 251 server's domain name and (default) port number. For example, an LDAP 252 client needs to know a starting search base within the Directory 253 Information Tree in order to have a meaningful dialogue with the 254 server. This document does not attempt to address this problem. 256 7. CCSO service name 258 There are currently at least three different aliases in common use 259 for the CCSO nameserver - e.g. "ph", "cso" and "ns". It would appear 260 to be in everyone's interest to narrow the choice of alias down to a 261 single name. "ns" would seem to be the best choice since it is the 262 most commonly used name. However, "ns" is also being used by DNS to 263 point to the DNS server. In fact, the most prevalent use of NS to 264 name DNS servers. For this reason, we suggest the use of PH as the 265 best name to use for CCSO nameservers. 267 Sites with existing CCSO servers using "cso" and "ns" should add an 268 additional CNAME for "ph", while keeping the old name. This 269 increases the likelihood of the service being found. 271 As noted earlier, implementations should be resilient in the event 272 that the name does not point to the expected service. 274 8. Security considerations 276 The DNS is open to many kinds of "spoofing" attacks, and it cannot be 277 guaranteed that the result returned by a DNS lookup is indeed the 278 genuine information. Spoofing may take the form of denial of 279 service, such as directing of the client to a non-existent address, 280 or a passive attack such as an intruder's server which masquerades as 281 the legitimate one. 283 Work is ongoing to remedy this situation insofar as the DNS is 284 concerned [22]. In the meantime it should be noted that stronger 285 authentication mechanisms such as public key cryptography with large 286 key sizes are a pre-requisite if the DNS is being used in any 287 sensitive situations. Examples of these would be on-line financial 288 transactions, and any situation where privacy is a concern - such as 289 the querying of medical records over the network. Strong encryption 290 of the network traffic may also be advisable, to protect against TCP 291 connection "hijacking" and packet sniffing. 293 9. Conclusions 295 The service names registered with the IANA provide a sensible set of 296 defaults which may be used as an aid in determining the hosts which 297 offer particular services for a given domain name. 299 This document has noted some exceptions which are either inherently 300 unsuitable for this treatment, or already have a substantial 301 installed base using alternative aliases. 303 10. Acknowledgements 305 Thanks to Jeff Allen, Tom Gillman, Renato Iannella, Thomas 306 Lenggenhager, Bill Manning, Andy Powell, Sri Sataluri, Patrik 307 Faltstrom, Paul Vixie and Greg Woods for their comments on draft 308 versions of this document. 310 This work was supported by grants from the UK Electronic Libraries 311 Programme (eLib) grant 12/39/01, the European Commission's Telematics 312 for Research Programme grant RE 1004, and U. S. Department of Energy 313 Contract Number DE-AC03-76SF00098. 315 11. References 317 Request For Comments (RFC) and Internet Draft documents are available 318 from and numerous mirror sites. 320 [1] P. V. Mockapetris. "Domain names - concepts and 321 facilities", RFC 1034. November 1987. 323 [2] P. V. Mockapetris. "Domain names - implementation 324 and specification", RFC 1035. November 1987. 326 [3] J. Postel, J. K. Reynolds. "File Transfer Proto- 327 col", RFC 959. October 1985. 329 [4] F. Anklesaria, M. McCahill, P. Lindner, D. Johnson, 330 D. Torrey & B. Albert. "The Internet Gopher Proto- 331 col (a distributed document search and retrieval 332 protocol)", RFC 1436. March 1993. 334 [5] T. Berners-Lee, R. Fielding, H. Nielsen. "Hyper- 335 text Transfer Protocol -- HTTP/1.0", RFC 1945. May 336 1996. 338 [6] J. Postel. "Transmission Control Protocol", RFC 339 793. September 1981. 341 [7] J. Postel. "User Datagram Protocol", RFC 768. 342 August 1980. 344 [8] C. Partridge. "Mail routing and the domain sys- 345 tem", RFC 974. January 1986. 347 [9] R. T. Braden. "Requirements for Internet hosts - 348 application and support", RFC 1123. October 1989. 350 [10] J. Postel. "Media Type Registration Procedure", 351 RFC 1590. March 1994. 353 [11] J. Reynolds, J. Postel. "ASSIGNED NUMBERS", RFC 354 1700. October 1994. 356 [12] D. Zimmerman. "The Finger User Information Proto- 357 col", RFC 1288. December 1992. 359 [13] W. Yeong, T. Howes, S. Kille. "Lightweight Direc- 360 tory Access Protocol", RFC 1777. March 1995. 362 [14] D. Mills. "Network Time Protocol (Version 3) 363 Specification, Implementation", RFC 1305. March 364 1992. 366 [15] S. Williamson & M. Kosters. "Referral Whois Proto- 367 col (RWhois)", RFC 1714. November 1994. 369 [16] K. Harrenstien, M. K. Stahl, E.J. Feinler. 370 "NICNAME/WHOIS", RFC 954. October 1985. 372 [17] A. Emtage, P. Deutsch. "archie - An Electronic 373 Directory Service for the Internet", Winter Usenix 374 Conference Proceedings 1992. Pages 93-110. 376 [18] R. Hedberg, S. Dorner, P. Pomes. "The CCSO 377 Nameserver (Ph) Architecture", Internet Draft. 378 February 1996. 380 [19] FSP software distribution: 381 383 [20] B. Kantor, P. Lapsley. "Network News Transfer Pro- 384 tocol", RFC 977. February 1986. 386 [21] M. St. Pierre, J. Fullton, K. Gamiel, J. Goldman, 387 B. Kahle, J. Kunze, H. Morris & F. Schiettecatte. 388 "WAIS over Z39.50-1988", RFC 1625. June 1994. 390 [22] D. E. Eastlake 3rd, C. W. Kaufman. "Domain Name 391 System Security Extensions", Internet Draft. Janu- 392 ary 1996. 394 12. Authors addresses 396 Martin Hamilton 397 Department of Computer Studies 398 Loughborough University of Technology 399 Leics. LE11 3TU, UK 401 Email: m.t.hamilton@lut.ac.uk 403 Russ Wright 404 Information & Computing Sciences Division 405 Lawrence Berkeley National Laboratory 406 1 Cyclotron Road, Berkeley 407 Mail-Stop: 50B-2258 408 CA 94720, USA 410 Email: wright@lbl.gov 411 This Internet Draft expires February 12th, 1997.