5 ms·

"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 mapp

by rlpb 13y ago

"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.

teddyh 13y ago
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.
- nraynaud 13y ago
  what about SPDY (or TLS if it's the relevant layer)?
  - sp332 13y ago
    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.
    - ithkuil 13y ago
      the different port clearly visible since spdy URLs are https (which defaults to 443)
- jessaustin 13y ago
  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 http://www.iana.org/protocols
  - teddyh 13y ago
    (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.
  - teddyh 13y ago
    That’s the wrong IANA link; you want this one: https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml https://www.iana.org/assignments/service-names-port-numbers/... There are not three, but thousands of protocol names registered.
    - asdfaoeu 13y ago
      You'll note http is specified there.
      - teddyh 13y ago
        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.
- Zr40 13y ago
  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.
  - teddyh 13y ago
    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.
    - MichaelGG 13y ago
      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.
      - teddyh 13y ago
        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.
jlgaddis 13y ago
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/ http://pkg.freebsd.org/

by rlpb 13y ago

teddyh 13y ago

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.

nraynaud 13y ago
what about SPDY (or TLS if it's the relevant layer)?
- sp332 13y ago
  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.
  - ithkuil 13y ago
    the different port clearly visible since spdy URLs are https (which defaults to 443)
jessaustin 13y ago
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 http://www.iana.org/protocols
- teddyh 13y ago
  (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.
- teddyh 13y ago
  That’s the wrong IANA link; you want this one: https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml https://www.iana.org/assignments/service-names-port-numbers/... There are not three, but thousands of protocol names registered.
  - asdfaoeu 13y ago
    You'll note http is specified there.
    - teddyh 13y ago
      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.
Zr40 13y ago
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.
- teddyh 13y ago
  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.
  - MichaelGG 13y ago
    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.
    - teddyh 13y ago
      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.

jlgaddis 13y ago

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/ http://pkg.freebsd.org/