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

[Eliot Lear <[e-mail]>]

Hi Josh,

Please see draft-lear-httpbis-svcinfo-rr-01.txt for a discussion as to
why SRV may not be appropriate.  The most important discussion to have,
however, is design goals, and that discussion has been somewhat delayed
by getting compression, upgrade, and a few other things done right.

Eliot

On 8/9/13 8:40 PM, Josh Goodall wrote:
> 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/
>
>
>
>