home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Internet Info 1997 December
/
Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso
/
drafts
/
draft_ietf_q_t
/
draft-ietf-svrloc-advertising-01.txt
< prev
next >
Wrap
Text File
|
1997-05-08
|
24KB
|
662 lines
Internet-Draft Ryan Moats
draft-ietf-svrloc-advertising-01.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-advertising-01.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]