Hacker News Reader

Comment by rlpb | Hacker News Reader

"The Inflexibility of DNS"

This problem would not exist if clients (eg. web browsers) supported SRV record lookups. The SRV fixes a missing abstraction by mapping names that users see (eg. foo.com) to actual server names (eg. webserv42.foo.com). Without SRV record lookups, web browsers must look up the bare domain, and expect to get an address, for this to work. CNAMEs were not designed to be used for this kind of situation; it's a square peg in a round hole.

This isn't due to the inflexibility of DNS; it's due to the inflexibility of clients that ignore newer advancements in the protocol.

Of course, this does mean that web hosts are stuck.

View on HN

This idea that web browsers are silly and should just start using SRV records gets a lot of traction, and I would like it if it were true. Unfortunately, the SRV specification prohibits anyone from using SRV records for protocols where the protocol’s definition does not specify the use of SRV records.

I.e. since HTTP does not specify the use of SRV records, web browsers are not allowed to use SRV lookups to locate HTTP servers.

The ones to blame are, instead, HTTP standards writers, which have not written a new HTTP standard taking advantage of the wonderful thing which SRV records are.

what about SPDY (or TLS if it's the relevant layer)?

That would cause a fragmentation where SPDY traffic might get directed to a completely different server than HTTP traffic. I mean, I know they're served from different ports already but this seem extra brittle.

the different port clearly visible since spdy URLs are https (which defaults to 443)

To be fair, the SRV spec, rfc2782, could have been written (or could be updated) to allow other, more flexible methods. Actually, that spec seems to contradict itself, saying first "...for applications where the relevant protocol specification indicates that clients should use the SRV record..." but later on the same page "The symbolic name of the desired service, as defined in Assigned Numbers [STD 2] or locally." At IANA [0] it appears that only three protocols actually use the assigned numbers infrastructure to handle this, but more could, and in the absence of new RFCs clients could adopt a convention for determining "symbolic service names" for non-SRV-aware protocols.

[0] http://www.iana.org/protocols

That’s the wrong IANA link; you want this one:

https://www.iana.org/assignments/service-names-port-numbers/...

There are not three, but thousands of protocol names registered.

You'll note http is specified there.

The list I linked to is a list of all protocols known by IANA. Whether the use of SRV records is allowed by the individual standards is not recorded by IANA; one would have to search each individual standard to find out.

HTTP, notably, does not specify the use of SRV records.

That page doesn't appear to have a thing to do with SRV.

Those are the registered service names you can make SRV records with.

If that's true, it only confirms my original point. Yet it still seems that SRV integration is a challenge for many clients.

(Oh, I see what you meant now.) The things on that page are protocols which require further allocation of numbers and/or names by IANA, and is not directly related to what protocols specifies the use of SRV records. The “three protocols” you mention are protocols which require further allocation of numbers and/or names in their use of SRV records in some way. This does not mean that only three protocols specifies the use of SRV records.

RFC2782 does not prohibit the use of SRV records with those protocols.

    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.

RFC2119 defines 'SHOULD NOT' as follows:

    This phrase, or the phrase "NOT RECOMMENDED" mean that
    there may exist valid reasons in particular circumstances when the
    particular behavior is acceptable or even useful, but the full
    implications should be understood and the case carefully weighed
    before implementing any behavior described with this label.

Maybe “prohibit” was the wrong word. On the other hand, I would argue that a “SHOULD NOT” is stronger than you think: The HTTP standard (RFC 2616) says that:

“[…] the GET and HEAD methods SHOULD NOT have the significance of taking an action other than retrieval. These methods ought to be considered "safe". This allows user agents to represent other methods, such as POST, PUT and DELETE, in a special way, so that the user is made aware of the fact that a possibly unsafe action is being requested.

I would argue that very few people would claim that it’s OK for HTTP servers to have HEAD and GET requests be non-idempotent just because they feel like it. “SHOULD NOT” prohibitions should not be ignored just because you really want to do it.

Do you really think that's the reason? Specs should be ignored when they state things beyond their scope. The a restriction on DNS depending on if a newer HTTP spec definitely something that can and should be ignored if it helps clients.

I really think that a “SHOULD NOT” in an RFC is a sufficient reason to not do a thing, yes. I further think that specifying the usage of SRV record is wholly in scope of the RFC specifying the SRV record.

pkgng, FreeBSD's new package management tool, uses SRV records (by default) with HTTP:

  $ dig +short srv _http._tcp.pkg.freebsd.org
  20 10 80 pkg0.isc.freebsd.org.
  50 10 80 pkg0.bme.freebsd.org.
  10 10 80 pkg0.nyi.freebsd.org.
  90 10 80 pkg0.ydx.freebsd.org.

Technically, though, it's not being used by/with a web browser.

It generated enough confusion (as evidenced by the frequent "how come I can't {connect to|resolve} pkg.freebsd.org?" questions) that there's now an A RR and a page explaining it: http://pkg.freebsd.org/

Reply on news.ycombinator.com