4 ms·

DNS SRV Records for HTTP (2009)

67 points by apitman 4y ago

olx_designer 4y ago
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.
- deleted 4y ago
  [deleted]
IgorPartola 4y ago
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.
- billfruit 4y ago
  But it is a legitimate case to specify any particular port to access a service than being merely follow convention.
- mugsie 4y ago
  I would also allow for apex load balancing, weighted load balancing, and failover without needing someone like cloudflare / akamai / a glb, all using standards
ivanr 4y ago
Take a look instead at the DNS SVCB and HTTPS resource records, which have already been adopted in practice: - Service binding and parameter specification via the DNS (DNS SVCB and HTTPS RRs) https://datatracker.ietf.org/doc/draft-ietf-dnsop-svcb-https/11/ https://datatracker.ietf.org/doc/draft-ietf-dnsop-svcb-https...
- xg15 4y ago
  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...
  - mananaysiempre 4y ago
    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-srv-00 https://datatracker.ietf.org/doc/html/draft-jennings-http-sr...
- pdenton 4y ago
  Does this deprecate TTLS records? I've only just begun to generate those
- Bender 4y ago
  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] dig +noall +answer -t type65 google.com google.com. 2857 IN HTTPS 1 . alpn="h2,h3" I see some hits in my name server stats for https/svcb types so I guess bots are looking for it. Perhaps scanning how widely adopted? The list of types has grown since I last looked. [2] People have been busy. [1] - https://serverfault.com/questions/1075522/whats-the-use-case-of-svcb-type-65-service-binding-rr https://serverfault.com/questions/1075522/whats-the-use-case... [2] - https://en.wikipedia.org/wiki/List_of_DNS_record_types https://en.wikipedia.org/wiki/List_of_DNS_record_types
throwawaaarrgh 4y ago
"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.
bawolff 4y ago
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.
- teddyh 4y ago
  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-https-11#section-1.1 https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-svcb-...
  - bawolff 4y ago
    > 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.
    - 4y ago
teddyh 4y ago
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-11.html https://www.ietf.org/archive/id/draft-ietf-dnsop-svcb-https-...
pashadee 4y ago
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.
charsi 4y ago
MongoDB has been using something similar for a little while now - https://www.mongodb.com/developer/products/mongodb/srv-connection-strings/ https://www.mongodb.com/developer/products/mongodb/srv-conne...

67 points by apitman 4y ago

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.

deleted 4y ago
[deleted]

IgorPartola 4y ago

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.

billfruit 4y ago
But it is a legitimate case to specify any particular port to access a service than being merely follow convention.
mugsie 4y ago
I would also allow for apex load balancing, weighted load balancing, and failover without needing someone like cloudflare / akamai / a glb, all using standards

ivanr 4y ago

Take a look instead at the DNS SVCB and HTTPS resource records, which have already been adopted in practice: - Service binding and parameter specification via the DNS (DNS SVCB and HTTPS RRs) https://datatracker.ietf.org/doc/draft-ietf-dnsop-svcb-https/11/ https://datatracker.ietf.org/doc/draft-ietf-dnsop-svcb-https...

xg15 4y ago
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...
- mananaysiempre 4y ago
  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-srv-00 https://datatracker.ietf.org/doc/html/draft-jennings-http-sr...
pdenton 4y ago
Does this deprecate TTLS records? I've only just begun to generate those
Bender 4y ago
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] dig +noall +answer -t type65 google.com google.com. 2857 IN HTTPS 1 . alpn="h2,h3" I see some hits in my name server stats for https/svcb types so I guess bots are looking for it. Perhaps scanning how widely adopted? The list of types has grown since I last looked. [2] People have been busy. [1] - https://serverfault.com/questions/1075522/whats-the-use-case-of-svcb-type-65-service-binding-rr https://serverfault.com/questions/1075522/whats-the-use-case... [2] - https://en.wikipedia.org/wiki/List_of_DNS_record_types https://en.wikipedia.org/wiki/List_of_DNS_record_types

throwawaaarrgh 4y ago

"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.

bawolff 4y ago

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.

teddyh 4y ago
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-https-11#section-1.1 https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-svcb-...
- bawolff 4y ago
  > 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.
  - 4y ago

teddyh 4y ago

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-11.html https://www.ietf.org/archive/id/draft-ietf-dnsop-svcb-https-...

pashadee 4y ago

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.

charsi 4y ago

MongoDB has been using something similar for a little while now - https://www.mongodb.com/developer/products/mongodb/srv-connection-strings/ https://www.mongodb.com/developer/products/mongodb/srv-conne...