Hacker News Reader

Comment by janci | Hacker News Reader

It's sad SRV records are not used for the web for running http(s) services on different ports (instead of virtual hosts and SNI).

View on HN

And because SRV records are not used for the web, they can't be used at all, as some routers or something doesn't support them and instead discards them. (~10% of users according to the admin of yaxim.org)

And then along comes https://datatracker.ietf.org/doc/draft-ietf-dnsop-svcb-https... defining a "SRV2", SVCB and also its identical twin the HTTPS RR (same format, different RR number). I have a fear that those routers will end up supporting the HTTPS RR but not SVCB...

Outside of businesses it doesn't matter at all. You'll use DoH to escape local garbage. A variation on Happy Eyeballs will automatically try to do QUIC unless that doesn't work in which case you get TLS.

At work, obviously IT group policy, "security" middle boxes and so on will insist on whatever set of nonsense is just barely enough to keep the Marketing Director's twitter working how she likes it, and the Sales Director's Candy Crush on his work phone. Can't help you really on that.

I've never had problems with srv records for matrix servers, Minecraft servers, email auto configuration etc.

The draft outlines the differences from SRV for anyone curious:

* https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-svcb-...

SRV records are critical for the functionality of SIP and VoIP.

The lack of adoption of SRV records for web protocols fills me with immense sadness. Having a separate service location layer, as a general design principle, would have made so many things much easier on the Internet (load balancing, failover, multiplexing multiple services on a single IP).

Then you'll love HTTPS records, described at the linked article and currently being finished up for use with QUIC and ECH.

If HTTP(S) would run on a multitude of ports in the wild, firewalling would become an impossible task.

IPv6 also solves the problem, as you can easily assign a big subnet to a web server and one IP per (sub-) domain.

And with the upcoming ESNI there are probably some additional privacy benefits.

But - if we had SRV records for http(s), things like geo load balancing would be super simple, no need for anycast / weird CNAME chains. The client would get a list of hosts, with attached priorities, and weights.

Do you have any further information on this topic, some blog post or something that explains how this would work?

basically normal A response (whether or not coming from a cname) doesn't define any weights or priority. just order may be changed by the server

according to clients' geoip, you just need to adjust weights/priority in the srv record so, a client can fallback next-nearest server

I don't have a specific URL for you (other than for the authoritative source, the DNS RFCs) but a good example would be how clients in an Active Directory environment find a Domain Controller to log on to -- I'm sure there's plenty of documentation and examples of that on the web!

Hint: This same method (SRV RRs and priorities/weights) so that a client communicates with a Domain Controller down the hall, instead of another one halfway across the country.

Then, just imagine that it's a web browser connecting to a web server, instead of a workstation connecting to a DC.

Why is that sad?

Reply on news.ycombinator.com