idnits 2.17.1 draft-ietf-ids-dnsnames-02.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. ** The abstract seems to contain references ([RFC-959], [RFC-1436], [RFC-2052], [RFC-1945], [RFC-1034,RFC-1035]), 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 134 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 (Feburary 1997) is 9993 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) == Unused Reference: 'RFC-768' is defined on line 300, but no explicit reference was found in the text == Unused Reference: 'RFC-793' is defined on line 303, but no explicit reference was found in the text == Unused Reference: 'RFC-1590' is defined on line 342, but no explicit reference was found in the text == Unused Reference: 'RFC-1700' is defined on line 349, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'ARCHIE' -- Possible downref: Non-RFC (?) normative reference: ref. 'PH' ** Obsolete normative reference: RFC 793 (Obsoleted by RFC 9293) ** Obsolete normative reference: RFC 821 (Obsoleted by RFC 2821) ** Obsolete normative reference: RFC 954 (Obsoleted by RFC 3912) ** Obsolete normative reference: RFC 974 (Obsoleted by RFC 2821) ** Obsolete normative reference: RFC 977 (Obsoleted by RFC 3977) ** Obsolete normative reference: RFC 1305 (Obsoleted by RFC 5905) ** Downref: Normative reference to an Informational RFC: RFC 1436 ** Obsolete normative reference: RFC 1590 (Obsoleted by RFC 2045, RFC 2046, RFC 2047, RFC 2048, RFC 2049) ** Downref: Normative reference to an Informational RFC: RFC 1625 ** Obsolete normative reference: RFC 1700 (Obsoleted by RFC 3232) ** Obsolete normative reference: RFC 1714 (Obsoleted by RFC 2167) ** Obsolete normative reference: RFC 1777 (Obsoleted by RFC 3494) ** Downref: Normative reference to an Informational RFC: RFC 1945 ** Obsolete normative reference: RFC 2052 (Obsoleted by RFC 2782) ** Obsolete normative reference: RFC 2065 (Obsoleted by RFC 2535) Summary: 24 errors (**), 0 flaws (~~), 9 warnings (==), 4 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 Feburary 1997 8 Use of DNS Aliases for Network Services 9 Filename: draft-ietf-ids-dnsnames-02.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 August 1, 1997. 37 Abstract 39 It has become a common practice to use symbolic names (usually 40 CNAMEs) in the Domain Name Service (DNS - [RFC-1034, RFC-1035]) to 41 refer to network services such as anonymous FTP [RFC-959] servers, 42 Gopher [RFC-1436] servers, and most notably World-Wide Web HTTP 43 [RFC-1945] servers. This is desirable for a number of reasons. It 44 provides a way of moving services from one machine to another 45 transparently, and a mechanism by which people or agents may 46 programatically discover that an organization runs, say, a World-Wide 47 Web server. 49 Although this approach has been almost universally adopted, there is 50 no standards document or similar specification for these commonly 51 used names. This document seeks to rectify this situation by 52 gathering together the extant "folklore" on naming conventions, and 53 proposes a mechanism for accommodating new protocols. 55 It is important to note that these naming conventions do not provide 56 a complete long term solution to the problem of finding a particular 57 network service for a site. There are efforts in other IETF working 58 groups to address the long term solution to this problem, such as the 59 Server Location Resource Records (DNS SRV) [RFC-2052] work. 61 1. Rationale 63 In order to locate the network services offered at a particular 64 Internet domain one is faced with the choice of selecting from a 65 growing number of centralized databases - typically Web or Usenet 66 News "wanderers", or attempting to infer the existence of network 67 services from whatever DNS information may be available. The former 68 approach is not practical in some cases, notably when the entity 69 seeking service information is a program. 71 Perhaps the most visible example of the latter approach at work is in 72 the case of World-Wide Web HTTP servers. It is common practice to 73 try prefixing the domain name of an organization with "http://www." 74 in order to reach its World-Wide Web site, e.g. taking "hivnet.fr" 75 and arriving at "http://www.hivnet.fr." Some popular World-Wide Web 76 browsers have gone so far as to provide automatic support for this 77 domain name expansion. 79 Ideally, the DNS or some complementary directory service would 80 provide a means for programs to determine automatically the network 81 services which are offered at a particular Internet domain, the 82 protocols which are used to deliver them, and other technical 83 information. 85 Unfortunately, although much work has been done on developing "yellow 86 pages" directory service technologies, and on attempting to define 87 new types of DNS resource record to provide this type of information, 88 there is no widely agreed upon or widely deployed solution to the 89 problem - except in a small number of cases. 91 The first case is where the DNS already provides a lookup capability 92 for the type of information being sought after. For example: Mail 93 Exchanger (MX) records specify how mail to a particular domain should 94 be routed [RFC-974], the Start of Authority (SOA) records make it 95 possible to determine who is responsible for a given domain, and Name 96 Server (NS) records indicate which hosts provide DNS name service for 97 a given domain. 99 The second case is where the DNS does not provide an appropriate 100 lookup capability, but there is some widely accepted convention for 101 finding this information. Some use has been made of Text (TXT) 102 records in this scenario, but in the vast majority of cases a 103 Canonical Name (CNAME) or Address (A) record pointer is used to 104 indicate the host or hosts which provide the service. This document 105 proposes a slight formalization of this well-known alias approach. 107 It should be noted that the DNS provides a Well Known Services (WKS) 108 lookup capability, which makes it possible to determine the network 109 services offered at a given domain name. In practice this is not 110 widely used, perhaps because of the absence of a suitable programming 111 interface. Use of WKS for mail routing was deprecated in the Host 112 Requirements specification [RFC-1123] in favour of the MX record, and 113 in the long term it is conceivable that SRV records will supercede 114 both WKS and MX. 116 2. A generic framework 118 Our approach to dealing with aliases for protocols is 119 straightforward. We define a standard set of DNS aliases for the most 120 popular network services that currently exist (see the "Special 121 Cases" section below). For protocols that are not explicitly listed 122 in this document, the protocol specification must propose a name. 124 3. Special cases 126 This is a static list of standard aliases and will not be added to in 127 the future. 129 Special Cases: 131 ----------------------------------------------------------- 132 Alias Service 133 ----------------------------------------------------------- 134 archie archie [ARCHIE] 135 finger Finger [RFC-1288] 136 ftp File Transfer Protocol [RFC-959] 137 gopher Internet Gopher Protocol [RFC-1436] 138 ldap Lightweight Directory Access Protocol [RFC-1777] 139 mail SMTP mail [RFC-821] 140 news Usenet News via NNTP [RFC-977] 141 ntp Network Time Protocol [RFC-1305] 142 ph CCSO nameserver [PH] 143 pop Post Office Protocol [RFC-1939] 144 rwhois Referral WHOIS [RFC-1714] 145 wais Wide Area Information Server [RFC-1625] 146 whois NICNAME/WHOIS [RFC-954] 147 www World-Wide Web HTTP [RFC-1945] 148 ----------------------------------------------------------- 150 4. (Ab)Use of the DNS as a directory service 152 The widespread use of these common aliases effectively means that it 153 is sometimes possible to "guess" the domain names associated with an 154 organization's network services, though this is becoming more 155 difficult as the number of organizations registered in the DNS 156 increases. 158 It should be understood by implementors that the existence of a DNS 159 entry such as 161 www.hivnet.fr 163 does not constitute a registration of a World-Wide Web service. 164 There is no requirement that the domain name resolve to an IP address 165 or addresses. There is no requirement that a host be listening for 166 HTTP connections, or if it is, that the HTTP server be running on 167 port 80. Finally, even if all of these things are true, there can be 168 no guarantee that the World-Wide Web server will be prepared to honor 169 requests from arbitrary clients. 171 Having said this, the aliases do provide useful "hints" about the 172 services offered. We propose that they be taken in this spirit. 174 The conventions described in this document are, essentially, only 175 useful when the organization's domain name can be determined - e.g. 176 from some external database. A number of groups, including the IETF, 177 have been working on ways of finding domain names given a set of 178 information such as organization name, location, and business type. 179 It is hoped that one or more of these will eventually make it 180 possible to augment the basic lookup service which the DNS provides 181 with a more generalised search and retrieval capability. 183 5. DNS server configuration 185 In the short term, whilst directory service technology and further 186 types of DNS resource record are being developed, domain name 187 administrators are encouraged to use these common names for the 188 network services they run. They will make it easier for outsiders to 189 find information about your organization, and also make it easier for 190 you to move services from one machine to another. 192 There are two conventional approaches to creating these DNS entries. 194 One is to add a single CNAME record to your DNS server's 195 configuration, e.g. 197 ph.hivnet.fr. IN CNAME baby.hivnet.fr. 199 Note that in this scenario no information about ph.hivnet.fr should 200 exist in the DNS other than the CNAME record. 202 An alternative approach would be to create an A record for each of 203 the IP addresses associated with ph.hivnet.fr, e.g. 205 ph.hivnet.fr. IN A 194.167.157.2 207 Recent DNS server implementations provide a "round-robin" feature 208 which causes the host's IP addresses to be returned in a different 209 order each time the address is looked up. 211 Network clients are starting to appear which, when they encounter a 212 host with multiple addresses, use heuristics to determine the address 213 to contact - e.g. picking the one which has the shortest round-trip- 214 time. Thus, if a server is mirrored (replicated) at a number of 215 locations, it may be desirable to list the IP addresses of the mirror 216 servers as A records of the primary server. This is only likely to 217 be appropriate if the mirror servers are exact copies of the original 218 server. 220 6. Limitations of this approach 222 Some services require that a client have more information than the 223 server's domain name. For example, an LDAP client needs to know a 224 starting search base within the Directory Information Tree in order 225 to have a meaningful dialogue with the server. This document does 226 not attempt to address this problem. 228 7. CCSO service name 230 There are currently at least three different aliases in common use 231 for the CCSO nameserver - e.g. "ph", "cso" and "ns". It would appear 232 to be in everyone's interest to narrow the choice of alias down to a 233 single name. "ns" would seem to be the best choice since it is the 234 most commonly used name. However, "ns" is also being used by DNS to 235 point to the DNS server. In fact, the most prevalent use of NS to 236 name DNS servers. For this reason, we suggest the use of PH as the 237 best name to use for CCSO nameservers. 239 Sites with existing CCSO servers using some of these aliases may find 240 it desirable to use all three. This increases the likelihood of the 241 service being found. 243 As noted earlier, implementations should be resilient in the event 244 that the name does not point to the expected service. 246 8. Security considerations 248 The DNS is open to many kinds of "spoofing" attacks, and it cannot be 249 guaranteed that the result returned by a DNS lookup is indeed the 250 genuine information. Spoofing may take the form of denial of 251 service, such as directing of the client to a non-existent address, 252 or a passive attack such as an intruder's server which masquerades as 253 the legitimate one. 255 Work is ongoing to remedy this situation insofar as the DNS is 256 concerned [RFC-2065]. In the meantime it should be noted that 257 stronger authentication mechanisms such as public key cryptography 258 with large key sizes are a pre-requisite if the DNS is being used in 259 any sensitive situations. Examples of these would be on-line 260 financial transactions, and any situation where privacy is a concern 261 - such as the querying of medical records over the network. Strong 262 encryption of the network traffic may also be advisable, to protect 263 against TCP connection "hijacking" and packet sniffing. 265 9. Conclusions 267 The service names listed in this document provide a sensible set of 268 defaults which may be used as an aid in determining the hosts which 269 offer particular services for a given domain name. 271 This document has noted some exceptions which are either inherently 272 unsuitable for this treatment, or already have a substantial 273 installed base using alternative aliases. 275 10. Acknowledgements 277 Thanks to Jeff Allen, Tom Gillman, Renato Iannella, Thomas 278 Lenggenhager, Bill Manning, Andy Powell, Sri Sataluri, Patrik 279 Faltstrom, Paul Vixie and Greg Woods for their comments on draft 280 versions of this document. 282 This work was supported by grants from the UK Electronic Libraries 283 Programme (eLib) grant 12/39/01, the European Commission's Telematics 284 for Research Programme grant RE 1004, and U. S. Department of Energy 285 Contract Number DE-AC03-76SF00098. 287 11. References 289 Request For Comments (RFC) and Internet Draft documents are available 290 from and numerous mirror sites. 292 [ARCHIE] A. Emtage, P. Deutsch. "archie - An Electronic 293 Directory Service for the Internet", Winter Usenix 294 Conference Proceedings 1992. Pages 93-110. 296 [PH] R. Hedberg, S. Dorner, P. Pomes. "The CCSO 297 Nameserver (Ph) Architecture", Internet Draft. 298 February 1996. 300 [RFC-768] J. Postel. "User Datagram Protocol", RFC 768. 301 August 1980. 303 [RFC-793] J. Postel. "Transmission Control Protocol", RFC 304 793. September 1981. 306 [RFC-821] J. Postel, "Simple Mail Transfer Protocol", RFC 307 821. August 1982. 309 [RFC-954] K. Harrenstien, M. K. Stahl, E.J. Feinler. 310 "NICNAME/WHOIS", RFC 954. October 1985. 312 [RFC-959] J. Postel, J. K. Reynolds. "File Transfer Proto- 313 col", RFC 959. October 1985. 315 [RFC-974] C. Partridge. "Mail routing and the domain sys- 316 tem", RFC 974. January 1986. 318 [RFC-977] B. Kantor, P. Lapsley. "Network News Transfer Pro- 319 tocol", RFC 977. February 1986. 321 [RFC-1034] P. V. Mockapetris. "Domain names - concepts and 322 facilities", RFC 1034. November 1987. 324 [RFC-1035] P. V. Mockapetris. "Domain names - implementation 325 and specification", RFC 1035. November 1987. 327 [RFC-1123] R. T. Braden. "Requirements for Internet hosts - 328 application and support", RFC 1123. October 1989. 330 [RFC-1288] D. Zimmerman. "The Finger User Information Proto- 331 col", RFC 1288. December 1992. 333 [RFC-1305] D. Mills. "Network Time Protocol (Version 3) 334 Specification, Implementation", RFC 1305. March 335 1992. 337 [RFC-1436] F. Anklesaria, M. McCahill, P. Lindner, D. Johnson, 338 D. Torrey & B. Albert. "The Internet Gopher Proto- 339 col (a distributed document search and retrieval 340 protocol)", RFC 1436. March 1993. 342 [RFC-1590] J. Postel. "Media Type Registration Procedure", 343 RFC 1590. March 1994. 345 [RFC-1625] M. St. Pierre, J. Fullton, K. Gamiel, J. Goldman, 346 B. Kahle, J. Kunze, H. Morris & F. Schiettecatte. 347 "WAIS over Z39.50-1988", RFC 1625. June 1994. 349 [RFC-1700] J. Reynolds, J. Postel. "ASSIGNED NUMBERS", RFC 350 1700. October 1994. 352 [RFC-1714] S. Williamson & M. Kosters. "Referral Whois Proto- 353 col (RWhois)", RFC 1714. November 1994. 355 [RFC-1777] W. Yeong, T. Howes, S. Kille. "Lightweight Direc- 356 tory Access Protocol", RFC 1777. March 1995. 358 [RFC-1939] J. Myers, M. Rose, "Post Office Protocol - Version 359 3", RFC 1939, May 1996. 361 [RFC-1945] T. Berners-Lee, R. Fielding, H. Nielsen. "Hyper- 362 text Transfer Protocol -- HTTP/1.0", RFC 1945. May 363 1996. 365 [RFC-2052] A. Gulbrandsen, P. Vixie, "A DNS RR for specifying 366 the location of services (DNS SRV)", RFC 2052, 367 October 1996. 369 [RFC-2065] D. Eastlake, C. Kaufman, "Domain Name System Secu- 370 rity Extensions", RFC 2065, January 1997. 372 12. Authors addresses 374 Martin Hamilton 375 Department of Computer Studies 376 Loughborough University of Technology 377 Leics. LE11 3TU, UK 379 Email: m.t.hamilton@lut.ac.uk 381 Russ Wright 382 Information & Computing Sciences Division 383 Lawrence Berkeley National Laboratory 384 1 Cyclotron Road, Berkeley 385 Mail-Stop: 50A-3111 386 CA 94720, USA 388 Email: wright@lbl.gov 390 This Internet Draft expires August 1, 1997.