Hi Delan, We have had a fair amount of discussions about this, and I would say that perhaps very few people would disagree with what you wrote below. However, an additional level of indirection in the SRV record can come at a cost, which is additional latency, and perhaps a lot of additional latency on first use, and it depends on a lot of factors, like RR TTLs on both the SRV record itself and the A record that is returned as part of RDATA, and whether or not that record itself requires multiple queries to satisfy. And so we examined not one, but several new different RRs to address those concerns, but in the end, people want to get on with getting out the door what is in the document now. Eliot On 1/2/15 9:29 AM, Delan Azabani wrote: > I'm not sure if it's appropriate for a random netizen like myself to > contribute to these comments, so my apologies in advance if it isn't. > > Please consider supporting SRV resource records. > > HTTP is simultaneously important enough that one can't simply run a > single server for any popular application, but not so important that it > deserves to necessarily be the A/AAAA record for every hostname. > > SRV makes service discovery more flexible than even MX records by: > > * Decoupling the default use of TCP port 80 for HTTP, allowing hosts > to run multiple distinct HTTP servers without needing a reverse > proxy or requiring users to explicitly override the port; > > * Allowing server administrators to create a tiered and weighted form > of load balancing by using the record's Priority and Weight fields, > again without shifting the point of failure to reverse proxies; and > > * Making it easier to transparently and scalably host services for > multiple protocols on a single apex domain name. > > Although the Target field of a SRV RR is a domain name, not an IPv6 or > IPv4 address, the resolution delay before a TCP connection is initiated > is unlikely to increase significantly because: > > * To reduce the need for multiple queries, "Implementors are urged, > but not required, to return the address record(s) in the Additional > Data section." [RFC 2782 page 4] > > * Like the record types PTR, MX and CNAME, "Domain names in RRs which > point at another name should always point at the primary name and > not the alias. This avoids extra indirections in accessing > information." [RFC 1034 § 3.6.2] > > To further avoid the complexity and inefficiency of multiple queries, > 'only the service name "http" should be used' when SRV records are > used, not the synonyms "www" or "www-http". [RFC 6335 § 5] > > LDAP, SIP, XMPP and Kerberos are successful examples of protocols which > rely on SRV resource records for service discovery. > > For these benefits to be realised however, HTTP/2 should explicitly opt > into support for SRV records, because "Service SRV records SHOULD NOT > be used in the absence of" an indication in the protocol specification > that clients should use SRV records for discovery. [RFC 2782 page 2] > > >
Attachment:
signature.asc
Description: OpenPGP digital signature