On Fri, Jun 15, 2018 at 6:40 PM Mark Andrews <ma...@isc.org> wrote: > What we should be asking is why a service that needs multiple machines > isn’t using SRV. It has randomisation between servers explicitly defined > along with proportional load balancing. >
That would be nice, but sadly major applications like the web, have (in my assessment) never seriously shown any interest in using SRV records. To quote some of the discussion of HTTP2 on this subject: from https://lists.w3.org/Archives/Public/ietf-http-wg/2015AprJun/0674.html: --- excerpt "We discussed this, but decided not to support SRV in HTTP/2 - mostly because HTTP/2 needs to be backwards-compatible with the existing Web, which doesn't use SRV. In discussion, it also became pretty clear that if we were to use an additional record type for HTTP, SRV may not suit, because we need to do things like protocol version negotiation. There were also concerns about latency and interoperability (especially considering how many DNS requests a page load can make, and the unfortunate limitations of some DNS gateways/proxies)." --- end excerpt The latter point about additional latency, due to the need for additional follow-on queries to resolve the address records for the SRV targets (if the resolver hasn't provided them), has been a pretty potent blocker for SRV adoption in the web. Also, in my experience, many implementations of client applications that do employ SRV don't even bother to implement the load balancing aspect, just the priority aspect. This was particularly true in Kerberos from my recollection. > It also addresses CNAME at the apex which quite frankly is only used to > find the name of the HTTP server for the zone which SRV is quite capable > of doing. > Yup .. Shumon.
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
