Internet DRAFT - draft-bazyar-dns-locating-services
draft-bazyar-dns-locating-services
HTTP/1.1 200 OK
Date: Mon, 08 Apr 2002 22:45:46 GMT
Server: Apache/1.3.20 (Unix)
Last-Modified: Sat, 02 Mar 1996 13:55:42 GMT
ETag: "304ad8-2a89-3138535e"
Accept-Ranges: bytes
Content-Length: 10889
Connection: close
Content-Type: text/plain
INTERNET-DRAFT Jawaid Bazyar
rev 1.0 January 20, 1996
Expires June 20, 1996
Locating Services through the DNS
filename: draft-bazyar-dns-locating-services-00.txt
STATUS OF THIS MEMO
This document is an Internet-Draft. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its
areas, and its working groups. Note that other groups may also
distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other
documents at any time. It is inappropriate to use Internet-
Drafts as reference material or to cite them other than as
``work in progress.''
To learn the current status of any Internet-Draft, please check
the ``1id-abstracts.txt'' listing contained in the Internet-
Drafts Shadow Directories on ftp.is.co.za (Africa),
nic.nordu.net (Europe), munnari.oz.au (Pacific Rim),
ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast).
ABSTRACT
Internet users continue to find new ways to apply existing Internet
standards and technology. In particular, it has become common usage to
use the DNS to locate services on a particular network, by use of names
like gopher.tc.umn.edu or www.hypermall.com.
This was a natural use of DNS. However, the continued commercialization
of the Internet and the current trend towards service providers who
maintain services and "pseudo-domains" for numerous customers, and the
difficulties of using multiple IP's requires that not only an IP
address, but a port number as well, be available to client software
looking for a particular service.
This draft describes a simple way to support "multi-home" servers
through the DNS, with no changes to existing protocols, and only
minimal additions to client software.
------------------------------------------------------------------------
Table of Contents
1. Typical DNS Naming Schemes & "Multi-home" Servers
2. Advertising Service Ports via DNS
a. Existing use of the DNS 'WKS' field
b. A new twist on an old field
c. Backwards-compatibility
3. Sample Source (patches to Lynx)
4. Impact
Appendix A. Results of survey of use of WKS record
Appendix B. Implementation of getportbyname()
Contacting the Author:
Jawaid Bazyar
Interlink Advertising Services Inc.
PO Box 641
Englewood, CO 80151-0641
(303) 781-3273
(303) 789-4197 (fax)
bazyar@hypermall.com
This draft and the source code listed herein is available at:
ftp://ftp.hypermall.com/pub/mh.tar.tz
1. Typical DNS Naming Schemes & "Multi-home" Servers
It has become common practice to name Internet services existing within
a domain by assigning sub-domain names that are descriptive of the
service provided. For example, ftp.ncsa.uiuc.edu points to the FTP
server for the National Center for Supercomputing Applications at the
University of Illinois at Urbana-Champaign. Similarly, www.netscape.com
is the Netscape corporation's main WWW server. The utility of such
uniform naming systems is obvious - a user can guess the proper name
for a server in a domain that he's never been to before.
Such names that are in common use are
www ftp gopher
archie irc
The preceeding system is sufficient to describe the IP address of a
service, and works well when you mix a variety of services on the same
IP -- the standardized ports are used for each service.
However, when attempting to serve multiple instances of the same
service on the same machine (say, several WWW's or several gopher's)
then there is a problem -- the IP itself is not sufficient to locate
the service on the machine, since the services each use different
ports. This is primarily a concern for commercial Internet providers
who wish to be able to set up "pseudo-domains" (many domain names
transparently aliased to the same machine). There are three solutions
under the existing system:
Tack on a subdirectory name
http://www.company.com/company/
This is generally unacceptable, because of the redundancy.
Businesses want a nice clean URL.
Tack on a port number
http://www.company.com:1234/
This is unacceptable for the same reason as above, and for
the further reason that there is now a hard-to-remember
arbitrary number in the mix.
Use Multiple IP's and "IP aliasing"
http://www.company.com/
This works great - as long as you're a small provider and
as long as your machine's OS support IP aliasing (not many
do). The main problem with this is the use of all the IP's.
Providers that have a few hundred clients, each with their
own domain name (or even sub-domain name), will have to use
hundreds of IP addresses. This will require them to request
multiple class C networks for "pseudo-domains". This should
be considered unreasonable. The other major problem with
this is performance. IP aliasing often requires the OS to
run its network driver in "promiscuous" mode. This means the
kernel must inspect every packet going across the local
network. While IP aliasing was a good short-term workaround
for this problem, it is not tenable in the long term.
As we can see, some new method for supporting multi-home servers
must be developed.
2. Advertising Service Ports via DNS
This draft proposes to change the definition of the DNS 'WKS' record
slightly, to enable it to advertise ports for services in a domain.
The existing use of the WKS record is to advertise the active service
ports on a host. However, in this day of security concerns and "port
sniffers" that are used to help break security, advertising the active
ports on a server is tantamount to "aiding and abetting the enemy". In
my survey of existing Internet DNS records, very few (5% or so) actually
used the WKS record (See appendix A). From conversations with DNS
administrators, the WKS record is essentially obsolete.
Since many domain names actually denote a _service_ more than a
particular host, it makes sense to include the port of the service
along with the other DNS information. The WKS record can be used to
accomplish this.
If there are multiple ports specified in the WKS record for a host:
Assume that the DNS administrator used the WKS record
for its pedantic purpose, and that this is an advertisement
of active ports. The browser should use the standard port.
If there is no WKS record specified:
The browser should use the standard port.
If there is exactly one port specified in the WKS record:
This is a use of WKS as specified in this draft. Use the
port number specified in the WKS record to contact the server.
As you can see, this draft does not replace, but rather extends the
definition of the WKS record. It is backward-compatible with the old
definition, with the extremely unlikely exception of a server that used
WKS for its original purpose but only advertised one port.
For this system to work, an Internet client program (whether a web
browser, FTP client, Prospero interface, etc) must know about and
utilize the new kind of information in the WKS record. The system has
been designed to make obtaining this information as simple as possible.
3. Sample Source & Test Server (patches to Lynx and lresolv+)
I have created a function call, eventually to be added to the resolv+
package): 'getportbyname'. This new call queries the DNS system for a
WKS record for the specified host, and returns a result according to the
algorithm presented in the previous section:
If there are multiple ports specified in the WKS record for a host:
getportbyname returns -1.
If there is no WKS record specified:
getportbyname returns -1.
If there is exactly one port specified in the WKS record:
getportbyname returns that port number.
Inside Lynx's libWWW module, in the function HTParseInet (HTTCP.c), I
have added appropriate code near the end of the function to use
getportbyname.
/* begin inserted code */
{
int nport;
if ((nport = getportbyname(host)) > 0)
sin->sin_port = htons((short)nport);
}
/* end inserted code */
return 0; /* OK */
}
There is a test http server running at HyperMall: www2.hypermall.com.
The DNS records for this hostname are:
www2 IN WKS www.hypermall.com. 6 81
IN A 204.181.152.101
The WKS record specifies a single port, #81. If you make the patches
described above to Lynx (or make similar changes to other browsers)
you should be able to access the www2 server (running on port 81)
by simply using the URL:
http://www2.hypermall.com/
(The source code is available at ftp://ftp.hypermall.com/pub/multihome)
4. Impact
The system described in this paper shouldn't have any direct impact on
current use of the WWW or the DNS. There is one issue that I'd like
to address, however.
The system described in this paper doesn't affect DNS Shuffle set-ups.
However, a domain that wants to use this system and DNS Shuffle must
make sure that the affected service uses the same port on all the
concerned machines.
I consider this system a temporary solution. A more robust standard
for locating Internet services by name needs to be developed, and I
will address that in a future memo.
Appendix A. DNS Research Results
Unless otherwise noted, there was no WKS record for the listed domain.
Out of 58 domains queried, only 6 used WKS at all. These (listed below)
use it only sporadically. There were no www.* domains with WKS records.
aristotle.algonet.se - 21 23 25 69
ftp.ncsa.uiuc.edu - strange use - advertises port 80 on 3 servers
stomate.essc.psu.edu - advertises #21 and #23
euler.ucsf.EDU - 21, 23, 25
apple.com - 7 9 13 19 37 53 69 123
c.gp.cs.cmu.edu - 21, 25, 79
B. Implementation of the getportbyname() function.
#include <netinet/in.h>
#include <arpa/nameser.h>
#include <resolv.h>
#include <fcntl.h>
#define RET_SIZE 512
int getportbyname(char *name)
{
unsigned char buf[RET_SIZE],vl;
int result;
int i,j;
char *ptr;
int fd;
int length;
int numports = 0, lastport = 0;
result = res_query( name, C_IN, T_WKS, buf, RET_SIZE );
if (result == -1) return -1;
ptr = buf + 12;
while (*ptr) { /* Skip the name */
ptr += (*ptr + 1);
}
ptr++; /* Skip the null byte */
ptr += 14; /* ptr now points to the WKS RDATA */
length = ntohs(*((short *)ptr));
ptr += 7; /* skip the length, IP address, protocol type fields */
length -= 5; /* adjust the length field */
for (i = 0; i < length ; i++,ptr++) {
if (*ptr) {
vl = *ptr;
for (j = i * 8; j < i * 8 + 8; j++) {
if (vl & 0x80) {
numports++;
lastport = j;
}
vl <<= 1;
}
}
}
if (numports == 1) return lastport;
else return -1;
}
