Subject: Using SRV records with a http Web Service

From: Phillip Hallam-Baker <[email-masked]>
Date: Tue, 15 Dec 2015 12:29:55 -0500

I am trying to spec out a Web Service. It is obviously desirable to use SRV
based discovery over A-record since that allows for priority, fallback, etc.

However rfc7230 is silent on the matter.

The point of complication that enters is what the name for the Host:
header. Should this be remapped to the address given in the SRV or not? My
view is that it should not.

so if the service being resolved is _mmm._tcp.example.com and we have srv
records:

_mmm._tcp.example.com SRV 0 5 80 host1.example.com
_mmm._tcp.example.com SRV 0 5 80 host2.example.com

The Host: header should be:

Get /.well-known/mmm/
Host: example.com

This seems like the obvious approach. However there are two other
possibilities:

Host: host1.example.com
Host: _mmm._tcp.example.com

The first is obviously unhelpful and wrong as the SRV alias identifies a
machine, not the site.

The second could actually be useful though. It essentially eliminates the
need for .well-known URIs.

---

From: Patrick McManus <[email-masked]>
Date: Tue, 15 Dec 2015 14:31:05 -0500

if you think of a srv as a more fine grained cname, the answer is obvious -
don't change the host header as it needs to reflect the origin.

On Tue, Dec 15, 2015 at 12:29 PM, Phillip Hallam-Baker <
[email-masked]> wrote:

> I am trying to spec out a Web Service. It is obviously desirable to use
> SRV based discovery over A-record since that allows for priority, fallback,
> etc.
>

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 17 Dec 2015 11:40:42 -0500

> don't change the host header as it needs to reflect the origin.

I had forgotten that CNAME is considered explicitly. that certainly
excludes changing the host name to the SRV host address which was my
main concern.

Resolve ("example.com", "mmm")

Get /.well-known/mmm/
Host: example.com

Still not happy throwing away information though.

---

From: Benjamin Carlyle <[email-masked]>
Date: Fri, 18 Dec 2015 01:32:13 +0000

SRV records have come up on the list previously for HTTP/2 and it appears
the current official position is that SRV is not supported for HTTP:
https://lists.w3.org/Archives/Public/ietf-http-wg/2015AprJun/0674.html

As for the use of the Host header it is really the logical name of the
origin. There are two distinct concepts in play here. One is the URL
(including the authority which includes the Host) which logically describes
the resource we want to interact with. The other is this concept of which
host and port we connect to in order to reach that resource.

If a proxy is in play we connect to the proxy. If an origin server runs a
single site or service or that origin server runs multiple sites or
services we connect to that origin server. In all cases we want to preserve
the URL of the resource we want to interact with. The Host header either
carries the authority part of the URL or the request line contains the URL
and Host is included but can be left blank.

In your case it would be difficult to logically express the mmm service in
a URL. http://example.com:mmm/ is invalid as the port must be numeric. In
your case the logically consistent thing to do would be to make the SRV
service "http" and include the "real" service name (mmm in your example) as
part of the SRV host. I.e.
_http._tcp.mmm.example.com SRV 0 5 80 host1.example.com
Your URL authority and your Host header would be mmm.example.com,
preserving the service information in the request. However, as stated above
using SRV will likely lead to interoperability problems.

Benjamin.

---

From: Glen Knowles <[email-masked]>
Date: Fri, 18 Dec 2015 17:18:43 -0800

In the wake of ALPN and ALT-SVC it might be worth revisiting whether SRV
records would be sufficient.

As for the latency concern, my own experience has been that SRV record
queries almost always include enough additional results in the form of A
and AAAA records to immediately start connecting. But my experience may be
unusual, especially since it's mostly within or between datacenters we
control.

A better solution for communicating non-standard ports than what we've got
would be welcome.

---

From: Erik Nygren <[email-masked]>
Date: Mon, 21 Dec 2015 14:25:40 -0500

Following a discussion a year or so ago I put together a (now-expired) I-D
that attempts to address many of these use-cases while also providing a
mechanism to effectively communicate ALT-SVC via the DNS:

           https://tools.ietf.org/html/draft-nygren-service-bindings-00

I've collected a bunch of feedback since then and am overdue
for publishing an updated version.

       Erik