DNS SRV Records for HTTP (2009)(datatracker.ietf.org)
datatracker.ietf.org
DNS SRV Records for HTTP (2009)
https://datatracker.ietf.org/doc/id/draft-jennings-http-srv-01.html
8 comments
It appears Google implemented the records type65, but not type64. Also Youtube. I am curious what browsers are leveraging this currently. I can't find many other domains using it yet. It seems Apple use it on some subdomains [1]
[1] - https://serverfault.com/questions/1075522/whats-the-use-case...
[2] - https://en.wikipedia.org/wiki/List_of_DNS_record_types
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
Chrome at least, behind a flag.[1]
[1] https://chromestatus.com/feature/5485544526053376
[1] https://chromestatus.com/feature/5485544526053376
Beat me to it, I was also wondering if the OP proposal hasn't been completely obsoleted by SVCB/HTTPS at this point.
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...
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 -00 draft[1] did not require the +srv. I would guess the blame lies with security problems when user agents with support for the SRV record see one thing and those without see another.
(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...
(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...
Does it support specifying the HTTPS port? This is a very important use case for selfhosting. I skimmed through Cloudflare's article[0] but didn't see any mention of it.
[0]: https://blog.cloudflare.com/speeding-up-https-and-http-3-neg...
[0]: https://blog.cloudflare.com/speeding-up-https-and-http-3-neg...
Ok after a little searching the spec itself talks about a port parameter in section 7.2. So it would appear SVCB can indeed replace HTTP SRV for my purposes.
Does this deprecate TTLS records? I've only just begun to generate those
This draft RFC expired 13 years ago. The corresponding modern standard is, as
ivanr correctly points out, DNS SVCB and HTTPS records: https://www.ietf.org/archive/id/draft-ietf-dnsop-svcb-https-...
"It is not expected that most web browsers would support these schemes for generic web use. It would instead be used for particular applications using HTTP such as specific web APIs. These APIs would be defined to require the use of this specification. In this situation, the end user's web browser might not do the SRV lookup when it browsed to the portal web pages, but the HTTP calls that the portal made out to other sites to generate the content would use this mechanism.
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.
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.
I dont get why people keep trying to make SRV happen.
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 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 (either SRV or HTTPS/SVCB) solves two significant problems:
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-...
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-...
> 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.
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.
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.
The problem CDNs solve can simply not be solved at protocol-level load balancing.
And yes, when people talk about DDoS mitigation, they are talking about a volumetric DoS that saturates their network link.
And yes, when people talk about DDoS mitigation, they are talking about a volumetric DoS that saturates their network link.
tcp[1] added an additional address segment, what is called the "port". in a perfect world this would not exists and it would be a single unified address(the ip address) all the way down[2], but this was before the ip6 post address scarcity future and the port was seen as the way to allow each host to deliver many services.
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)
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)
The purpose is not really clear from abstract:
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 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.
[deleted]
A problem of the mentioned SVCB records is that while theoretically they're capable of HTTP (unencrypted etc), http is not mentioned in the upcoming drafts directly and no browser supports HTTP via SVCB. Only HTTPS.
MongoDB has been using something similar for a little while now - https://www.mongodb.com/developer/products/mongodb/srv-conne...
What a terrible proposal. First, the correct solution is IPv6 and not this hack. Second, why would you even start by suggesting that only some HTTP clients support this? To make my life more difficult because e.g. curl supports this but Chrome doesn’t do that debugging is harder? Would a browser that does support it hide the fact that I am connecting to a non-standard port so that when I do take the URL to a library that does not support this that it would fail with “Connection refused” for no discernible reason?
This is straight up awful.
This is straight up awful.
- Service binding and parameter specification via the DNS (DNS SVCB and HTTPS RRs) https://datatracker.ietf.org/doc/draft-ietf-dnsop-svcb-https...