Hacker News Reader

Comment by mugsie | Hacker News Reader

This is why I wish that as part of HTTP 2 they had allowed the use of SRV records and gotten it built into the browsers / clients etc.

SRV records are far superior - its a priority and weighted list of hosts for a protocol, which could really cut down on load balancing complexity.

View on HN

I don't think there is a reason it would have to be tied to HTTP 2, and also not much to gain by explicitly including it. Proposals for using SRV records for HTTP have been around a long time, seems like there have been some open questions and not all that much interest.

The Mozilla Bug is old enough that it is a Mozilla bug (Firefox didn't exist when it was filed): https://bugzilla.mozilla.org/show_bug.cgi?id=14328

Chromium's bug is from 2009: https://bugs.chromium.org/p/chromium/issues/detail?id=22423 (which has some interesting comments regarding DNS fallback behavior and the latency penalties incurred)

The HTTP 2 standard must include provisions for SRV records to be used, since that is part of how clients should follow a URL. Additionally, the SRV specification itself says that a protocolspecification must say that SRV record should be used before any client of that protocol takes it upon itself to use SRV records.

The most explicit reference to name resolution I know of in any of the HTTP standards is RFC 7230 Section 2.7.1 (https://tools.ietf.org/html/rfc7230#section-2.7.1), which is still quite vague:

[...] If host is a registered name, the registered name is an indirect identifier for use with a name resolution service, such as DNS, to find an address for that origin server.

[...]

When an "http" URI is used within a context that calls for access to the indicated resource, a client MAY attempt access by resolving the host to an IP address, establishing a TCP connection to that address on the indicated port, and sending an HTTP request message (Section 3) containing the URI's identifying data (Section 5) to the server.

I don't think that excludes SRV-based name resolution. Some sort of standardization of course would be helpful, even if just for reference, but that could in my mind be an independent document recommending to use SRV instead for HTTP, without any detail about the version (since HTTP 2 has no property that makes it more or less fit for use with SRV records than 1.1). Adding something that's totally unclear if it ever will see any use to HTTP2 just because seems worse.

Yes; a thousand times yes.

I have written about this here before:

https://news.ycombinator.com/item?id=8404612

https://news.ycombinator.com/item?id=8850251

Is that relevant to HTTP/2, though? Does HTTP/2 say anything about DNS at all?

Isn't that the same as doing DNS round robin?

Also with software defined networking load balancing you can have one user facing ip be backed by many servers.

No, DNS round robin has ... issues.

With SRV, you can set a priority, so it goes to a set of hosts first, then falls back.

You can also weight traffic so that some hosts get more than others.

(also host is actually an A (or AAAA) record - so it could have multiple values as well)

> Also with software defined networking load balancing you can have one user facing ip be backed by many servers.

Sure - but software defined (or normal) load balancing is usually inside the datacenter or region. Its another tier behind the DNS layer.

Also, DNS round robin won’t work with IPv6. At all. Round robin DNS depends on a client connecting to the first address record it receives in the DNS reply, and the DNS server altering its responses to set different addresses as the first one each time it sends a DNS response. But with IPv6, a client host is required to connect to the address closest to its own (as determined by the longest range of common bits), regardless of the adress’ position in the DNS reply.

Tragic missed opportunity.

Reply on news.ycombinator.com