1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
|
<pre>Network Working Group M. Hamilton
Request for Comments: 2219 Loughborough University
BCP: 17 R. Wright
Category: Best Current Practice Lawrence Berkeley Laboratory
October 1997
<span class="h1">Use of DNS Aliases for Network Services</span>
Status of this Memo
This document specifies an Internet Best Current Practices for the
Internet Community, and requests discussion and suggestions for
improvements. Distribution of this memo is unlimited.
Abstract
It has become a common practice to use symbolic names (usually
CNAMEs) in the Domain Name Service (DNS - [RFC-1034, <a href="./rfc1035">RFC-1035</a>]) to
refer to network services such as anonymous FTP [<a href="./rfc959" title=""File Transfer Protocol"">RFC-959</a>] servers,
Gopher [<a href="./rfc1436" title=""The Internet Gopher Protocol (a distributed document search and retrieval protocol)"">RFC-1436</a>] servers, and most notably World-Wide Web HTTP
[<a href="./rfc1945" title=""Hypertext Transfer Protocol -- HTTP/1.0"">RFC-1945</a>] servers. This is desirable for a number of reasons. It
provides a way of moving services from one machine to another
transparently, and a mechanism by which people or agents may
programmatically discover that an organization runs, say, a World-
Wide Web server.
Although this approach has been almost universally adopted, there is
no standards document or similar specification for these commonly
used names. This document seeks to rectify this situation by
gathering together the extant 'folklore' on naming conventions, and
proposes a mechanism for accommodating new protocols.
It is important to note that these naming conventions do not provide
a complete long term solution to the problem of finding a particular
network service for a site. There are efforts in other IETF working
groups to address the long term solution to this problem, such as the
Server Location Resource Records (DNS SRV) [<a href="./rfc2052" title=""A DNS RR for specifying the location of services (DNS SRV)"">RFC-2052</a>] work.
<span class="h2"><a class="selflink" id="section-1" href="#section-1">1</a>. Rationale</span>
In order to locate the network services offered at a particular
Internet domain one is faced with the choice of selecting from a
growing number of centralized databases - typically Web or Usenet
News "wanderers", or attempting to infer the existence of network
services from whatever DNS information may be available. The former
approach is not practical in some cases, notably when the entity
seeking service information is a program.
<span class="grey">Hamilton & Wright Best Current Practice [Page 1]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-2" ></span>
<span class="grey"><a href="./rfc2219">RFC 2219</a> DNS Aliases October 1997</span>
Perhaps the most visible example of the latter approach at work is in
the case of World-Wide Web HTTP servers. It is common practice to
try prefixing the domain name of an organization with "<a href="http://www">http://www</a>."
in order to reach its World-Wide Web site, e.g. taking "hivnet.fr"
and arriving at "<a href="http://www.hivnet.fr">http://www.hivnet.fr</a>." Some popular World-Wide Web
browsers have gone so far as to provide automatic support for this
domain name expansion.
Ideally, the DNS or some complementary directory service would
provide a means for programs to determine automatically the network
services which are offered at a particular Internet domain, the
protocols which are used to deliver them, and other technical
information. Unfortunately, although much work has been done to
develop said directory service technologies and to define new types
of DNS resource record to provide this type of information, there is
no widely agreed upon or widely deployed solution to the problem -
except in a small number of cases.
The first case is where the DNS already provides a lookup capability
for the type of information being sought after. For example: Mail
Exchanger (MX) records specify how mail to a particular domain should
be routed [<a href="./rfc974" title=""Mail routing and the domain System"">RFC-974</a>], the Start of Authority (SOA) records make it
possible to determine who is responsible for a given domain, and Name
Server (NS) records indicate which hosts provide DNS name service for
a given domain.
The second case is where the DNS does not provide an appropriate
lookup capability, but there is some widely accepted convention for
finding this information. Some use has been made of Text (TXT)
[<a href="./rfc1035" title=""Domain names - implementation and specification"">RFC-1035</a>] records in this scenario, but in the vast majority of
cases a Canonical Name (CNAME) or Address (A) record pointer is used
to indicate the host or hosts which provide the service. This
document proposes a slight formalization of this well-known alias
approach.
It should be noted that the DNS provides a Well Known Services (WKS)
[<a href="./rfc1035" title=""Domain names - implementation and specification"">RFC-1035</a>] lookup capability, which makes it possible to determine
the network services offered at a given domain name. In practice
this is not widely used, perhaps because of the absence of a suitable
programming interface. Use of WKS for mail routing was deprecated in
the Host Requirements specification [<a href="./rfc1123" title=""Requirements for Internet hosts - application and support"">RFC-1123</a>] in favour of the MX
record, and in the long term it is conceivable that SRV records will
supersede both WKS and MX.
<span class="grey">Hamilton & Wright Best Current Practice [Page 2]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-3" ></span>
<span class="grey"><a href="./rfc2219">RFC 2219</a> DNS Aliases October 1997</span>
<span class="h2"><a class="selflink" id="section-2" href="#section-2">2</a>. A generic framework</span>
Our approach to dealing with aliases for protocols is
straightforward. We define a standard set of DNS aliases for the most
popular network services that currently exist (see the "Special
Cases" section below). For protocols that are not explicitly listed
in this document, the protocol specification must propose a name.
<span class="h2"><a class="selflink" id="section-3" href="#section-3">3</a>. Special cases</span>
Special Cases:
-----------------------------------------------------------
Alias Service
-----------------------------------------------------------
archie archie [<a href="#ref-ARCHIE" title=""archie - An Electronic Directory Service for the Internet"">ARCHIE</a>]
finger Finger [<a href="./rfc1288" title=""The Finger User Information Protocol"">RFC-1288</a>]
ftp File Transfer Protocol [<a href="./rfc959" title=""File Transfer Protocol"">RFC-959</a>]
gopher Internet Gopher Protocol [<a href="./rfc1436" title=""The Internet Gopher Protocol (a distributed document search and retrieval protocol)"">RFC-1436</a>]
ldap Lightweight Directory Access Protocol [<a href="./rfc1777" title=""Lightweight Directory Access Protocol"">RFC-1777</a>]
mail SMTP mail [<a href="./rfc821" title=""Simple Mail Transfer Protocol"">RFC-821</a>]
news Usenet News via NNTP [<a href="./rfc977" title=""Network News Transfer Protocol"">RFC-977</a>]
ntp Network Time Protocol [<a href="./rfc1305" title=""Network Time Protocol (Version 3) Specification, Implementation"">RFC-1305</a>]
ph CCSO nameserver [<a href="#ref-PH" title=""The CCSO Nameserver (Ph) Architecture"">PH</a>]
pop Post Office Protocol [<a href="./rfc1939" title=""Post Office Protocol - Version 3"">RFC-1939</a>]
rwhois Referral WHOIS [<a href="./rfc1714" title=""Referral Whois Protocol (RWhois)"">RFC-1714</a>]
wais Wide Area Information Server [<a href="./rfc1625" title=""WAIS over Z39.50-1988"">RFC-1625</a>]
whois NICNAME/WHOIS [<a href="./rfc954" title=""NICNAME/WHOIS"">RFC-954</a>]
www World-Wide Web HTTP [<a href="./rfc1945" title=""Hypertext Transfer Protocol -- HTTP/1.0"">RFC-1945</a>]
-----------------------------------------------------------
<span class="h2"><a class="selflink" id="section-4" href="#section-4">4</a>. (Ab)Use of the DNS as a directory service</span>
The widespread use of these common aliases effectively means that it
is sometimes possible to "guess" the domain names associated with an
organization's network services, though this is becoming more
difficult as the number of organizations registered in the DNS
increases.
It should be understood by implementors that the existence of a DNS
entry such as
www.hivnet.fr
does not constitute a registration of a World-Wide Web service.
There is no requirement that the domain name resolve to an IP address
or addresses. There is no requirement that a host be listening for
<span class="grey">Hamilton & Wright Best Current Practice [Page 3]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-4" ></span>
<span class="grey"><a href="./rfc2219">RFC 2219</a> DNS Aliases October 1997</span>
HTTP connections, or if it is, that the HTTP server be running on
port 80. Finally, even if all of these things are true, there can be
no guarantee that the World-Wide Web server will be prepared to honor
requests from arbitrary clients.
Having said this, the aliases do provide useful "hints" about the
services offered. We propose that they be taken in this spirit.
The conventions described in this document are, essentially, only
useful when the organization's domain name can be determined - e.g.
from some external database. A number of groups, including the IETF,
have been working on ways of finding domain names given a set of
information such as organization name, location, and business type.
It is hoped that one or more of these will eventually make it
possible to augment the basic lookup service which the DNS provides
with a more generalized search and retrieval capability.
<span class="h2"><a class="selflink" id="section-5" href="#section-5">5</a>. DNS server configuration</span>
In the short term, whilst directory service technology and further
types of DNS resource record are being developed, domain name
administrators are encouraged to use these common names for the
network services they run. They will make it easier for outsiders to
find information about your organization, and also make it easier for
you to move services from one machine to another.
There are two conventional approaches to creating these DNS entries.
One is to add a single CNAME record to your DNS server's
configuration, e.g.
ph.hivnet.fr. IN CNAME baby.hivnet.fr.
Note that in this scenario no information about ph.hivnet.fr should
exist in the DNS other than the CNAME record. For example,
ph.hivnet.fr could not contain a MX record.
An alternative approach would be to create an A record for each of
the IP addresses associated with ph.hivnet.fr, e.g.
ph.hivnet.fr. IN A 194.167.157.2
It isn't a simple matter of recommending CNAMEs over A records. Each
site has it's own set of requirements that may make one approach
better than the other. <a href="./rfc1912">RFC 1912</a> [<a href="./rfc1912" title=""Common DNS Operational and Configuration Errors"">RFC-1912</a>] discusses some of the
configuration issues involved in using CNAMEs.
<span class="grey">Hamilton & Wright Best Current Practice [Page 4]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-5" ></span>
<span class="grey"><a href="./rfc2219">RFC 2219</a> DNS Aliases October 1997</span>
Recent DNS server implementations provide a "round-robin" feature
which causes the host's IP addresses to be returned in a different
order each time the address is looked up.
Network clients are starting to appear which, when they encounter a
host with multiple addresses, use heuristics to determine the address
to contact - e.g. picking the one which has the shortest round-trip-
time. Thus, if a server is mirrored (replicated) at a number of
locations, it may be desirable to list the IP addresses of the mirror
servers as A records of the primary server. This is only likely to
be appropriate if the mirror servers are exact copies of the original
server.
<span class="h2"><a class="selflink" id="section-6" href="#section-6">6</a>. Limitations of this approach</span>
Some services require that a client have more information than the
server's domain name. For example, an LDAP client needs to know a
starting search base within the Directory Information Tree in order
to have a meaningful dialogue with the server. This document does
not attempt to address this problem.
<span class="h2"><a class="selflink" id="section-7" href="#section-7">7</a>. CCSO service name</span>
There are currently at least three different aliases in common use
for the CCSO nameserver - e.g. "ph", "cso" and "ns". It would appear
to be in everyone's interest to narrow the choice of alias down to a
single name. "ns" would seem to be the best choice since it is the
most commonly used name. However, "ns" is also being used by DNS to
point to the DNS server. In fact, the most prevalent use of "ns" is
to name DNS servers. For this reason, we suggest the use of "ph" as
the best name to use for CCSO nameservers.
Sites with existing CCSO servers using some of these aliases may find
it desirable to use all three. This increases the likelihood of the
service being found.
As noted earlier, implementations should be resilient in the event
that the name does not point to the expected service.
<span class="h2"><a class="selflink" id="section-8" href="#section-8">8</a>. Security Considerations</span>
The DNS is open to many kinds of "spoofing" attacks, and it cannot be
guaranteed that the result returned by a DNS lookup is indeed the
genuine information. Spoofing may take the form of denial of
service, such as directing of the client to a non-existent address,
or a passive attack such as an intruder's server which masquerades as
the legitimate one.
<span class="grey">Hamilton & Wright Best Current Practice [Page 5]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-6" ></span>
<span class="grey"><a href="./rfc2219">RFC 2219</a> DNS Aliases October 1997</span>
Work is ongoing to remedy this situation insofar as the DNS is
concerned [<a href="./rfc2065" title=""Domain Name System Security Extensions"">RFC-2065</a>]. In the meantime it should be noted that
stronger authentication mechanisms such as public key cryptography
with large key sizes are a pre-requisite if the DNS is being used in
any sensitive situations. Examples of these would be on-line
financial transactions, and any situation where privacy is a concern
- such as the querying of medical records over the network. Strong
encryption of the network traffic may also be advisable, to protect
against TCP connection "hijacking" and packet sniffing.
<span class="h2"><a class="selflink" id="section-9" href="#section-9">9</a>. Conclusions</span>
The service names listed in this document provide a sensible set of
defaults which may be used as an aid in determining the hosts which
offer particular services for a given domain name.
This document has noted some exceptions which are either inherently
unsuitable for this treatment, or already have a substantial
installed base using alternative aliases.
<span class="h2"><a class="selflink" id="section-10" href="#section-10">10</a>. Acknowledgements</span>
Thanks to Jeff Allen, Tom Gillman, Renato Iannella, Thomas
Lenggenhager, Bill Manning, Andy Powell, Sri Sataluri, Patrik
Faltstrom, Paul Vixie and Greg Woods for their comments on draft
versions of this document.
This work was supported by UK Electronic Libraries Programme (eLib)
grant 12/39/01, the European Commission's Telematics for Research
Programme grant RE 1004, and U. S. Department of Energy Contract
Number DE-AC03-76SF00098.
<span class="h2"><a class="selflink" id="section-11" href="#section-11">11</a>. References</span>
Request For Comments (RFC) documents are available from
<URL:ftp://ftp.internic.net/rfc> and numerous mirror sites.
[<a id="ref-ARCHIE">ARCHIE</a>] A. Emtage, P. Deutsch. "archie - An Electronic
Directory Service for the Internet", Winter Usenix
Conference Proceedings 1992. Pages 93-110.
[<a id="ref-PH">PH</a>] R. Hedberg, S. Dorner, P. Pomes. "The CCSO
Nameserver (Ph) Architecture", Work in Progress.
[<a id="ref-RFC-768">RFC-768</a>] Postel, J., "User Datagram Protocol", STD 6, <a href="./rfc768">RFC 768</a>,
August 1980.
<span class="grey">Hamilton & Wright Best Current Practice [Page 6]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-7" ></span>
<span class="grey"><a href="./rfc2219">RFC 2219</a> DNS Aliases October 1997</span>
[<a id="ref-RFC-793">RFC-793</a>] Postel, J., "Transmission Control Protocol", STD 7,
<a href="./rfc793">RFC 793</a>, September 1981.
[<a id="ref-RFC-821">RFC-821</a>] Postel, J., "Simple Mail Transfer Protocol", STD 10,
<a href="./rfc821">RFC 821</a>, August 1982.
[<a id="ref-RFC-954">RFC-954</a>] Harrenstien, K., Stahl, M., and E. Feinler,
"NICNAME/WHOIS", <a href="./rfc954">RFC 954</a>, October 1985.
[<a id="ref-RFC-959">RFC-959</a>] Postel, J., and J.K. Reynolds, "File Transfer
Protocol", STD 9, <a href="./rfc959">RFC 959</a>, October 1985.
[<a id="ref-RFC-974">RFC-974</a>] Partridge, C., "Mail routing and the domain
System", STD 14, <a href="./rfc974">RFC 974</a>, January 1986.
[<a id="ref-RFC-977">RFC-977</a>] Kantor, B., and P. Lapsley, "Network News Transfer
Protocol", <a href="./rfc977">RFC 977</a>, February 1986.
[<a id="ref-RFC-1034">RFC-1034</a>] Mockapetris, P., "Domain names - concepts and
facilities", STD 13, <a href="./rfc1034">RFC 1034</a>, November 1987.
[<a id="ref-RFC-1035">RFC-1035</a>] Mockapetris, P., "Domain names - implementation
and specification", STD 13, <a href="./rfc1035">RFC 1035</a>, November 1987.
[<a id="ref-RFC-1123">RFC-1123</a>] Braden, R., "Requirements for Internet hosts -
application and support", STD 3, <a href="./rfc1123">RFC 1123</a>, October 1989.
[<a id="ref-RFC-1288">RFC-1288</a>] Zimmerman, D., "The Finger User Information
Protocol", <a href="./rfc1288">RFC 1288</a>, December 1992.
[<a id="ref-RFC-1305">RFC-1305</a>] Mills, D., "Network Time Protocol (Version 3)
Specification, Implementation", <a href="./rfc1305">RFC 1305</a>, March 1992.
[<a id="ref-RFC-1436">RFC-1436</a>] Anklesaria, F., McCahill, M., Lindner, P., Johnson, D.,
Torrey, D., and B. Albert, "The Internet Gopher Protocol
(a distributed document search and retrieval protocol)",
<a href="./rfc1436">RFC 1436</a>, March 1993.
[<a id="ref-RFC-1590">RFC-1590</a>] Postel, J., "Media Type Registration Procedure",
<a href="./rfc1590">RFC 1590</a>, March 1994.
[<a id="ref-RFC-1625">RFC-1625</a>] St. Pierre, M., Fullton, J., Gamiel, K., Goldman, J.,
Kahle, B., Kunze, J., Morris, H., and F. Schiettecatte,
"WAIS over Z39.50-1988", <a href="./rfc1625">RFC 1625</a>, June 1994.
[<a id="ref-RFC-1700">RFC-1700</a>] Reynolds, J.K., and J. Postel, "ASSIGNED NUMBERS",
STD 2, <a href="./rfc1700">RFC 1700</a>, October 1994.
<span class="grey">Hamilton & Wright Best Current Practice [Page 7]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-8" ></span>
<span class="grey"><a href="./rfc2219">RFC 2219</a> DNS Aliases October 1997</span>
[<a id="ref-RFC-1714">RFC-1714</a>] Williamson, S., and M. Kosters, "Referral Whois
Protocol (RWhois)", <a href="./rfc1714">RFC 1714</a>, November 1994.
[<a id="ref-RFC-1777">RFC-1777</a>] Yeong, W., Howes, T., and S. Kille, "Lightweight
Directory Access Protocol", <a href="./rfc1777">RFC 1777</a>, March 1995.
[<a id="ref-RFC-1912">RFC-1912</a>] Barr, D., "Common DNS Operational and Configuration
Errors", <a href="./rfc1912">RFC 1912</a>, Feburary 1996.
[<a id="ref-RFC-1939">RFC-1939</a>] Myers, J., and M. Rose, "Post Office Protocol - Version
3", STD 53, <a href="./rfc1939">RFC 1939</a>, May 1996.
[<a id="ref-RFC-1945">RFC-1945</a>] Berners-Lee, T., Fielding, R., and H. Nielsen,
"Hypertext Transfer Protocol -- HTTP/1.0", <a href="./rfc1945">RFC 1945</a>, May
1996.
[<a id="ref-RFC-2052">RFC-2052</a>] Gulbrandsen, A., and P. Vixie, "A DNS RR for specifying
the location of services (DNS SRV)", <a href="./rfc2052">RFC 2052</a>, October
1996.
[<a id="ref-RFC-2065">RFC-2065</a>] Eastlake, D., and C. Kaufman, "Domain Name System
Security Extensions", <a href="./rfc2065">RFC 2065</a>, January 1997.
<span class="h2"><a class="selflink" id="section-12" href="#section-12">12</a>. Authors' Addresses</span>
Martin Hamilton
Department of Computer Studies
Loughborough University of Technology
Leics. LE11 3TU, UK
EMail: m.t.hamilton@lut.ac.uk
Russ Wright
Information & Computing Sciences Division
Lawrence Berkeley National Laboratory
1 Cyclotron Road, Berkeley
Mail-Stop: 50A-3111
CA 94720, USA
EMail: wright@lbl.gov
Hamilton & Wright Best Current Practice [Page 8]
</pre>
|
