6 ms·

Just from the article and some of the comments here, it's not quite clear to me what the motivation for making HTTP use SRV records is. To me, naively, it seems

Just from the article and some of the comments here, it's not quite clear to me what the motivation for making HTTP use SRV records is. To me, naively, it seems like relying on A/AAAA records a) "works", and b) is central to a lot of people's intuition of how networking services function. Following some of the links in the article, I've seen people make arguments on how straightforward it would be to implement and how it clearly works well for some non-HTTP systems. I'm guessing there's some implicit shared understanding of the problem space that I, as an uninitiated, casual DNS user, can't really wrap my head around. Can y'all point me in the right direction to read something about, like, what problems SRV records solve for HTTP, and specifically how that solution compares to how people have traditionally solved those problems with HTTP? There seems to be some tension between best practices as established by IETF RFCs and best practices coming from decades of deploying public-facing HTTP infrastructure/browsers, does that sound about right?

sneak 8y ago
A big one: client-side load balancing allows for the removal of the last SPOF for most websites: the IP(s) of the load balancer(s) to which the A record(s) point to. A second one: deploying TLS websites used to require one ip per hostname, and presently requires weird hacks like SNI (which leak the hostname to which one is connecting to observers). Being able to deploy any website on any port allows for a lot more flexibility in deployments, especially given the current trends such as “serverless”, k8s, et c.
- ben0x539 8y ago
  Hm, I don't quite understand, if I have multiple A records, is it still a single point of failure? Could you clarify the difference between having a bunch of SRV records and a bunch of A records here?
  - JdeBP 8y ago
    If your client recieves multiple A/AAAA resource records, your client has no way to know what order they should best be tried in, from the server's point of view, and there is no way for the content DNS server to transmit that information. * http://jdebp.eu./FGA/dns-round-robin-is-useless.html http://jdebp.eu./FGA/dns-round-robin-is-useless.html Note that making priority and weighting available is given in the rationale section of the original RFC from 1996. What you're talking about actually isn't specific to HTTP. * https://tools.ietf.org/html/rfc2052 https://tools.ietf.org/html/rfc2052
  - sneak 8y ago
    Most browsers will not retry to a second one if the first one it tries fails. Multiple A records do not fail over.
LinuxBender 8y ago
For web browsers, multiple A/AAAA are sufficient. Web browsers worked around the issues folks are mentioning some time ago using retries to each IP. The use of SRV could help in newer API driven implementations so that scripts and other tooling could enumerate which IP's are preferred. For now, developers will just have to make use of multiple records like the browsers do. That said, it won't likely happen because the HTTP spec does not allow new DNS implementations. The RFC would have to be deprecated with a new one that permits SRV. HTTP/2 would have been a grand opportunity to do just that. There have been many discussions [1] and debates on the issue, but I do not foresee it happening. [1] - https://www.ietf.org/mail-archive/web/httpbisa/current/msg25379.html https://www.ietf.org/mail-archive/web/httpbisa/current/msg25...
- deleted 8y ago
  [deleted]
- inopinatus 8y ago
  HTTP protocol & normative references don't actually mention DNS at all. The hand-wringing evidenced by some about the difficulties of introducing a new behaviour seems pretty feeble when you consider that Google has successfully intruded both a new transport protocol (QUIC) and a new application layer protocol (HTTP/2 i.e. SPDY) in a few short years. Rolling browser updates are now the norm and enable these major changes.
  - LinuxBender 8y ago
    Agreed, but the protocol does not allow for deviation without creating a new protocol; which to your point, Google did. Google could have introduced SRV records as optional components in the spec. So the lack of mention of DNS standards in the protocol is sufficient to block the implementation of a new DNS requirement. Browsers are not the only thing that speak http. There are a myriad of libraries used by API's and all manor of automation that must also be updated to support a new protocol. A good example of this is SNI. All major browsers support SNI, but there are plenty of libraries that have yet to catch up to that very well aged protocol.
inopinatus 8y ago
An URL of "https://github.com" https://github.com" means looking up A and AAAA records for "github.com". The HTTP vendors are arrogant enough to demand that your host address for the whole domain is that of the web service, and not any other service. Because it's at the apex of the domain, that record also cannot be a CNAME alias, because the apex includes DNS metadata that is not allowed to be aliased. So instead we have numerous ugly hacks from DNS providers that vary that address record by tracking an alias target, with varying degrees of reliability. In other words, your DNS is now entirely subordinate to the demands of the web protocols and using ugly hacks to work around limitations of address records. You can stick a "www" on the front as a cheap, poorly specified, and untyped service selector, but because of the convention of just entering a domain name you'll still have to do the apex record. Basically, the current convention for HTTP is to overload the address record to be its personal service record and screw everyone else and the consequences. SRV also provides mechanisms for service fallback and weighted loadbalancing that address records do not. It can also conserve IP space by directing clients to alternative ports without ugly port specifications in the URI. There's a lot to like about it, and a lot to dislike about the current practices.
- ben0x539 8y ago
  For someone who goes by inopinatus, you sure sound opinionated ;) Thanks for the clarifications!
  - inopinatus 8y ago
    It's actually Latin. But yes.

sneak 8y ago

A big one: client-side load balancing allows for the removal of the last SPOF for most websites: the IP(s) of the load balancer(s) to which the A record(s) point to. A second one: deploying TLS websites used to require one ip per hostname, and presently requires weird hacks like SNI (which leak the hostname to which one is connecting to observers). Being able to deploy any website on any port allows for a lot more flexibility in deployments, especially given the current trends such as “serverless”, k8s, et c.

ben0x539 8y ago
Hm, I don't quite understand, if I have multiple A records, is it still a single point of failure? Could you clarify the difference between having a bunch of SRV records and a bunch of A records here?
- JdeBP 8y ago
  If your client recieves multiple A/AAAA resource records, your client has no way to know what order they should best be tried in, from the server's point of view, and there is no way for the content DNS server to transmit that information. * http://jdebp.eu./FGA/dns-round-robin-is-useless.html http://jdebp.eu./FGA/dns-round-robin-is-useless.html Note that making priority and weighting available is given in the rationale section of the original RFC from 1996. What you're talking about actually isn't specific to HTTP. * https://tools.ietf.org/html/rfc2052 https://tools.ietf.org/html/rfc2052
- sneak 8y ago
  Most browsers will not retry to a second one if the first one it tries fails. Multiple A records do not fail over.

LinuxBender 8y ago

For web browsers, multiple A/AAAA are sufficient. Web browsers worked around the issues folks are mentioning some time ago using retries to each IP. The use of SRV could help in newer API driven implementations so that scripts and other tooling could enumerate which IP's are preferred. For now, developers will just have to make use of multiple records like the browsers do. That said, it won't likely happen because the HTTP spec does not allow new DNS implementations. The RFC would have to be deprecated with a new one that permits SRV. HTTP/2 would have been a grand opportunity to do just that. There have been many discussions [1] and debates on the issue, but I do not foresee it happening. [1] - https://www.ietf.org/mail-archive/web/httpbisa/current/msg25379.html https://www.ietf.org/mail-archive/web/httpbisa/current/msg25...

deleted 8y ago
[deleted]
inopinatus 8y ago
HTTP protocol & normative references don't actually mention DNS at all. The hand-wringing evidenced by some about the difficulties of introducing a new behaviour seems pretty feeble when you consider that Google has successfully intruded both a new transport protocol (QUIC) and a new application layer protocol (HTTP/2 i.e. SPDY) in a few short years. Rolling browser updates are now the norm and enable these major changes.
- LinuxBender 8y ago
  Agreed, but the protocol does not allow for deviation without creating a new protocol; which to your point, Google did. Google could have introduced SRV records as optional components in the spec. So the lack of mention of DNS standards in the protocol is sufficient to block the implementation of a new DNS requirement. Browsers are not the only thing that speak http. There are a myriad of libraries used by API's and all manor of automation that must also be updated to support a new protocol. A good example of this is SNI. All major browsers support SNI, but there are plenty of libraries that have yet to catch up to that very well aged protocol.

inopinatus 8y ago

An URL of "https://github.com" https://github.com" means looking up A and AAAA records for "github.com". The HTTP vendors are arrogant enough to demand that your host address for the whole domain is that of the web service, and not any other service. Because it's at the apex of the domain, that record also cannot be a CNAME alias, because the apex includes DNS metadata that is not allowed to be aliased. So instead we have numerous ugly hacks from DNS providers that vary that address record by tracking an alias target, with varying degrees of reliability. In other words, your DNS is now entirely subordinate to the demands of the web protocols and using ugly hacks to work around limitations of address records. You can stick a "www" on the front as a cheap, poorly specified, and untyped service selector, but because of the convention of just entering a domain name you'll still have to do the apex record. Basically, the current convention for HTTP is to overload the address record to be its personal service record and screw everyone else and the consequences. SRV also provides mechanisms for service fallback and weighted loadbalancing that address records do not. It can also conserve IP space by directing clients to alternative ports without ugly port specifications in the URI. There's a lot to like about it, and a lot to dislike about the current practices.

ben0x539 8y ago
For someone who goes by inopinatus, you sure sound opinionated ;) Thanks for the clarifications!
- inopinatus 8y ago
  It's actually Latin. But yes.