Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

Why do browsers not use SRV records?

It seems like a minimal amount of work and it will make the server-side implementation of reliable websites much simpler.

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
show 1 more comment

2 Answers

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
6  
-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
3  
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
show 1 more comment

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
1  
@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
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.