DNS behaviour should be specified (the principled & forward-thinking case for SRV)

[Josh Goodall <[e-mail]>]

It is quite, no, very surprising that a protocol of the complexity,
importance and universality of HTTP does not fully specify how to
locate the service endpoint.  There are two major issues caused by
the current absence of DNS resolution behaviour specification:

#1 IPv4 and IPv6 require separate lookups, resulting in a DNS race
   for some browsers.[1]
#2 Apex records must be configured specially (read: hackishly).

The underlying assumption is that all address records are valid
for HTTP.  This is, of course, quite wrong.


Discussion

Issue #1 is very well discussed in [1]. Suffice to say that the
recommendation is not to have a DNS race at all but a TCP SYN race.
Supporting IPv6 adoption should be a part of this protocol revision,
because IPv6 is no longer coming; it is here, and failure to consider
it will look like a mistake later on.

Issue #2. It is unfortunate that almost every destination of
significance configures an address record for the apex.
So every other protocol that might respond to an A/AAAA record ends
up finding it too.  Ever seen inbound SMTP for your web server?
This is part of the reason.  Apex records are an enemy of availability,
since they must be changed manually where aliases do not.

But we can't use CNAMEs at the apex. How can we resolve this?


The SRV proposal

My suggestion is that standardising on SRV (RFC 2782)[2] records is
an easy and appropriate remediation, due to widespread support,
fitness for purpose and standards readiness.

It solves both problems above:

#1: both A and AAAA are included in Additional Information in SRV
    replies, at least by BIND9, so a SRV query is one round-trip.
#2: SRV works at the apex.

and adds additional benefits in behaviour and deployment flexibility.

I can't stress how valuable it is to have widespread support in DNS
servers today; that is why other DNS RR proposals don't have legs.
BIND9, NSD and Windows DNS Server all support authoritative service
of SRV. It can be deployed today.

Essentially, SRV is what CNAME should've been.  BCP 17 (RFC 2219)[6]
foresees this; section 5 of RFC 6335 (aka BCP 165 - the governing
document for the IANA service registry)[7] even has explicit
clarification for how "http" is to be used in SRV records, firmly
deprecating "www".

Moreover, as the browser becomes ever more the general client,
support for non-HTTP services can deploy in future without conflicting
with the traditional role. For example, SRV would've been a superb
choice for the Mozilla project's "Persona" protocol.


On the history

This has been proposed many times in various forms; see for example
[3][4][9][10].  The history shows that if we don't take action in the
protocol standard itself, improvement won't happen.

A fully worked example of including SRV lookup in the TCP binding
of a significant protocol standard can be found in section 3.2 of
RFC 6120 (XMPP) [5]


On the counterarguments

The common reason quoted not to use SRV is that it means an extra
DNS round-trip, since everything is using CNAME/A/AAAA records
today.  Indeed if we don't include it in the standard up front,
then it will always require an extra round-trip.  But settling on
SRV right now means that browser behaviour will be SRV-first. Not
only does this get everyone on board sooner or later, it'll mean
faster lookups for IPv6 in future.

There is a conflict with URI explicit ports; this was resolved by
Andrews in [4] by having an explicit URI port take priority;
conversely, in XMPP is resolved by prohibition of explicit port
numbers in URIs. (s5.2 of RFC 5122 [8])


References

[1] https://ripe64.ripe.net/presentations/78-2012-04-16-ripe64.pdf
[2] http://tools.ietf.org/html/rfc2782
[3] http://tools.ietf.org/html/draft-jennings-http-srv-05
[4] http://tools.ietf.org/html/draft-andrews-http-srv-01
[5] http://tools.ietf.org/html/rfc6120
[6] http://www.rfc-editor.org/bcp/bcp17.txt
[7] http://tools.ietf.org/html/bcp165
[8] http://tools.ietf.org/html/rfc5122
[9] http://homepage.ntlworld.com/jonathan.deboynepollard/FGA/dns-srv-record-use-by-clients.html
[10] http://dns.vanrein.org/srv/