Date: Fri, 10 Feb 95 09:07:20 CST
   From: (Dan Connolly)

   [ . . . ]

   But as another solution, it seems that something like the MX record
   facility for finding SMTP servers would work well for HTTP servers.

   This "HX record" would map a domain name to one or more domain/port
   pairs or [ . . . ]

The basic problem is that at the moment of accepting a client's
connection, the server has in hand the IP address of the client but
not a clue about either the IP address or domain to which the client
believes it is connecting.  Hence, an "HX" won't do the server any
good for making a decision about what to do next.

The notion of something like an "HX" record analogous to an MX
record might make some sense despite this, since some sites will want
to support off-site or redundant HTTP servers.   But a new "HX" type
is NOT a good idea because it requires formally extending the DNS

However, you can easily implement the exact equivalent of an "HX" RR
type by using Hesiod's TXT type RR, which allows for application-specific
syntax and semantics in its text portion.  For example, you might have
this pair of records for "bigsite" and "smallsite":   HS TXT  "  http://other.provider/bigsite" HS TXT  ""

The syntax of the text string is simply a list of URLs:  a client
receiving this RR would try the first URL, then the second, and so
forth, when searching for the site's "Home Page".  For example, given
"", after retrieving the Hesiod record for
"" the WWW client would start out by trying to GET
"" and then "http://other.provider/bigsite"
if the first attempt failed.

As a default, you could obviously use the same rule used for MX
records:  absent our "HX" record, the HTTP client should attempt to
connect directly to the domain mentioned in the URL (i.e.

On the downside, unlike the case an MX record, you can't discover this
HS class TXT record for "www.domain" by simply asking your local
nameserver for class "IN", type "ANY" records for the domain.  You
have to make a separate query using the "HS" class to get the record.
Caching at the local nameserver should reduce the impact.

The fact that DNS zones are (in theory) always replicated means that
this record will (in theory) be redundantly available to all clients
on the net.

- Bede McCall   <>

   The MITRE Corporation                      Tel: (617) 271-2839
   Bedford, Massachusetts                     FAX: (617) 271-2423

Received on Friday, 10 February 1995 22:47:53 UTC