Discovering proxy servers.

I Find Karma (
Thu, 24 Apr 97 04:33:45 PDT

See if you can spot the DNS abuse in this Internet-Draft.
:) Adam

Network Working Group Josh Cohen
Internet-Draft Netscape Communications
Expires in 6 Months 24 March 1997

Discovering proxy servers

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 (Africa), (Europe), (Pacific Rim), (US East Coast), or (US West Coast).


This document describes a method for automating 'out of the box'
configuration of WWW clients via the Server Location Protocol.

Presently, the most popular method of automatic browser configuration
is via a Proxy Autoconfig file, which is delivered upon request to
the browser. Unfortunately, the URL of this PAC file must still be
specified by the user or administrator.


The Server Location Protocol working group has defined a number of
Internet Drafts on how to locate and advertise services on IP
networks. This draft suggests using the method described in [SRVURL]
and [SVRADV] to advertise the URL of the autoconfig file.

If has been suggested that a client should use DHCP in [KWAN] to
determine this URL, but presently, there is no cross platform way to
reference DHCP configuration options. Because of this, the author
suggests using the Server Location protocol.

J. Cohen [Page 1]

INTERNET-DRAFT Discovering proxy servers 24 March 1997

By following the recommendations in this draft, an administrator can
expect that a user will procure a conforming web client, install it
on their computer and have the product automagically configure itself
for the appropriate proxy policies based on the clients domain.

Advertising the URL

As specified in [SRVADV] and [SRVRR], service: URLs can be advertised
via DNS. The method for advertising these resources in DNS is based
on TXT RRs and SRV RRs. Presently, SRV records are not widely
supported, so in the interim, [TXT] recommends using TXT records

The service URL for a PAC file is a service URL defined in [SRVURL].
The general format of a service: URL is:

service: service-location

The explicit format of the URL in DNS TXT records is defined in
[FIND]. The general format is:

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

According to [FIND], srvtag would be 'yp' short for yellow pages.
This is the generic tag for services, as opposed to 'wp' or white
pages for people.

Service should be 'w3-ns-pac' to specify the type of configuration we
are looking for.

An example for a proxy called on port 8080 whose PAC
file is /proxy.pac is:

w3-ns-pac IN TXT "service:yp-"

Discovering the PAC URL

A client should attempt to discover the PAC URL at least as often as
upon each startup. To do so it shall query DNS for TXT RRs with the
identifier w3-ns-pac.

It should start with the most specific domain, and the query, with a
more general domain, until it finds an response.

For example, for a client whose name is, the
client should query, in order:

J. Cohen [Page 2]

INTERNET-DRAFT Discovering proxy servers 24 March 1997

Note the final '.' to speed unsucessful queries.

The 'w3-ns-pac' specifier

The specifier should is unique and it reflects:

the functional area: the world wide web

the origination of: ns (Netscape Communications)
this resource format

the type of resource: PAC (Proxy Auto Config)

By using unique identifiers, administrators can list other
resources for other types of PAC files, should they use
a browser which has its own format.

The PAC file format

This format has generally become a defacto standard, but is
not currently defined in any standards body. Information can be
found at: [PAC]

Security Considerations

Since this discovery method depends on DNS, it is subject to the
same concerns and restrictions as the Domain Name System with
respect to security.

It is presumed that this functionality will be of most use in an
intranet deployment where the DNS servers, and proxy servers are
maintained by the same organization. Therefore, a certain degree
of trust is assumed.


[HTTP] R. Fielding, J. Gettys, J.C. Mogul, H. Frystyk, T. Berners-Lee
"Hypertext Transfer Protocol -- HTTP/1.1", RFC 2068, Jan 1997

[KWAN] S. Kwan, "DHCP Option for Proxy Client Configuration File",
draft-kwan-proxy-client-conf-00.txt, March 1997

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

J. Cohen [Page 3]

INTERNET-DRAFT Discovering proxy servers 24 March 1997

[SRVURL] E. Guttman, "The service: URL Scheme",
<draft-ietf-svrloc-service-scheme-00.txt>, November 1996.

[SVRLOC] C. Perkins, S. Kaplan, J. Veizades, E. Guttman,
"Service Location Protocol", draft-ietf-svrloc-protocol-15.txt,
January 1997

[SVRADV] R. Moats, M. Hamilton, "Advertising Services",
draft-ietf-svrloc-advertise-00.txt February 1997

[FIND] R. Moats M. Hamilton, "Finding Stuff (How to discover)",
draft-ietf-svrloc-discovery-00.txt, February 1997

[PAC] A. Luotonen, "Netscape Proxy Autoconfiguration"
March 1996

Author's Address

Josh Cohen
Netscape Communications Corporation
501 E. Middlefield Rd
Mountain View, CA 94043

Phone (415) 937-4157


The truth is out there.