Take the 2-minute tour ×

Why do browsers not use SRV records?


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.

share|improve this question
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. –  RobM Jan 30 '12 at 12:48
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 '12 at 12:57
Shameful isn't it? –  JdeBP Jan 31 '12 at 12:19
exact duplicate of stackoverflow.com/questions/9063378/… –  Alnitak Feb 1 '12 at 12:01
@chrisdew why have you asked the exact same question on both sites? –  Alnitak Feb 1 '12 at 12:06

2 Answers 2

up vote 4 down vote accepted

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.

share|improve this answer
HTTP 1.1 was 2616, so also missed it. Is HTTP 1.2 with SRV support that we need? –  chrisdew Jan 30 '12 at 12:26
No, because quess what - it is not needed ;) –  TomTom Jan 30 '12 at 12:27
-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 '12 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 '12 at 14:04
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 '12 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).

share|improve this answer
-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 '12 at 13:38
@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 '12 at 13:49
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 at 10:25
@FlashFan unfortunately, corporates persist in wanting to block internet egress by assuming that all web sites are on port 80 or 443. –  Alnitak Oct 27 at 18:36
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 at 8:11

Your Answer


