7 ms·

This is what SRV records were (largely) created for. There have been a couple of attempts at making this a reality: https://tools.ietf.org/html/draft-andrews-h

This is what SRV records were (largely) created for. There have been a couple of attempts at making this a reality: https://tools.ietf.org/html/draft-andrews-http-srv-01 https://tools.ietf.org/html/draft-andrews-http-srv-01 https://tools.ietf.org/html/draft-jennings-http-srv-05 https://tools.ietf.org/html/draft-jennings-http-srv-05 Unfortunately, HTTP is just too widespread of a protocol - you would end up having to listen for legacy clients on 80/443 forever, making it a nonstarter.

mikeash 9y ago
The sooner we get started, the sooner we'll be able to actually take advantage of it. It's true that you have to wait a long time, but that's no reason to avoid it. SNI wasn't widely supported initially, for example, but these days you can safely require it unless you have weird requirements. There probably isn't enough need for it to get the major vendors to start adopting it, though.
- marcosdumay 9y ago
  Browsers won't lead the way. Fetching SRV records will increase network latency, and that's one of the main points of competition among browsers today.
  - mikeash 9y ago
    Is it not possible to fetch them as part of the same request that looks up the IP address?
    - marcosdumay 9y ago
      My DNS knowledge is a bit rusty. I remember there are some issues with requiring different types of record on the same request (most servers block it), and that timeout worked differently for different types of record. I did never try resolving HTTP services anyway, so I may be completely wrong. I've had problems with TXT and MX.
      - mikeash 9y ago
        Interesting. It would make sense that requests that don't get used in the real world might not work well.
dsparkman 9y ago
The reality is that this is not that infeasible a change as everyone wants us to think that it is. It is simply a change to the DNS resolution logic for HTTP/HTTPS. The major browser vendors could make the change in relatively short order. The major hurdle is that it would increase the number of DNS queries to resolve a website. XMPP is an example of a protocol that currently has this correct, in that it uses SRV records to control ports for a given host.
- LgWoodenBadger 9y ago
  Why would it involve extra DNS queries? Why wouldn't the SRV record come back as part of the original response to the host-name resolution request?
  - zAy0LfpBZLC8mAC 9y ago
    There is no such thing as a "host-name resolution request". A DNS query specifies a domain name and a record type, and gets as the result a list of all records of that type under that name. Record types would be A (IPv4 address), AAAA (IPv6 address), MX (mail exchanger name), SRV (server name and port for a particular service), TXT (free-form text), and many others, most of them nowadays unused.
    - icebraining 9y ago
      You can specify "ANY" as the type in the query and get all results. Try running "host -a ycombinator.com". It doesn't recursively resolve CNAMEs like an A query does, though. Also, at least Cloudflare refuses those requests, to reduce DNS reflection attacks.
      - zAy0LfpBZLC8mAC 9y ago
        ANY gives you all records for the given name in the cache of the name server that you are querying, which usually will be incomplete in the case of recursive resolvers.
      - 9y ago
Nullabillity 9y ago
As a workaround, couldn't you just have, say, nginx listen on 80/443 and either redirect or reverse proxy to the correct endpoints based on the SRV records? That way, compliant browsers can connect directly while SRV-ignoring browsers would just get proxied (or redirected), and once set up there would be no special actions needed by the users, save for telling the proxy about the keys and certs.

mikeash 9y ago

The sooner we get started, the sooner we'll be able to actually take advantage of it. It's true that you have to wait a long time, but that's no reason to avoid it. SNI wasn't widely supported initially, for example, but these days you can safely require it unless you have weird requirements. There probably isn't enough need for it to get the major vendors to start adopting it, though.

marcosdumay 9y ago
Browsers won't lead the way. Fetching SRV records will increase network latency, and that's one of the main points of competition among browsers today.
- mikeash 9y ago
  Is it not possible to fetch them as part of the same request that looks up the IP address?
  - marcosdumay 9y ago
    My DNS knowledge is a bit rusty. I remember there are some issues with requiring different types of record on the same request (most servers block it), and that timeout worked differently for different types of record. I did never try resolving HTTP services anyway, so I may be completely wrong. I've had problems with TXT and MX.
    - mikeash 9y ago
      Interesting. It would make sense that requests that don't get used in the real world might not work well.

dsparkman 9y ago

The reality is that this is not that infeasible a change as everyone wants us to think that it is. It is simply a change to the DNS resolution logic for HTTP/HTTPS. The major browser vendors could make the change in relatively short order. The major hurdle is that it would increase the number of DNS queries to resolve a website. XMPP is an example of a protocol that currently has this correct, in that it uses SRV records to control ports for a given host.

LgWoodenBadger 9y ago
Why would it involve extra DNS queries? Why wouldn't the SRV record come back as part of the original response to the host-name resolution request?
- zAy0LfpBZLC8mAC 9y ago
  There is no such thing as a "host-name resolution request". A DNS query specifies a domain name and a record type, and gets as the result a list of all records of that type under that name. Record types would be A (IPv4 address), AAAA (IPv6 address), MX (mail exchanger name), SRV (server name and port for a particular service), TXT (free-form text), and many others, most of them nowadays unused.
  - icebraining 9y ago
    You can specify "ANY" as the type in the query and get all results. Try running "host -a ycombinator.com". It doesn't recursively resolve CNAMEs like an A query does, though. Also, at least Cloudflare refuses those requests, to reduce DNS reflection attacks.
    - zAy0LfpBZLC8mAC 9y ago
      ANY gives you all records for the given name in the cache of the name server that you are querying, which usually will be incomplete in the case of recursive resolvers.
    - 9y ago

Nullabillity 9y ago

As a workaround, couldn't you just have, say, nginx listen on 80/443 and either redirect or reverse proxy to the correct endpoints based on the SRV records? That way, compliant browsers can connect directly while SRV-ignoring browsers would just get proxied (or redirected), and once set up there would be no special actions needed by the users, save for telling the proxy about the keys and certs.