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;
}