5 ms·

From the responses given to your linked comments, it seems like there was a technically valid reason not to use them: performance You just kept pushing that it

by tobz 12y ago

From the responses given to your linked comments, it seems like there was a technically valid reason not to use them: performance You just kept pushing that it wasn't a good enough reason. Are you just going to keep posting and asking until people decide you're right and they're wrong?

marcosdumay 12y ago
Take a better look at the responses. There's no inherent reason for the performance degradation (it's mainly because of noncompliance on Bind), and without it we are stuck with the much slower HTTP redirects.
- teddyh 12y ago
  Yes. Also CDNs and having your servers in the Cloud™ for automatic failover would be no longer necessary. So of course every company providing these services are against it. These companies are also, of course, the “stakeholders” interested in development of HTTP/2.
teddyh 12y ago
There actually is no performance problem. The closest anyone has come to a substantiation of that claim is to say, in essence, “If there is a buggy resolver somewhere which completely ignores SRV queries, the client would have to wait for a timeout.”. But this is not the normal, or even commonly occurring, case! SRV does not have such problems, or at least not enough for people to avoid using it for other protocols such as autodiscovery or Minecraft.
- tobz 12y ago
  (I'm responding inline, and I'm not looking at all the aforementioned posts/comments, so forgive me if I'm missing something here.) It sounds like you're arguing that SRV records are no slower than A records, which, on it's face, seems reasonable. A DNS request is a DNS request, and aside from a response being too big for UDP and having to switch to TCP, you should get nearly-identical performance. The part, to me, that looks like a real performance issue is potentially having to double the minimum amount of queries to serve a website. We couldn't possibly switch directly to SRV records; there would have to be an overlap of browsers using both SRV and A records for backwards compatibility. If we stick with that invariant, then we can say that the first-load cost of a page not using SRV records doubles in the worst case: websites that only have an A record. Now we're looking for a SRV record, not getting it, and falling back to an A record. So, now, all of the normal websites who don't give a crap about SRV records, won't ever use them, pay a performance penalty. A marginal one, sure. but it's there., So, overall, their claim seems valid, even if low in severity. I'd love to hear from someone that has the data, but I can count on one hand the number of times where a loss of IP connectivity has happened where I wish I had SRV records for load balancing. It's usually bad DNS records, or slow/bad DNS propagation, or web servers behind my load balancers went down, or a ton of other things. Your point is still totally valid about being able to more easily load balance across multiple providers, datacenters, what have you... but I'm not convinced it's as much of a problem as you make it out to be.
  - teddyh 12y ago
    If you really are in the position where an additional DNS request will kill you (unlike the overwhelming majority), there is an easy solution: Make sure all the servers pointed to by the SRV records are in the same domain (or at least that the domain is served by the same DNS server). Then the A (and AAAA) records should be present in the “ADDITIONAL” section of the DNS response. No more DNS questions are then necessary to get this data. > […] or web servers behind my load balancers went down […] I’m getting the impression that you think that even having a load balancer is a natural state of affairs, but it should not be. Getting more performance should be as easy as spinning up an additional server and editing the DNS data; done. Your attitude reminds me of the Unix-haters handbook, describing people who have grown up with Unix and are irreversibly damaged by it: “They regard the writing of shell scripts as a natural act.” (quoted from memory).
    - tobz 12y ago
      You make a valid point, but that relies on systems asking for all records on an RR. If a DNS server decides to send along A records with a SRV request, it's likely those A records won't be cached[1], and thus you'd have to make a second query. As far as load balancers, sure, it'd be great if nobody needed to do anything other than spread requests across a pool of heterogeneous machines... but there's plenty more to be had by using a load balancer in front of web servers, namely intelligent routing. Things you just couldn't possibly figure out, as the browser, from looking at SRV records. Besides that, I appreciate your thorough and clearly-informed thoughts on my attitude and state of mind when it comes to engineering systems. It definitely elevated this discussion to new heights, to be sure. 1. http://tools.ietf.org/rfcmarkup?doc=2181 http://tools.ietf.org/rfcmarkup?doc=2181
      - teddyh 12y ago
        > You make a valid point, but that relies on systems asking for all records on an RR. Um, no? If a DNS client asks a DNS server for an SRV record, and the DNS server has the A (and AAAA) records for the domain names contained within that SRV record, the DNS server will send those A (and AAAA) records along in the reply in the “ADDITIONAL” section; i.e. not in the “ANSWER” section as a reply to the actual SRV query, but still contained within the same DNS response. So the tiny performance issue for this minor case can be solved for those who need to solve it. > […] a load balancer [can also be used for] intelligent routing. Well, yes, SRV records can’t be all things to all people. This is, however, nothing which will affect, I guess, at least 90% of those even today using load balancers. Those needing this extra functionality can perfectly well keep their load balancers or (to call them for what they actually would be) HTTP routers. These are, however, both minor quibbles (the first of them even has a solution) and should not affect the decision to specify SRV usage in HTTP/2. (Also, being overly ironic does not help discourse, either.)

by tobz 12y ago

marcosdumay 12y ago

Take a better look at the responses. There's no inherent reason for the performance degradation (it's mainly because of noncompliance on Bind), and without it we are stuck with the much slower HTTP redirects.

teddyh 12y ago
Yes. Also CDNs and having your servers in the Cloud™ for automatic failover would be no longer necessary. So of course every company providing these services are against it. These companies are also, of course, the “stakeholders” interested in development of HTTP/2.

teddyh 12y ago

There actually is no performance problem. The closest anyone has come to a substantiation of that claim is to say, in essence, “If there is a buggy resolver somewhere which completely ignores SRV queries, the client would have to wait for a timeout.”. But this is not the normal, or even commonly occurring, case! SRV does not have such problems, or at least not enough for people to avoid using it for other protocols such as autodiscovery or Minecraft.

tobz 12y ago
(I'm responding inline, and I'm not looking at all the aforementioned posts/comments, so forgive me if I'm missing something here.) It sounds like you're arguing that SRV records are no slower than A records, which, on it's face, seems reasonable. A DNS request is a DNS request, and aside from a response being too big for UDP and having to switch to TCP, you should get nearly-identical performance. The part, to me, that looks like a real performance issue is potentially having to double the minimum amount of queries to serve a website. We couldn't possibly switch directly to SRV records; there would have to be an overlap of browsers using both SRV and A records for backwards compatibility. If we stick with that invariant, then we can say that the first-load cost of a page not using SRV records doubles in the worst case: websites that only have an A record. Now we're looking for a SRV record, not getting it, and falling back to an A record. So, now, all of the normal websites who don't give a crap about SRV records, won't ever use them, pay a performance penalty. A marginal one, sure. but it's there., So, overall, their claim seems valid, even if low in severity. I'd love to hear from someone that has the data, but I can count on one hand the number of times where a loss of IP connectivity has happened where I wish I had SRV records for load balancing. It's usually bad DNS records, or slow/bad DNS propagation, or web servers behind my load balancers went down, or a ton of other things. Your point is still totally valid about being able to more easily load balance across multiple providers, datacenters, what have you... but I'm not convinced it's as much of a problem as you make it out to be.
- teddyh 12y ago
  If you really are in the position where an additional DNS request will kill you (unlike the overwhelming majority), there is an easy solution: Make sure all the servers pointed to by the SRV records are in the same domain (or at least that the domain is served by the same DNS server). Then the A (and AAAA) records should be present in the “ADDITIONAL” section of the DNS response. No more DNS questions are then necessary to get this data. > […] or web servers behind my load balancers went down […] I’m getting the impression that you think that even having a load balancer is a natural state of affairs, but it should not be. Getting more performance should be as easy as spinning up an additional server and editing the DNS data; done. Your attitude reminds me of the Unix-haters handbook, describing people who have grown up with Unix and are irreversibly damaged by it: “They regard the writing of shell scripts as a natural act.” (quoted from memory).
  - tobz 12y ago
    You make a valid point, but that relies on systems asking for all records on an RR. If a DNS server decides to send along A records with a SRV request, it's likely those A records won't be cached[1], and thus you'd have to make a second query. As far as load balancers, sure, it'd be great if nobody needed to do anything other than spread requests across a pool of heterogeneous machines... but there's plenty more to be had by using a load balancer in front of web servers, namely intelligent routing. Things you just couldn't possibly figure out, as the browser, from looking at SRV records. Besides that, I appreciate your thorough and clearly-informed thoughts on my attitude and state of mind when it comes to engineering systems. It definitely elevated this discussion to new heights, to be sure. 1. http://tools.ietf.org/rfcmarkup?doc=2181 http://tools.ietf.org/rfcmarkup?doc=2181
    - teddyh 12y ago
      > You make a valid point, but that relies on systems asking for all records on an RR. Um, no? If a DNS client asks a DNS server for an SRV record, and the DNS server has the A (and AAAA) records for the domain names contained within that SRV record, the DNS server will send those A (and AAAA) records along in the reply in the “ADDITIONAL” section; i.e. not in the “ANSWER” section as a reply to the actual SRV query, but still contained within the same DNS response. So the tiny performance issue for this minor case can be solved for those who need to solve it. > […] a load balancer [can also be used for] intelligent routing. Well, yes, SRV records can’t be all things to all people. This is, however, nothing which will affect, I guess, at least 90% of those even today using load balancers. Those needing this extra functionality can perfectly well keep their load balancers or (to call them for what they actually would be) HTTP routers. These are, however, both minor quibbles (the first of them even has a solution) and should not affect the decision to specify SRV usage in HTTP/2. (Also, being overly ironic does not help discourse, either.)