Use of DNS Aliases for Network Services

Status of this Memo

Abstract

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) [RFC 2052] work.
 

Contents

1. Rationale

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 [RFC 974], 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) [RFC 1035] 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) [RFC 1035] 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 [RFC 1123] in favour of the MX record, and in the long term it is conceivable that SRV records will supersede both WKS and MX.
 

2. A Generic Framework

3. Special Cases

4. (Ab)Use of the DNS as a Directory Service

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 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.
 

5. DNS Server Configuration

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. RFC 1912 [RFC 1912]  discusses some of the configuration issues involved in using CNAMEs.

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.
 

6. Limitations of this Approach

7. CCSO Service Name

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.
 

8. Security Considerations

9. Conclusions

This document has noted some exceptions which are either inherently unsuitable for this treatment, or already have a substantial installed base using alternative aliases.
 

10. Acknowledgements

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.
 

11. References

12. Authors' Addresses

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