Subject: SRV records - when?

From: [email-masked]
Date: Sun, 3 Feb 2002 13:28:43 -0800

I hope this is the right place to ask this question - if not please
tell me where. It's been a number of years since the creation
of the protocol-independent SRV resource record yet I know
of no web browsers that implement it for HTTP. I've contacted
web browser manufacturers and they show no interest in using 
it.

This is a problem for me and many other small businessmen
who want fault tolerance for our ecommerce web sites. We must
take expensive steps to implement fault tolerance at the server
side of things when a client-side solution (SRV records) would
be more flexible and less expensive.

While I understand the merits of SRV's protocol-independence
the people who build our web browsers apparently do not. The
designers at Microsoft, (AOL) Netscape, Opera, etc. do not
appear to have a clue as to how useful SRV records would be.
Nor do the users of web browsers, apparently, since they're
not demanding it.

Perhaps what's needed is a http-specific record type similar
to MX records for email. I know this will be an unpopular
suggestion, but it seems that web browser users and designers
need things to be dumbed down before they'll pay attention.

Ed Sawicki

---

From: Jim Reid <[email-masked]>
Date: Mon, 04 Feb 2002 01:31:00 -0800

>>>>> "ed" == ed  <[email-masked]> writes:

    ed> Perhaps what's needed is a http-specific record type similar
    ed> to MX records for email. I know this will be an unpopular
    ed> suggestion, but it seems that web browser users and designers
    ed> need things to be dumbed down before they'll pay attention.

Frankly, I don't see the point. There would appear to be little
significant difference between your proposed new record type and the
SRV record. Even if your new record got through IETF, you still have
*exactly* the same problem we have with SRV records right now. Browser
developers will have to implement support for them. They might as well
do the Right Thing and implement SRV records which would be more
useful in the long run.

---

From: Kenneth Porter <[email-masked]>
Date: 04 Feb 2002 13:32:16 -0800

> web browser manufacturers and they show no interest in using 

At least for Open Source clients, check out http://ruli.sourceforge.net.
RULI is a client library for dealing with SRV records.

---

From: Jaap Akkerhuis <[email-masked]>
Date: Tue, 05 Feb 2002 10:47:12 +0100

Nice work, but note the Applicability Statement in the SRV RFC:

   In general, it is expected that SRV records will be used by clients
   for applications where the relevant protocol specification indicates
   that clients should use the SRV record. Such specification MUST
   define the symbolic name to be used in the Service field of the SRV
   record as described below. It also MUST include security
   considerations. Service SRV records SHOULD NOT be used in the absence
   of such specification.

So to promote the use of SRV, one should also update the RFC's for
the application protocols, defining the symbolic name etc.

	jaap

---

From: Erik Nordmark <[email-masked]>
Date: Tue, 5 Feb 2002 17:03:40 +0100 (CET)

> the application protocols, defining the symbolic name etc.

This could be a separate, very short specification.
For instance, for http it would at a minimum say that _http._tcp.
is the prefix (I think the IANA registration for port 80 has two names "http"
and "web" and choosing one of them is important).

  Erik

---

From: Kevin Darcy <[email-masked]>
Date: Tue, 05 Feb 2002 18:02:33 -0500

Mark Andrews had an ID out there for this, but it appears to have expired.
Perhaps it could be resurrected?

- Kevin

---

From: Erik Nordmark <[email-masked]>
Date: Wed, 6 Feb 2002 10:37:51 +0100 (CET)

> In most cases, yes.
> Except that a _lot_ of things run over HTTP. For discovery of
> a World Wide Web service, _www._tcp seems more appropriate.

You've beautifully make the case why there needs to be a short specification
stating which name should be used for the srv record.
Thank you,

  Erik

---

From: Lyndon Nerenberg <[email-masked]>
Date: Tue, 05 Feb 2002 11:12:50 -0700

In most cases, yes.

--lyndon

---

From: [email-masked]
Date: Wed, 06 Feb 2002 23:50:14 +1100

I intend to rev. draft-andrews-http-srv-00.txt in the
	next day or so.

--
Mark Andrews, Internet Software Consortium
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: [email-masked]
Date: Sat, 09 Feb 2002 12:48:14 +1100

> 	I intend to rev. draft-andrews-http-srv-00.txt in the

	draft-andrews-http-srv-01.txt is available

---

From: Peter Koch <[email-masked]>
Date: Sat, 09 Feb 2002 17:12:06 +0100

Hi Mark,

> 	draft-andrews-http-srv-01.txt is available

nice draft. Wonder what the impact on larger name servers would look like,
especially during transition.

In section 2 you give this example (considered dnsop relevant):

      Non-default port specified:

         URI:      http://example.com:8080/
         SRV RR:   _http._tcp.example.com. SRV   10 1 80 host2.example.com.
         CNAME RR: example.com.            CNAME host1.example.com.
         A RRs:    host1.example.com.      A     10.0.0.1
                   host2.example.com.      AAAA  1080::8:800:200C:417A

      Connect to: 10.0.0.1 port 8080

While formally "example.com" need not be the name of a zone, in real life it
is and that's the expectation of the average DNS user, even emphasized by
the phrase "you are example.com" introducing the example in section 3.
So, this CNAME RR will be in clear conflict with SOA/NS RRs, a situation
you correctly declare "illegal" in an earlier paragraph. Unfortunately
cases like this happen "out there" every day and render the zone unusable.
So I'd rather see a warning here - or the CNAME RR altered, since it's not
necessary in this constellation. Instead it's worth another example showing
explicitly why SRV based solutions work where CNAME won't.

While at it: I'd probably mention that the SRV processing will have no
influence on what's sent in the http "Host:" header. 

Finally, what is the length of a "session"? If it is predetermined by the TTL
(actually which? the SRV's or the A/AAAA RRs'?), would this imply restrictions
on how to set the TTL values?

-Peter

---

From: "D. J. Bernstein" <[email-masked]>
Date: 10 Feb 2002 07:59:54 -0000

[email-masked] writes:
> who want fault tolerance for our ecommerce web sites.

Why not simply set up a bunch of A records, like everybody else?

---D. J. Bernstein, Associate Professor, Department of Mathematics,
Statistics, and Computer Science, University of Illinois at Chicago

---

From: [email-masked]
Date: Sun, 10 Feb 2002 08:12:57 -0800

> Why not simply set up a bunch of A records, like everybody else?

That doesn't solve the fault tolerance problem. Web browsers 
are
not smart enough to move on to the next address should the
web server at the first/selected address not be reachable.

This forces me do devise an inadequate and extraordinary
technique for making my DNS smart - each site checking the
other's health and adjusting zone files accordingly. Then,
for those running BIND, having the DNS server unavailable
temporarily as the zones are reloaded. The short TTLs
that are required cause more bandwidth to be consumed.
SRV support in the browser would be much better and
easier.

Ed

---

From: "Neil Carpenter" <[email-masked]>
Date: Sun, 10 Feb 2002 14:33:55 -0500

Which then suggests that you use a load-balancing solution at the
server-side (load-balancing router or clustering software on the web farm).
Uptime always has a cost associated with it...the higher the uptime you
require, the higher the cost you must be willing to pay.

Widespread implementation of SRV records would not help you in this
situation.  If a server goes down, the server is down -- whether you resolve
it via A records or SRV records is irrelevant.

Neil

(All opinions expressed are my own, and not those of my employer)

---

From: "D. J. Bernstein" <[email-masked]>
Date: 10 Feb 2002 17:01:48 -0000

[email-masked] writes:
> Web browsers are

Really? Which browsers? Have you pointed out RFC 1123, section 2.3? This
is not a SRV-specific issue.

In my experience, web browsers _do_ connect to multiple addresses, but
users give up in annoyance before the second address is tried.

This is why tcpclient (http://cr.yp.to/ucspi-tcp/tcpclient.html) uses a
fast connection strategy: try all the addresses with 2-second timeouts,
then try again with 58-second timeouts. Try asking browser authors to
adopt the same feature. The benefit to users is obvious.

  [ load balancing on the server side ]
> The short TTLs that are required cause more bandwidth to be consumed.

``Premature optimization is the root of all evil.'' How many bytes of
DNS traffic do you see every day? How many bytes of HTTP traffic do you
see every day?

---

From: Mats Dufberg <[email-masked]>
Date: Mon, 11 Feb 2002 06:49:17 +0100 (CET)

> 	draft-andrews-http-srv-01.txt is available

When I try

ftp://ftp.ietf.org/internet-drafts/draft-andrews-http-srv-01.txt

it says there is such no file (other new drafts are available). Can anyone
see what is wrong?

Mats

----------------------------------------------------------------------
Mats Dufberg <[email-masked]>
----------------------------------------------------------------------

---

From: Mats Dufberg <[email-masked]>
Date: Wed, 13 Feb 2002 00:28:31 +0100 (CET)

> 	I intend to rev. draft-andrews-http-srv-00.txt in the

I think it would be a good idea to include https (http over SSL) in the
draft with the name "https". The gain for https is even greater than for
normal http. With SRV support for https it would be possible to run
several https based virtual domain on one IP address (and letting the SRV
record point at a "private" port for each domain).

Comments?

Mats