[Search] [txt|pdf|bibtex] [Tracker] [WG] [Email] [Nits]

Versions: 00 01 02 03 04 05                                             
Internet-Draft                                                Ryan Moats
draft-ietf-svrloc-advertise-00.txt                                  AT&T
Expires in six months                                    Martin Hamilton
                                                 Loughborough University
                                                           February 1997


                          Advertising Services
          (Providing information to support service discovery)
              Filename: draft-ietf-svrloc-advertise-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

   This document proposes a solution to the problem of finding
   information about that services are being offered at a particular
   Internet domain, based on deployment experience with the Netfind
   White Pages directory software.

   This approach makes it possible to supply clients with more
   information than the DNS aliases that have been widely deployed in
   this role - notably the port numbers being used by servers.  However,
   it is not without problems, and we have tried to take account of
   these.







Expires 8/31/97                                                 [Page 1]


INTERNET DRAFT            Advertising Services             February 1997


1. Rationale

   There is no one single way of discovering the network services and
   application protocols supported at a particular Internet domain.  The
   Domain Name System (DNS - [1,2]) provides some basic facilities for
   finding the hosts that offer particular services, such as DNS servers
   themselves (NS records), and mail exchangers (MX records).  It does
   not provide a mechanism for locating arbitrary servers of arbitrary
   protocols, or a search capability.

   In addition to the name and IP address(es) of the host offering the
   service, clients also sometimes require further information to make
   effective use of the service - e.g. TCP or UDP port numbers, protocol
   version information, and information about the protocol options
   supported by the server.  Another example would be the organization's
   base within the X.500 [3] Directory Information Tree (DIT), which is
   needed for X.500 browsing and searching.

   At the time of writing, it was common practice to "hint" at the
   services and protocols offered at a given domain via DNS aliases. For
   example, the alias "www.internic.net" implies that the HTTP server
   for the domain "internic.net" is running on TCP port 80 of the
   machine (or machines) that answer to the name "www.internic.net."  A
   slight formalization of this approach is proposed by [4].  Other
   schemes have been suggested for explicitly registering services
   either by DNS extensions, as in [5], or by dedicated directory
   services such as X.500.

   Several mechanisms have been suggested to address the problem of
   finding this service information, ranging from new DNS record types
   to dedicated directory services.  No single one of these would-be
   solutions has as yet gained the competitive edge. If the lengthy
   gestation period to date is anything to go by, it seems that we can
   expect even more delay before there is any widespread deployment -
   unless there is a "killer application" that forces the issue.

2. Where Netfind has gone before

   The Netfind software [6,7] follows what has been proposed in RFC 1588
   [8]:  using URLs [9] for passing directory service information to
   clients. It uses stylized Text (TXT) record encoding within the DNS
   and currently understands the following "White Pages" URLs:

     -----------------------------------------------------------
     White Pages URL             Information
     -----------------------------------------------------------
     wp-noop://                  This site should not be visited
     wp-dap://<sb>               X.500 search base for the site



Expires 8/31/97                                                 [Page 2]


INTERNET DRAFT            Advertising Services             February 1997


          e.g. wp-dap://o=Loughborough%20University,c=GB
     wp-ph://host/port           Indicates CCSO nameserver [10]
     wp-whois://host/port        Indicates WHOIS [11] server
     wp-smtp-expn-finger://host  Use the SMTP [12] EXPN command,
                                   and the finger [13] protocol
     wp-smtp-expn://host/port    Indicates the SMTP EXPN command
     wp-finger://host/port       Indicates the finger protocol
     wp-telnet://host/port       Indicates a text based info
                                   service that should be used
                                   via telnet [14]
     -----------------------------------------------------------

   Note that the notation "protocol://host/port" is used, rather than
   the "protocol://host:port" format that is being standardized for
   generic URLs.

   Note also that these URL schemes have not all been standardized,
   although wp-ph and wp-whois may be accommodated by translation to the
   widely supported Internet Gopher Protocol [15].

3. A simple interim solution

   In this document, we propose that the "service:" URL scheme as
   described in [17] be encoded in DNS TXT records as a solution.  With
   this scheme, software agents would do a DNS lookup on
   <service>.<domain name>.  The TXT record associated with
   <service>.<domain name> would have the following syntax:

   <service> IN TXT "service:<srvtag>-<url> [preference] [protocol
   specific information]"

   where the preference value and protocol specific information are
   optional and are separated by spaces.  Alternatively, software agents
   could do a lookup on the parent domain, but this could lead to
   overloading the DNS response packet.

   We propose that the following values be used for <srvtag>

     ---------------------------------------------------------------------
     Prefix   Meaning
     ---------------------------------------------------------------------
     keys     Public key server info
     wp      "White Pages" service info
     yp      "Yellow Pages" service info
     ---------------------------------------------------------------------

   This scheme is not compatible with the Netfind "wp-" scheme, but that
   is not viewed as a problem owing to lack of deployment of "wp-" URLs.



Expires 8/31/97                                                 [Page 3]


INTERNET DRAFT            Advertising Services             February 1997


   Alternatively, clients may support both "wp-" URLs and "service:"
   URLs.

   Thus for general white pages discovery, we propose that software
   agents do a DNS lookup on wp.<domain name>.  Here, the TXT records
   would contain URLs of the "wp-" service type.  For example, the TXT
   records for wp.lut.ac.uk could be written as

     service:wp-ldap://ldap.lut.ac.uk/o=Loughborough%20University%20of%20
       Technology,c=GB
     service:wp-http://www.lut.ac.uk/cgi-bin/local

   Whilst not an optimal solution, for reasons we will discuss below,
   this approach does provide an additional level of flexibility and
   only requires a trivial amount of work to deploy - typically adding a
   single line to the site's DNS configuration file for each service
   being advertised.  In addition, several of the "service:" URL schemes
   proposed here are documented in [19].

4. Further details and usage scenarios

4.1. Finding "White Pages" information

   This is the case that is already catered for by the Netfind "wp-"
   prefix.  To advertise their White Pages services explicitly, a site
   would create one or more TXT records under both wp and the service
   being advertised, e.g.

     wp IN TXT "service:wp-ldap://ldap.lut.ac.uk/o=Loughborough%20University
       %20of%20Technology,c=GB"
     wp IN TXT "service:wp-whois://whois.lut.ac.uk/"
     wp IN TXT "service:wp-ccso://cso.lut.ac.uk/2"

     ldap IN TXT "service:wp-ldap://ldap.lut.ac.uk/o=Loughborough%20University
       %20of%20Technology,c=GB"

     whois IN TXT "service:wp-whois://whois.lut.ac.uk/"

     ph IN TXT "service:wp-ccso://cso.lut.ac.uk/2"

   Another example showing the possibility of multiple protocols for
   accessing a service would be (the domain for this example is
   aecom.yu.edu):

    ns IN TXT "service:wp-gopher://gopher.aecom.yu.edu/2"
    ns IN TXT "service:wp-http://www.middlebury.edu/cgi-bin/
               WebPh?other_ph_servers"
    ns IN TXT "service:wp-http://faker.ncsa.uiuc.edu:8080/cgi-bin/phfd"



Expires 8/31/97                                                 [Page 4]


INTERNET DRAFT            Advertising Services             February 1997


   It is envisaged that this information could be used in some
   scenarios.  Assuming their Internet domain is aleady known, mail user
   agents with integrated support could offer to do directory service
   lookups to determine a correspondent's address from their name, to
   verify the contents of address books, and to determine alternative
   email addresses should delivery fail.  This last technique might also
   be applied by lower level mail delivery software.

4.3. Public key lookup

   Attempts to build a scalable infrastructure for the distribution of
   public key information, in particular for the public keys of
   individuals, have been hampered by the lack of a convention that
   could be used to suggest the public key servers for a site or
   organization.

   The "keys-" prefix gives us a flexible means by which this may be
   done, e.g.

     keys IN TXT "service:keys-finger://mrrl.lut.ac.uk 5"

     lut.ac.uk IN TXT "service:keys-finger://mrrl.lut.ac.uk 5"

   It does not, however, address the issue of public key (certificate)
   format.  It is expected that this would be taken care of by format
   negotiation in the protocol or protocols being used to do the lookup.

   Public key lookup would be of immediate use in software that has
   integrated support for public key authentication, signing and
   encryption - e.g. mail and news user agents.

4.4. Finding "Yellow Pages" information

   By "Yellow Pages" we mean a catch-all category: information about
   services offered that do not fall into any of the above categories.

   For example, consider the case of a machine that is running a HTTP
   server - but not on the IANA registered default port (80)

     www IN A 204.179.186.65
         IN A 198.49.45.10
         IN A 192.20.239.132
         IN TXT "service:yp-http://www.ds.internic.net:8888/"

     yp  IN A 204.179.186.65
         IN A 198.49.45.10
         IN A 192.20.239.132
         IN TXT "service:yp-http://www.ds.internic.net:8888/"



Expires 8/31/97                                                 [Page 5]


INTERNET DRAFT            Advertising Services             February 1997


   This "Yellow Pages" mechanism provides a means for DNS maintainers to
   effectively register the existence of their major network services.
   This can have a variety of uses - e.g. the service information is
   available to any "web crawler" type applications that might choose to
   index it, and to interactive applications such as World-Wide Web
   browsers, that might use it to override their default behavior.

4.5 Finding "Directory Agent" information

   [20] also defines a scheme for Directory Agent discovery (Here
   directory is being used in the SVRLOC context, not the IDS context).
   A site may wish to present services to hosts outside its domain may
   elect to set up a Directory Agent (with the remote registration
   features turned off, see [20]) outside its firewall.  A client
   supporting the service location protocol would then make queries for
   individual services inside the domain.  The Directory Agent would be
   found via the following DNS entries:

   (Domain entry)
   catch22.com IN TXT "service:directory-agent://slp-resolver.catch22.com"

   (host in domain catch22.com)
   directory-agent IN TXT "service:directory-agent://slp-resolver.catch22.com"

5. Support in DNS clients and servers

   This scheme is completely compatible with SRV and NAPTR (see [18])
   DNS records, that are currently being implemented in BIND.

6. Limitations of this approach

   Note that older DNS servers may not support the TXT record type, and
   some servers fail to implement it properly - e.g. BIND 4.9.2 misses
   out every other letter in the TXT record.  Further, support for SRV
   has only recently been added to the BIND code base.

   Some resolvers are not capable of requesting a TXT record, or not
   capable of generating any DNS lookup requests other than a simple
   address lookup.  TXT records can actually be requested by setting the
   question type in the request to 16 (decimal), regardless of the
   symbolic names defined by the stack's resolver code.  Implementing
   more advanced resolver functionality when the stack only provides
   address lookup requires a little work, but sample code is freely
   available.

   The size limitations on DNS packets will have some effect on the
   number of URLs that can be associated with a domain name using TXT
   records.  Response packets are liable to be truncated if they grow to



Expires 8/31/97                                                 [Page 6]


INTERNET DRAFT            Advertising Services             February 1997


   over 576 bytes.

   Characters that are illegal in URLs must be escaped, for example:

     "service:wp-ldap://ldap.lut.ac.uk/o=Loughborough%20University%20of
       %20Technology,c=GB"

   Domain name compression is normally used to reduce the size of the
   response packet needed for a given domain name.  Clearly, this will
   not be possible on arbitrary strings embedded within the response
   packet.

   Widespread use of TXT records in the role proposed by this document
   would increase the amount of information held in nameserver caches,
   and in particular might cause problems where negative caching is
   concerned.  Consequently we suggest that clients use them as a fall
   back mechanism if more conventional methods, such as DNS aliases,
   prove unproductive.

7. Security Considerations

   Since this draft proposes to use DNS for storage of URL information,
   all the normal security considerations for applications that depend
   on the DNS apply.  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
   that masquerades as the legitimate one.

   Work is ongoing to remedy this issue insofar as the DNS is concerned
   [16].  In the meantime, note 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 environment.
   Examples of these would be on-line financial transactions, and any
   scenario 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.

   There are some additional considerations that are specific to URLs.
   Specifically, client applications should be wary of URLs that direct
   them to alternative Internet domains and/or unusual port numbers.
   They should also be proactive when passing URLs to external programs,
   to ensure that the user's environment is not exposed to malevolent
   meta-characters.  Finally, implementors should take care to avoid
   buffer overruns when processing these DNS response packets.




Expires 8/31/97                                                 [Page 7]


INTERNET DRAFT            Advertising Services             February 1997


8. Conclusions

   Whilst far from ideal, we believe the approach outlined in this
   document does provide a workable interim solution to the problem of
   locating the network services offered at a particular Internet domain
   - particularly when used in combination with DNS aliases, as outlined
   in [4].  Suitable DNS server software is already widely deployed, and
   client support may be implemented without any great difficulty.

   It is debatable whether any of this is strictly necessary.  Certainly
   there is less work involved in adding a few lines to an existing DNS
   server configuration than in setting up a whole new directory
   service, such as X.500.  From this point of view, a new DNS resource
   record type or types would perhaps address the problem more
   effectively, but it may be some time before any new types are widely
   deployed.

9. Acknowledgments

   Special thanks to Erik Guttman for his help with the service location
   example, information on the "service:" scheme, as well as much e-mail
   in working out the service schemes proposed here.  Thanks to Tim
   Howes, Sri Sataluri and <<your name here!!>> for their comments on
   earlier drafts of this document. This document is partially supported
   by the National Science Foundation, Cooperative Agreement NCR-
   9218179, the UK Electronic Libraries Programme (eLib) grant 12/39/01,
   and the European Commission's Telematics for Research Programme grant
   RE 1004.

   The format used for representing Netfind White Pages URLs within the
   DNS was originally defined by Mike Schwartz, with help from Carl
   Malamud and Marshall Rose.  The Netfind work was supported in part by
   grants from the National Science Foundation, the Advanced Research
   Projects Agency, Sun Microsystems' Collaborative Research Program,
   and AT&T Bell Laboratories.

   Some of the points in the security considerations section were drawn
   from [4].

10. References

   Request For Comments (RFC) and Internet Draft documents are available
   from <URL:ftp://ftp.internic.net> and numerous mirror sites.

         [1]         P. V. Mockapetris. "Domain names - concepts and
                     facilities," RFC 1034.  November 1987.





Expires 8/31/97                                                 [Page 8]


INTERNET DRAFT            Advertising Services             February 1997


         [2]         P. V. Mockapetris. "Domain names - implementation
                     and specification," RFC 1035.  November 1987.


         [3]         C. Weider, J. Reynolds, S. Heker.  "Technical Over-
                     view of Directory Services Using the X.500 Proto-
                     col," RFC 1309.  March 1992.


         [4]         M. Hamilton, R. Wright.  "Use of DNS Aliases for
                     Network Services," Internet Draft (work in pro-
                     gress). June 1996.


         [5]         A. Gulbrandsen, P. Vixie. "A DNS RR for specifying
                     the location of services (DNS SRV)," RFC 2052.
                     October 1996.


         [6]         M. F. Schwartz. "Netfind Support for URL-Based
                     Search Customization," June 28, 1994.
                     <URL:ftp://ftp.cs.colorado.edu/pub/cs/distribs/
                     netfind/Netfind.WP.URLs>


         [7]         M. F. Schwartz, C. Pu.  "Applying an Information
                     Gathering Architecture to Netfind: A White Pages
                     Tool for a Changing and Growing Internet," Univer-
                     sity of Colorado Technical Report CU-CS-656-93.
                     December 1993, revised July 1994.
                     <URL:ftp://ftp.cs.colorado.edu/pub/cs/techreports/
                     schwartz/Netfind.Gathering.txt.Z>


         [8]         J. Postel, C. Anderson. "White Pages Meeting
                     Report," RFC 1588.  February 1994.


         [9]         T. Berners-Lee, L. Masinter & M. McCahill.  "Uni-
                     form Resource Locators (URL)," RFC 1738.  December
                     1994.


         [10]        R. Hedberg, S. Dorner, and P. Pomes. "The CCSO
                     Nameserver (Ph) Architecture," Internet Draft (work
                     in progress), January 1996.





Expires 8/31/97                                                 [Page 9]


INTERNET DRAFT            Advertising Services             February 1997


         [11]        K. Harrenstien, M. K. Stahl, E.J. Feinler.
                     "NICNAME/WHOIS," RFC 954.  October 1985.


         [12]        D. Crocker.  "Standard for the format of ARPA
                     Internet text messages," RFC 822. August 1982.


         [13]        D. Zimmerman.  "The Finger User Information Proto-
                     col," RFC 1288. December 1992.


         [14]        J. Postel, J .K. Reynolds.  "Telnet Protocol
                     specification," RFC 855.  May 1983.


         [15]        F. Anklesaria, M. McCahill, P. Lindner, D. Johnson,
                     D. Torrey & B. Albert.  "The Internet Gopher Proto-
                     col (a distributed document search and retrieval
                     protocol)," RFC 1436.  March 1993.


         [16]        D. E. Eastlake 3rd, C. W. Kaufman.  "Domain Name
                     System Security Extensions," Internet Draft (work
                     in progress).  August 1996.


         [17]        E. Guttman, "The service: URL Scheme," Internet
                     Draft (work in progress), November 1996.


         [18]        R. Daniel, M. Mealling. "Resolution of Uniform
                     Resource Identifiers using the Domain Name System,"
                     Internet Draft (work in progress), Oct. 30 1996.


         [19]        R. Moats, "Defining White Pages and Yellow Pages
                     Services," Internet Draft (work in progress),
                     February, 1997.


         [20]        J. Veizades, E. Guttman, C. Perkins, S. Kaplan,
                     "Service Location Protocol," Internet Draft (work
                     in progress), January 1997.







Expires 8/31/97                                                [Page 10]


INTERNET DRAFT            Advertising Services             February 1997


11. Authors' addresses

   Ryan Moats
   AT&T
   15621 Drexel Circle
   Omaha, NE 68135-2358
   USA

   Phone:  +1 402 894-9456
   EMail:  jayhawk@ds.internic.net


   Martin Hamilton
   Department of Computer Studies
   Loughborough University of Technology
   Leics. LE11 3TU, UK

   Email:  m.t.hamilton@lut.ac.uk


               This Internet Draft expires August 31, 1997.






























Expires 8/31/97                                                [Page 11]