It seems like a minimal amount of work and it will make the server-side implementation of reliable websites much simpler. Also SRV records have been around for years...

Is there something I'm missing here?

Edit: @DJ Pon3 - what I'm talking about is:

  1. one site served from two datacentres without needing BGP, but still working if either datacentre goes offline. (Can also be achieved by short DNS TTLs.)

  2. multiple httpS servers on different ports on one IP address.

  • I'm not clear as to what problem, precisely, you think this would solve. Its been perfectly possible to create reliable web services without srv records so far.
    – Rob Moir
    Jan 30, 2012 at 12:48
  • 1
    I think (and maybe only because I'm a simpleton) that it would solve the issue of running a web site on an alternate port without the user needing to know what port the site is running on and having to type the port number in the URL.
    – joeqwerty
    Jan 30, 2012 at 12:57
  • Shameful isn't it?
    – JdeBP
    Jan 31, 2012 at 12:19
  • 2
    exact duplicate of stackoverflow.com/questions/9063378/…
    – Alnitak
    Feb 1, 2012 at 12:01
  • @chrisdew why have you asked the exact same question on both sites?
    – Alnitak
    Feb 1, 2012 at 12:06

2 Answers 2


Why do browsers not use SRV records?

Because SRV records did not exist when http was onceived and because http is not assumd to be a service.

SRV records have been around for years...

Hahaha. Do you remember the time when HTTP started? Wen the first browsers were writtten? THAT was a long time ago.

SRV are first in RFC 2782. HTTP goes to RFC 1945 for 1.0. Guess which was first.

  • HTTP 1.1 was 2616, so also missed it. Is HTTP 1.2 with SRV support that we need?
    – fadedbee
    Jan 30, 2012 at 12:26
  • No, because quess what - it is not needed ;)
    – TomTom
    Jan 30, 2012 at 12:27
  • 15
    -1 for the rather silly argument that relative ages constrain interoperability. The world really does have the capability of making two separate inventions work together once they exist, and has done just that many times throughout history. It has even done it twice over for SRV resource records and HTTP.
    – JdeBP
    Jan 31, 2012 at 12:03
  • @JdeBP you well know that if it were that easy it would have been done by now. The problem is transitioning sites to an HTTP+SRV mechanism without providing an inferior experience to the countless millions of users that would be stuck on old browsers.
    – Alnitak
    Feb 1, 2012 at 14:04
  • 6
    You mean a couple of times someone wrote an internet draft? That's hardly the same - it's trivial to write one, and then the real world hits you and you find that actually there's shed loads of edge cases and other issues that means it won't work in the real world, and eventually the draft expires and is mostly forgotten. Hell, I've had that happen to quite a few of mine already.
    – Alnitak
    Feb 7, 2012 at 13:51

SRV records offer three things:

  1. Multiple hostnames - can be done without
  2. Alternate ports - bad idea - see below
  3. A fix for the CNAME at zone apex problem

Re: alternate ports - SRV records could be used as a way of running web servers on alternate ports without having to advertise that fact in the URL. This is a bad thing. Corporate firewall policies very commonly prohibit access to "unusual" ports, and encouraging the idea of using alternate ports would be poor for site accessibility.

The only tangible benefit I see is for #3 - it would allow example.com to get redirected to webhost.example.net without requiring a CNAME (which isn't permitted in a zone apex) or an A record (which is bad for zone maintenance).

  • 3
    -1 for missing the whole point, despite many people making it over the years as they ask for this and the questioner even alluding to it, which is of course the explicit load balancing and fallback information for clients.
    – JdeBP
    Feb 7, 2012 at 13:38
  • 3
    @JdeBP IMNSHO load balancing and fallback data does not belong in the DNS - that's well into the realms of "Stupid DNS Tricks (TM)". They both belong in the IP routing layer - that's the only place you can provide seamless failover between services.
    – Alnitak
    Feb 7, 2012 at 13:49
  • 3
    Actually, Alternate Ports is a good idea because protocols should not be bound to ports. Imagine a world where the post office always had to be at the second floor in the building, wouldn't that be pointless? That's what we have address books (DNS) for! What's really a bad idea is defining outgoing firewall rules based on a port. It's just pointless because attackers always could use the not-blocked ports. Additionally, imagine a world where it would be denied to go to floor 2 in every building, just because it could be a post office. Funny, isn't it? ;)
    – FlashFan
    Oct 27, 2014 at 10:25
  • 4
    Yes, I know. That's why enabling SRV records would be good, because it force the corporates to stop doing those pointless, bad practices. No matter how much outgoing ports you block, as long as there is one port open, you can do everything you want, because you can do everything though every port. The fact, that you cannot even know if what goes through the TLS connection on port 443 really is HTTP, does only underline this.
    – FlashFan
    Oct 28, 2014 at 8:11
  • 1
    @specializt No, you can't filter out non-HTTP protocols on a TLS connection. That would require you to be able to decrypt the connection, and that is only possible if you force all network users to trust your MITM certificate.
    – FlashFan
    Jun 17, 2022 at 14:57

Not the answer you're looking for? Browse other questions tagged .