Subject: Re: SRV records - when?

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

On Feb 13, 2002, 20:52 (-0800) Ted Hardie <[email-masked]> wrote:

> This is the interesting thing: are you talking about a protocol/transport
> or a service?  The service "web" might be handled by http or https and
> that indicated in the look up for the service (and given the possibility
> of using UPGRADE, maybe even that it can be http, https, or TLS within
> HTTP).  The  service "http", on the other hand, had better not be
> handled by https.

I'm talking about http and https as different services, since you must
know in advance which one you are connecting to. With TLS within http that
should not be needed, but that does not seem to take off. There have been
objections against the clear text initialization of http/TLS model, but I
do not know if they are valid.

Are you updated on https vs. http/TLS?

If http with TLS will replace https, then there is no need for a special
https service. But if that is not the case, or if it is unclear, I think
that SRV for https should be defined as a different service in the same
RFC as SRV for http.

Mats

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

---

From: Daniel Senie <[email-masked]>
Date: Thu, 14 Feb 2002 11:29:48 -0500

At 12:49 AM 2/14/02, Mats Dufberg wrote:
>know in advance which one you are connecting to.

For sites where some parts are encrypted, and other parts are not, there's 
a real need to keep the client/server mappings together. Consider, for 
example, a site which does not use encryption for the shopping cart, but 
does for the checkout. If the SRV records are used to select among servers 
in different physical locations, it would be quite inconvenient for an 
https SRV record to point at a different locale than the http record.

-----------------------------------------------------------------
Daniel Senie                                        [email-masked]
Amaranth Networks Inc.                    http://www.amaranth.com

---

From: Mats Dufberg <[email-masked]>
Date: Thu, 14 Feb 2002 20:21:12 +0100 (CET)

> https SRV record to point at a different locale than the http record.

Do you mean that we should have the same SRV record for http and https?
The SRV record contains information on port number, but we need to have
different ports for http and https. My conclusion is that we have to have
different SRV records for http and https. Or we could say that we think
that https should not be, and only support http.

Mats

---

From: Daniel Senie <[email-masked]>
Date: Thu, 14 Feb 2002 14:49:02 -0500

>Do you mean that we should have the same SRV record for http and https?

I'm saying that may be more useful than having separate ones, yes. This is 
due to the way the service employs the ports.

>that https should not be, and only support http.

I guess the basic question is whether having SRV records tied to a 1:1 
mapping of port numbers is desirable, or whether they should be mapped 
instead to "services." There are cases, such as the present case of HTTP 
and HTTPS where the "service" described as the "World Wide Web" uses more 
than one port. To properly point to a particular host to provide service, 
it doesn't seem useful to do this based on port number.

So, the question is should there be a "web" SRV record that can be queried 
and which clients use to answer the larger service question, instead of 
finding out about the HTTP port or the HTTPS port.

Dan

---

From: Mats Dufberg <[email-masked]>
Date: Thu, 14 Feb 2002 21:19:47 +0100 (CET)

On Feb 14, 2002, 14:49 (-0500) Daniel Senie <[email-masked]> wrote:

> instead to "services."

You are about to redefine SRV. An SRV record connects a service at a
domain to port and a server. Since http and https cannot share port, they
cannot share SRV record.

> There are cases, such as the present case of HTTP

I'm sorry, I don't understand your solution. Could you describe how to use
one SRV record for the web service to cover both plain http and https?

Mats

---

From: Daniel Senie <[email-masked]>
Date: Thu, 14 Feb 2002 17:02:27 -0500

>domain to port and a server. Since http and https cannot share port, they

Interesting that RFC 2782 has a note explicitly saying NOT to use port 
numbers. The language is less clear on whether the names must be tied to 
specific ports. I agree I may be arguing for redefining SRV. That may be 
out of scope for an Ops area group. However I have to wonder if it's the 
right thing to do.

>one SRV record for the web service to cover both plain http and https?

The goal is to get an a mapping to a machine that can handle a service. SRV 
as defined in RFC2782 returns both address and port number, where for what 
I was thinking about, address alone would have been better. It's too bad 
the address and port number were tied together. If we had it to do again, 
I'd argue for one record pointing at the proper host, and separate query to 
ask what port to use on that host for a particular protocol if needed. What 
I was thinking about was doing a lookup for a "service," where "service" is 
defined in terms of application functionality, not in terms of a 1:1 
mapping of "service" to port number.

If it were possible to define a record be defined that answers the question 
for "web service," that could be useful. If one asks the question for HTTP, 
then asks the question for HTTPS, the answers might be different. Website 
operators who really need the two to map together could use existing 
load-balancers and such, and keep the state and so forth, but that 
technology is already present, and is implemented with short DNS timers, 
and so forth.

The solution I was thinking of was to ask for "web," for example, instead 
of "http" or "https" and allow that mapping. This would require 
registration of pseudo-services in the IANA, effectively service names that 
have NO associated port number.

 From RFC 2782: "Service: The symbolic name of the desired service, as 
defined in Assigned Numbers [STD 2] or locally." Further, while this RFC 
references IANA's database, it doesn't specify specifically that the 
service names are from the port number table, though that is what it's been 
taken to mean. I was suggesting is a new table at IANA could be used to 
specify the specific and appropriate values to be used for the Service 
field for SRV requests, and that this would permit what I was suggesting in 
the case of web/http/https.

Unfortunately, the response of the SRV record specifies a single port 
number, which effectively rules out what I was thinking about. If only an 
address were returned by SRV, and another question were asked to get the 
port(s), it would be more workable.

Given the present definition of SRV, the mechanism will not be able to 
support services which employ multiple ports, or applications (e.g. web 
browsers) will have to make assumptions (i.e. look up SRV for http, and 
assume port 443 for the same host for https) or else sites will not 
function correctly.

I guess the question I'm left with is whether SRV records, as defined, are 
useful and sufficient. For some types of services, they are useful. For the 
broader spectrum of applications, SRV records, as defined, appear not to be 
sufficient.

Dan

---

From: Daniel Senie <[email-masked]>
Date: Thu, 14 Feb 2002 18:16:04 -0500

At 05:20 PM 2/14/02, Ted Hardie wrote:
>They cannot share an SRV record, but both might be valid responses to
>similar SRV requests applied to different domains.  The response to an
>SRV request returns only one port, so you can't give a hostname and
>multiple ports.  But you might have a request for "web" return the
>http port for queries in the domain nasa.gov and the https port for
>schwab.com.  Or to, put a different spin on it, a request for service
>"secureweb" might return a host and the https port for one domain but
>a host and the http port for another (implying an upgrade to TLS, and
>yes, I see the risk in using something implied).
>
>I'm fine with a 1:1 mapping of "service" to port number, but I don't
>think we should assume that the service will always map to the same
>port or transport (imagine using BEEP instead of TCP).  The only
>really tricky part of the https vs. http case (against, say having
>port 80 and 8080) is that the connection sematics are different
>on one.  That may well argue that they be treated as different
>services (e.g. web and secureweb).

I've reread your message a few times, and don't see that you've addressed 
the issue I was concerned about.

If a web site uses multiple protocols (HTTP and HTTPS), and needs any given 
web browser/client to map to exactly ONE host, then SRV is a useless 
mechanism to achieve this. Note that MANY web sites that include shopping 
functionality rely on this today. If there's no solution to this with SRV, 
then I see little incentive for anyone in web services to bother adopting 
SRV into web clients. The web sites would still have to run stateful 
balancers to ensure a given client ALWAYS maps to the same server, or else 
the user's shopping cart could easily be on a server in chicago and when 
they try to check out, the secure server they get routed to in Miami has no 
idea of the cart contents.

Since SRV can't provide this, I guess the next step is to either:

1. Not bother solving the problem.

2. Define something else in DNS to solve this problem.

3. Redefine SRV to be sufficiently flexible for today's application space.

I expect #3 is out of the question, so it's going to be 1 or 2.
-----------------------------------------------------------------
Daniel Senie                                        [email-masked]
Amaranth Networks Inc.                    http://www.amaranth.com

---

From: Mats Dufberg <[email-masked]>
Date: Fri, 15 Feb 2002 00:29:21 +0100 (CET)

On Feb 14, 2002, 17:02 (-0500) Daniel Senie <[email-masked]> wrote:

> ask what port to use on that host for a particular protocol if needed.

I don't see the point of having to ask twice. I don't see the problem of
having the port in the data. On the contrary, by having port number, it is
more flexible.

> assume port 443 for the same host for https) or else sites will not

You can handle it by having more than one SRV record.

Mats

---

From: Daniel Senie <[email-masked]>
Date: Thu, 14 Feb 2002 18:33:48 -0500

>having the port in the data. On the contrary, by having port number, it is

The point is to ensure the client talks over the multiple ports to the same 
server, in the event a given application requires that. Web-based shopping 
sites which use HTTP for speed and HTTPS for checkout security are a prime 
example.

>You can handle it by having more than one SRV record.

So you have SRV records pointing at 3 different web farms for http, and 
records for https pointing to the same web farms. How do you ensure that a 
given resolver gets the SAME server IP address (though different port) for 
the http and https requests?

---

From: Mats Dufberg <[email-masked]>
Date: Fri, 15 Feb 2002 00:35:04 +0100 (CET)

> idea of the cart contents.

I don't see how SRV will cause the problem your are describing. If you
have several servers under the same name for the same service, then you
run the risk that the "visitors" end up at different servers different
times.

> I expect #3 is out of the question, so it's going to be 1 or 2.

What about NAPTR records (RFC 2915)? They are more flexible.

Personally I think that SRV will be sufficient in most cases. And they add
flexibility missing today. SRV could be seen as a general for om MX. We
need those.

Mats

---

From: Mats Dufberg <[email-masked]>
Date: Fri, 15 Feb 2002 00:44:46 +0100 (CET)

> sites which use HTTP for speed and HTTPS for checkout security are a prime

In that case you can probably direct the client from the HTTP based
connection to a specific server under HTTPS. But there are probably
situations that don't work.

> the http and https requests?

What I had in mind was virtual domains under https on one server with one
address. A specific service and SRV could solve that problem because we
want to be able to specify port.

_https._tcp.namn1.se.  SRV  0 1  143  www.namn.se.
_https._tcp.namn2.se.  SRV  0 1  144  www.namn.se.
_https._tcp.namn3.se.  SRV  0 1  145  www.namn.se.

Mats

---

From: jerry scharf <[email-masked]>
Date: Thu, 14 Feb 2002 16:55:00 -0800

Daniel,

If you want to guarantee that the secure and non-secure servers are the 
same, you don't want SRV as I see it. Since the whole idea of SRVs is to 
present a controlled choice setup, you shouldn't use it for things that you 
don't want choice.

When you switch from the shopping cart to the checkout, and you've designed 
your system so that the information is local, send them to a A record https 
host that is the one with the shopping cart info. You don't want SRV here, 
because if the host with the shopping cart doesn't catch the https 
connection in a transient way, the user will get sent to the next host, get 
to a host with an empty shopping cart and be confused.

If you don't use SRV when you don't want choice, you won't have a problem 
with SRV records.

If someone designs a systems like this, and it's (IMO) not robust against 
host failures, they get what they designed. no way for any DNS trick to fix 
this. If you don't use same value round robin with this, then again the SRV 
linkage problem goes away.

I don't think this rationale is compelling to make any changes to SRV.

jerry

---

From: Daniel Senie <[email-masked]>
Date: Thu, 14 Feb 2002 20:11:35 -0500

At 07:55 PM 2/14/02, jerry scharf wrote:
>present a controlled choice setup, you shouldn't use it for things that 
>you don't want choice.

More or less right. The thought was SRV would work well for choosing the 
web server to talk to, though. When the client switches to secure mode, 
that's when going through this choice process again sounds like a really 
bad idea.

>When you switch from the shopping cart to the checkout, and you've 
>designed your system so that the information is local, send them to a A 
>record https host that is the one with the shopping cart info.

The concern was you might have several possible addresses for the https, 
maching the several possibles for the http. Best bet may well be to tell 
web browser vendors they can use SRV for http, but use the A record they 
get back from that request to find the https server.

Messes up someone else's desire to use SRV to spread out SSL for virtual 
servers, though (something I hadn't thought about).

>  You don't want SRV here, because if the host with the shopping cart 
> doesn't catch the https connection in a transient way, the user will get 
> sent to the next host, get to a host with an empty shopping cart and be 
> confused.
>
>host failures, they get what they designed. no way for any DNS trick to 
>fix this. If you don't use same value round robin with this, then again 
>the SRV linkage problem goes away.

Right. Ultimately we come back to people running DNS-based multisite load 
balancers with very short timeouts to handle outages.

>I don't think this rationale is compelling to make any changes to SRV.

I ultimately see little rationale for getting the web client vendors to 
adopt SRV, or for web server farm providers to use it, unfortunately.

---

From: jerry scharf <[email-masked]>
Date: Thu, 14 Feb 2002 17:58:23 -0800

Daniel,

SRV records suck just as badly as A records for round robin load balancing, 
intelligent routing and the like. It's just DNS.

SRV could be very useful if I have a fat pipe without a full transparent 
redundancy. Any time you fail the first connection, you will lose some 
percentage of your clients, but people can use the fat pipe when its there 
and use one or more slower pipes in the case of a failure. HTTP based file 
downloads could benefit from this as well.

Given the immediacy of web access, it is less useful for this then for 
batch functions such as mail. That doesn't make it useless, especially 
seeing how widely HTTP is now being used.

jerry

---

From: Alan Barrett <[email-masked]>
Date: Fri, 15 Feb 2002 09:32:25 +0200

> that's when going through this choice process again sounds like a really 

If the page designer wants to force the client to go to a particular
host, then the page designer can feed the client an URL that maps to a
specific host.  If the page designer wants the client to go to any of
a set of hosts, then the page designer can feed the client an URL that
maps (via SRV or multiple A records) to a set of hosts.

I don't see a problem.

--apb (Alan Barrett)

---

From: Ted Hardie <[email-masked]>
Date: Thu, 14 Feb 2002 14:20:05 -0800 (PST)

regards,
				Ted Hardie

---

From: Ted Hardie <[email-masked]>
Date: Thu, 14 Feb 2002 15:50:28 -0800 (PST)

> the issue I was concerned about.

I was pointing out that I am concerned about a different use case,
not saying that my use case solved your problem.  Sorry if that was
not clear.

> idea of the cart contents.

I understand that many web sites have both http and https but, as you
note, you might still see these as distinct services ("web" and
"secureweb" to use one set of terms).  An application may well make
use of both services (as you have it, one for browsing, one for
buying).  Moving data entered during "browsing/web" into
"buying/secureweb" can be done in a variety of different ways, and
thought it may be convenient for the same machine to be
involved, it certainly isn't the only available architecture.
For those who want to make sure that it is always the same machine,
a stateful balancer might be the best choice.  For those that use
a different architecutre, the SRV record solution might be fine.

			regards,
				Ted Hardie

---

From: [email-masked]
Date: Fri, 15 Feb 2002 11:55:11 +1100

> flexibility missing today. SRV could be seen as a general for om MX. We

	This is simple to solve.  Just extend the definition of a
	session to include both http and https then as long as the
	host name is the same in the URI you pick the same server
	(and same IP address) if it is in the set of SRV records
	for the other service.

	_http._tcp.example.com SRV 10 50 80 server1.isp.com
	_http._tcp.example.com SRV 10 50 80 server2.isp.com
	_http._tcp.example2.com SRV 10 50 80 server1.isp.com
	_http._tcp.example2.com SRV 10 50 80 server2.isp.com
	_https._tcp.example.com SRV 10 50 443 server1.isp.com
	_https._tcp.example.com SRV 10 50 443 server2.isp.com
	_https._tcp.example2.com SRV 10 50 444 server1.isp.com
	_https._tcp.example2.com SRV 10 50 444 server2.isp.com

	So if you start out talking to server1.isp.com HTTP you stay
	talking to server 1 when you switch to HTTPS.

	Note: The above is using name based differention for http and
	port based differentiation for HTTPS.

	You still get load balancing at the session level.

	I don't intend to add HTTPS to the current document as
	there is a lot more required for HTTPS than there is for
	HTTP.  I will add a section about following a session from
	HTTP to HTTPS which basically says what I said here.

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

---

From: Robert Elz <[email-masked]>
Date: Fri, 15 Feb 2002 18:08:49 +0700

Date:        Fri, 15 Feb 2002 11:55:11 +1100
    From:        [email-masked]
    Message-ID:  <[email-masked]>

  | 	I will add a section about following a session from
  | 	HTTP to HTTPS which basically says what I said here.

Don't bother, that's way too ugly and complicated.  Alan Barrett's
answer is the correct one for this particular non-problem.  You might
include that as a reference (so people don't keep asking the
same quesion).

kre

---

From: Michael Richardson <[email-masked]>
Date: Fri, 15 Feb 2002 13:58:43 -0500

My understanding is that there is a new proposal, HTTP/TLS which has the
TLS start after an initial HTTP transaction, rather the way SMTP/STARTTLS
works. In that context, HTTP/TLS and HTTP can share a record.

]       ON HUMILITY: to err is human. To moo, bovine.           |  firewalls  [
]   Michael Richardson, Sandelman Software Works, Ottawa, ON    |net architect[
] [email-masked] http://www.sandelman.ottawa.on.ca/ |device driver[
] panic("Just another NetBSD/notebook using, kernel hacking, security guy");  [

---

From: Michael Richardson <[email-masked]>
Date: Fri, 15 Feb 2002 14:55:35 -0500

>>>>> "Daniel" == Daniel Senie <[email-masked]> writes:
    Daniel> mechanism to achieve this. Note that MANY web sites that include shopping 
    Daniel> functionality rely on this today. If there's no solution to this with SRV, 
    Daniel> then I see little incentive for anyone in web services to bother adopting 
    Daniel> SRV into web clients. The web sites would still have to run stateful 
    Daniel> balancers to ensure a given client ALWAYS maps to the same server, or else 
    Daniel> the user's shopping cart could easily be on a server in chicago and when 
    Daniel> they try to check out, the secure server they get routed to in Miami has no 
    Daniel> idea of the cart contents.

  Well, this is the result of bogus web site design.

  The web server in Chicago can simply give *its own address* in when they
are referred to the HTTPS web server.  The whole stateful load balancer
nightmare is because nobody with a clue has taken web designers, hosting
people and customers and put them in the same room for half an hour. Not
surprising, the hosting and web designers stand to lose here to everyone
else's benefit.

---

From: Daniel Senie <[email-masked]>
Date: Fri, 15 Feb 2002 15:40:00 -0500

>works. In that context, HTTP/TLS and HTTP can share a record.

Yep, and we've had an MD5 hashed authentication to supplement the 
clear-text basic authentication in the HTTP protocol for how long? How many 
browsers have implemented it?

Then again, the SRV support may never make it into the browsers either.