DNS SRV Records for HTTP (2009)
datatracker.ietf.org
datatracker.ietf.org
- Service binding and parameter specification via the DNS (DNS SVCB and HTTPS RRs) https://datatracker.ietf.org/doc/draft-ietf-dnsop-svcb-https...
Still reveals a sad picture of the ecosystem that a standard which addressed the same shortcomings existed since 2009 but was completely ignored until Cloudflare reinvented it in a proprietary fashion.
On the other hand, expecting that end users suddenly start typing "https+srv://" everywhere for exactly no added benefit except to make standards wonks happy, doesn't exactly inspire much confidence in the standard's authors either...
(The drafts go up to -05, though this is not apparent from the posted link.)
[1] https://datatracker.ietf.org/doc/html/draft-jennings-http-sr...
dig +noall +answer -t type65 google.com
google.com. 2857 IN HTTPS 1 . alpn="h2,h3"
[1] - https://serverfault.com/questions/1075522/whats-the-use-case...
[2] - https://en.wikipedia.org/wiki/List_of_DNS_record_types
[0]: https://blog.cloudflare.com/speeding-up-https-and-http-3-neg...
As such architectures become more common, DNS SRV would allow many servers that are just providing an API to run on ports other than 80 even though main portal sites may still be running on the well known ports. Eventually, web browsers may end up supporting these SRV lookups, as the implementation is trivial and has very little downside."
My thoughts:
1. This would be very advantageous in cases like a K8s cluster, where if you want to use just DNS for service discovery, you still need an ingress listening on port 80 or 443, with nginx rules defined to route each service to a mapped port. A more general DNS method would eliminate the need of an ingress to route traffic.
2. We should be using this for all requests. It's more than a little ridiculous that it's 2022 and we have 65,535 different ports to use, but we can only use 1 of them (443) because we can't get the industry to fix its old designs.
It seems like an extra layer of indirection that doesn't solve any real problems and just adds complication.
Edit: i guess up until recently where ECH provided more of a rationale.
It makes web serving as robust as SMTP, with official fallback servers listed in the DNS. This makes most uses of CDNs or DDoS protection services unnecessary, as you can just spin up N different servers and list them all in the DNS. No need to centralize everything behind Cloudflare or Google.
It also solves the “apex delegation” problem; i.e. the problem of having to hard-code the IP address or addresses of a service at the apex domain name (i.e. on example.com instead of on www.example.com), without even having a CNAME, making you having to change that IP address on all domains using that web service whenever that service changes it IP address. (So-called “ALIAS” DNS records are fake; they are an ugly hack which does the aforementioned changing of IP addresses automatically.)
These two are what I personally consider the most important ones, but there are more:
https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-svcb-...
There are lots of load balancing solutions that are really well developed. I think most people use cloudflare because its really easy, and (the probably misguided notion) that shaving a few ms via georeplication is worth it . And for some users, fear of a volumetric DoS that just totally saturates the network link.
I feel like the type of people who would be content with the load balancing offered by SRV are probably already using load balancing on some other layer, e.g. LVS or HAproxy.
And yes, when people talk about DDoS mitigation, they are talking about a volumetric DoS that saturates their network link.
The SRV record was the way invented to expose ports to the dns system. like how A records expose addresses to dns.
But sadly this too was in the future. so the interim method used was to have services running on commonly agreed ports, the well known ports.
And so here we are stuck with ports, those will never go away, and stuck with the "well known ports", at least we have a mechanism to name ports. if only more programs would get with the act.
1. yes yes udp exists and has ports, I know, feel free to fill in TCP/UDP whenever you see TCP, if that makes you happy.
2. the narrow waist is an amazingly useful phenomenon, everything being addressed the same gives you great flexibility... And... I have just seen the light, the skies opened up, an angel spoke. you are right. ignore ports completely(or at least as much as you can) and give each service it's own ip6 address. not sarcasm, but genuine enlightenment. I already do this for dns servers, dns servers hate to run off port 53, while there are ways to change the port nobody is happy about it, it is less pain to give each one it's own address and bind to that. (Q: why do you run multiple dns severs on one box? A: because I run unbound and nsd)
This document specifies a new URI scheme called http+srv which uses a DNS SRV lookup to locate a HTTP server. The http+srv scheme operates in the same way as an http scheme but instead of the normal DNS A record lookup that a http scheme would use, it uses an DNS SRV lookup. This memo also defines a https+srv scheme that operates in the same was a an https URI but uses DNS SRV lookups.
This is straight up awful.