idnits 2.17.1 draft-ietf-ids-dnsnames-00.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-25) 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 166 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 (May 1996) is 10207 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 INTERNET-DRAFT Martin Hamilton 3 draft-ietf-ids-dnsnames-00.txt Loughborough University 4 Expires in six months Russ Wright 5 Lawrence Berkeley Laboratory 6 May 1996 8 Use of DNS Aliases for Network Services 9 Filename: draft-ietf-ids-dnsnames-00.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 Abstract 32 It has become a common practice to use symbolic names (usually 33 CNAMEs) in the Domain Name Service (DNS - [1,2]) to refer to network 34 services such as anonymous FTP [3] servers, Gopher [4] servers, and 35 most notably World-Wide Web HTTP [5] servers. This is desirable for 36 a number of reasons. It provides a way of moving services from one 37 machine to another transparently, and a mechanism by which people or 38 agents may programatically discover that an organization runs, say, a 39 World-Wide Web server. 41 Although this approach has been almost universally adopted, there is 42 no standards document or similar specification for these commonly 43 used names. This document seeks to rectify this situation by 44 gathering together the extant "folklore" on naming conventions, and 45 proposes a mechanism for accommodating new protocols. Distribution 46 of this document is unlimited. Comments should be sent to the IETF 47 Integrated Directory Services mailing list, ietf-ids@umich.edu, or 48 directly to the authors. 50 1. Rationale 52 In order to locate the network services offered at a particular 53 Internet domain one is faced with the choice of selecting from a 54 growing number of centralized databases - typically Web or Usenet 55 News "wanderers", or attempting to infer the existence of network 56 services from whatever DNS information may be available. The former 57 approach is not practical in some cases, notably when the entity 58 seeking service information is a program. 60 Perhaps the most visible example of the latter approach at work is in 61 the case of World-Wide Web HTTP servers. It is common practice to 62 try prefixing the domain name of an organization with "http://www." 63 in order to reach its World-Wide Web site, e.g. taking "hivnet.fr" 64 and arriving at "http://www.hivnet.fr." Some popular World-Wide Web 65 browsers have gone so far as to provide automatic support for this 66 domain name expansion. 68 Ideally, the DNS or some complementary directory service would 69 provide a means for programs to determine automatically the network 70 services which are offered at a particular Internet domain, the 71 protocols which are used to deliver them, and other technical 72 information such as TCP [6] and UDP [7] port numbers. 74 Unfortunately, although much work has been done on developing "yellow 75 pages" directory service technologies, and on attempting to define 76 new types of DNS resource record to provide this type of information, 77 there is no widely agreed upon or widely deployed solution to the 78 problem - except in a small number of cases. 80 The first case is where the DNS already provides a lookup capability 81 for the type of information being sought after. For example: Mail 82 Exchanger (MX) records specify how mail to a particular domain should 83 be routed [8], the Start of Authority (SOA) records make it possible 84 to determine who is responsible for a given domain, and Name Server 85 (NS) records indicate which hosts provide DNS name service for a 86 given domain. 88 The second case is where the DNS does not provide an appropriate 89 lookup capability, but there is some widely accepted convention for 90 finding this information. Some use has been made of Text (TXT) 91 records in this scenario, but in the vast majority of cases a 92 Canonical Name (CNAME) or Address (A) record pointer is used to 93 indicate the host or hosts which provide the service. This document 94 proposes a slight formalization of this well-known alias approach. 96 It should be noted that the DNS provides a Well Known Services (WKS) 97 lookup capability, which makes it possible to determine the services 98 offered by a particular host given its domain name. In practice this 99 is not widely used, and was deprecated in the Host Requirements 100 specification [9]. In fact, WKS is really trying to solve a 101 different problem - advertising the services provided by a particular 102 machine, rather than which machines provide particular services for a 103 domain as a whole. 105 2. A generic framework 107 One approach to dealing with aliases for new protocols would be to 108 define a standard set of DNS aliases for the most popular network 109 services, and an accompanying review procedure for registering new 110 protocols - such as has been attempted with Internet Media (MIME) 111 Types [10]. We suggest that in the rapidly changing world of 112 computer networking this may not be the most appropriate way of 113 tackling the problem. 115 The Internet Assigned Numbers Authority (IANA) maintains a registry 116 of well known port numbers, registered port numbers, protocol and 117 service names [11]. We propose that this list be used to determine 118 the a default port number, transport protocol (e.g. TCP or UDP) and 119 DNS alias for a given application protocol. 121 e.g. 123 ----------------------------------------------------------- 124 Name Port Transport Protocol 125 ----------------------------------------------------------- 126 finger 79 TCP Finger [12] 127 ftp 21 TCP File Transfer Protocol 128 gopher 70 TCP Internet Gopher Protocol 129 ldap 389 TCP/UDP Lightweight Directory Access 130 Protocol [13] 131 ntp 123 UDP Network Time Protocol [14] 132 rwhois 4321 TCP Referral WHOIS [15] 133 whois 43 TCP NICNAME/WHOIS [16] 134 ----------------------------------------------------------- 136 If it is not appropriate to use the information registered with IANA 137 for a particular application protocol, we suggest the protocol 138 specification should indicate why this is the case - and preferably 139 propose an alternative mechanism. For example, a Remote Procedure 140 Call (RPC) based application protocol which does not use a fixed port 141 number by default might determine which port to use by contacting a 142 remote RPC portmapper. 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), with recourse to the list of protocol and 148 service names if there is some confusion over the preferred alias. 149 This might be necessary if, for example, the name associated with the 150 IANA registered port number for a protocol contains the underscore 151 character "_", the plus character "+", or the dot character "." - 152 these are not legal as domain name components. 154 3. Special cases 156 In addition to the character set problems outlined above, there are a 157 small number of special cases which are not currently catered for in 158 the IANA registry. We propose that IANA maintain a list of these in 159 addition to the existing assigned numbers information. 161 Some common examples: 163 ----------------------------------------------------------- 164 Alias Service 165 ----------------------------------------------------------- 166 archie archie [17] (alias for "prospero") 167 cso CCSO nameserver [18] (alias for "csnet-ns") 168 fsp File Service Protocol [19] 169 news Usenet News via NNTP [20] (alias for "nntp") 170 ns DNS servers, and CCSO nameservers (aliases for 171 "domain" and "csnet-ns") 172 ph CCSO (alias for "csnet-ns") 173 wais Wide Area Information Server [21] (alias for 174 "z39.50") 175 www World-Wide Web HTTP (alias for "http") 176 ----------------------------------------------------------- 178 4. (Ab)Use of the DNS as a directory service 180 The widespread use of these common aliases effectively means that it 181 is sometimes possible to "guess" the domain names associated with an 182 organization's network services, though this is becoming more 183 difficult as the number of organizations registered in the DNS 184 increases. 186 It should be understood by implementors that the existence of a DNS 187 entry such as 189 www.hivnet.fr 191 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. An alternative 229 approach would be to create an A record for each of the IP addresses 230 associated with ph.hivnet.fr, e.g. 232 ph.hivnet.fr. IN A 194.167.157.2 234 Recent DNS server implementations provide a "round-robin" feature 235 which causes the host's IP addresses to be returned in a different 236 order each time the address is looked up. 238 Network clients are starting to appear which, when they encounter a 239 host with multiple addresses, use heuristics to determine the address 240 to contact - e.g. picking the one which has the shortest round-trip- 241 time. Thus, if a server is mirrored (replicated) at a number of 242 locations, it may be desirable to list the IP addresses of the mirror 243 servers as A records of the primary server. This is only likely to 244 be appropriate if the mirror servers are exact copies of the original 245 server. 247 6. Limitations of this approach 249 Some services require that a client have more information than the 250 server's domain name and (default) port number. For example, an LDAP 251 client needs to know a starting search base within the Directory 252 Information Tree in order to have a meaningful dialogue with the 253 server. This document does not attempt to address this problem. 255 In some cases, different aliases are in common use for the same 256 service - e.g. "ph", "cso" and "ns" for the CCSO nameserver. It 257 might appear to be in everyone's interest to narrow the choice of 258 alias down to a single name. However, if current practice implies 259 that a number of aliases are equally valid, it would be advisable to 260 support them all. This increases the likelihood of the service being 261 found. 263 <> Given the confusion over the multiple use of the "ns" 264 alias in particular, we could suggest/mandate that everyone move to a 265 single name, e.g. the IANA registered "csnet-ns" or one of "cso" and 266 "ph". Should we be trying to do this ? Discuss! <> 268 Another problem is the use of a single alias to refer to multiple 269 network services, e.g. "ns" is commonly used to refer to both hosts 270 which run the CCSO nameserver, and DNS servers themselves. In this 271 particular case the DNS already provides a lookup capability for 272 nameservers via the NS record. As noted, implementations should be 273 resilient in the event that the name does not point to the expected 274 service. 276 7. Security considerations 278 The DNS is open to many kinds of "spoofing" attacks, and it cannot be 279 guaranteed that the result returned by a DNS lookup is indeed the 280 genuine information. Spoofing may take the form of denial of 281 service, such as directing of the client to a non-existent address, 282 or a passive attack such as an intruder's server which masquerades as 283 the legitimate one. 285 Work is ongoing to remedy this situation insofar as the DNS is 286 concerned [22]. In the meantime it should be noted that stronger 287 authentication mechanisms such as public key cryptography with large 288 key sizes are a pre-requisite if the DNS is being used in any 289 sensitive situations. Examples of these would be on-line financial 290 transactions, and any situation where privacy is a concern - such as 291 the querying of medical records over the network. Strong encryption 292 of the network traffic may also be advisable, to protect against TCP 293 connection "hijacking" and packet sniffing. 295 8. Conclusions 297 The service names registered with the IANA provide a sensible set of 298 defaults which may be used as an aid in determining the hosts which 299 offer particular services for a given domain name. 301 This document has noted some exceptions which are either inherently 302 unsuitable for this treatment, or already have a substantial 303 installed base using alternative aliases. 305 9. Acknowledgements 307 Thanks to Jeff Allen, Tom Gillman, Renato Iannella, Thomas 308 Lenggenhager, Bill Manning, Andy Powell, Sri Sataluri, and <> for their comments on draft versions of this document. 311 This work was supported by grants from the UK Electronic Libraries 312 Programme (eLib) and the European Commission's Telematics for 313 Research Programme. 315 10. 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 11. 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 29th November, 1996.