Bug 6872 – use DNS SRV records as part of the fallback process for domain names

• Status: RESOLVED
• Resolution: INVALID
• Component: New Bugs

[Freek Dijkstra]

SUMMARY
When a site for a domain is not found, Safari tries www.domain. A better approach is to check for SRV records of type _http._tcp.

STEPS TO REPRODUCE
1. Open Safari
2. Go to srvtest.macfreek. (without the http:// part).
3. Safari will first check for an A (or CNAME) record for srvtest.macfreek.nl, and if that fails for an A record of www.srvtest.macfreek.nl.

EXPECT RESULTS
I expected Safari, when no A record was found, to check the _http._tcp.srvtest.macfreek.nl SRV record, which points to mickey.macfreek.nl currently (may be removed by the time you read this report).

ACTUAL RESULTS
Safari seems to check only the domain, and www.domain, but not the services listed in the SRV records.

STANDARDIZATION INFORMATION
The SRV records are described in a Standards Track document of the IETF, RFC 2782.
Current usage of SRV records is little, though increasing. The _http._tcp server announcement is use with Bonjour (ZeroConf), though with another indirection. It should be pretty straightforward to implement this fallback mechanism.
This bug was reported in June 2004 with apple as rdar:3715164.

[Joost de Valk (AlthA)]

This is a valid request as per the RFC, no other browser has yet implemented this though, so i'm doubting if we will and should. It is however a valid request, and an enhancement, so confirming as such.

[Joost de Valk (AlthA)]

Mozilla hasn't implemented this either yet: 

https://bugzilla.mozilla.org/show_bug.cgi?id=14328

Firstly may I give my whole hearted thanks and appreciation to all the kind, considerate and talented people who work so hard on webkit.  I am really pleased to use Safari utilizing the webkit engine.  They are a joy to use.

I would like to add my vote/comment to the status of this enhancement request.  I understand it's implications on web servers and the reduced need for load balancers for example.  It is my hope this this sort of enhancement is exactly what Apple's Mobile Safari would put to good use to improve many people's interaction with the web.  As soon as it becomes a standard feature in a trend setting browser like Safari I'm sure many others will be quick to copy it and obviously the other browsers built on webkit will take instant advantage of this.  Please can I encourage a kind developer to take up this task.

Best regards and wishes to all involved.

Mark.

[Alexey Proskuryakov]

This would be Safari functionality, so there is no reason to have a bug in Bugzilla. Marking as INVALID per our policy.

This is tracked internally by Apple as <rdar://problem/3715164>.

To Alexey and any other interested developers:

I find it interesting that you dismiss this request as a Safari implementation rather than see it as a needed feature for WebKit. I would tend to agree, since WebKit is a layout engine, and thus shouldn't be dealing with issues at the DNS level. However, perhaps you forgot to inform the Chrome developers over at Google, as they shirked their responsibility for implementing DNS SRV support onto WebKit. This is how I found this bug, as a matter of fact...

http://code.google.com/p/chromium/issues/detail?id=22423

My problem with this lack of ownership of this issue--nay, feature--is not just the embarrassing bug-passing, not unlike when my phone service provider blames Nokia for a missing feature while Nokia swears this feature could only be locked by the provider (etc). 

My problem isn't just with the fact that this has been an ongoing outcry from users across the board: developers and system admins and the geek chic who just would like a more reliable web. An outcry for over 10 years.

My problem is not based on the fact that this feature request keeps being dismissed as a "bug-fix"-- although, this is HUGE-ly annoying and almost offensive. I can pull a DNS-SRV request right now from either of my OS's without a problem, so to suggest a bug, as though browser's just haven't quite caught up to this advanced technology, is just sad. The real bug is the low priority being placed on this...

My problem is this:

WebKit was meant to be the product of brilliant minds from all major tech industries working to create a unified and evolving vision of the perfect browser. Okay, maybe I'm exaggerating, but this was the gist of the project. And while Google and Apple may be rivals, and while consumers debate over the newest Symbian from Nokia or the iPhone or Android, what they all share is WebKit. And with Epiphany's decision to abandon Gecko and go with WebKit, several other alternative browsers are making the same switch.

My problem is that WebKit promises to be everywhere very soon. While Mozilla has a strong and solid reputation that will keep Firefox as a popular choice, most users will either be on Chrome or Safari on their desktop and some WebKit browser on their mobile. Even if Apple and Google have to split the vote and leave Firefox as the winning browser, in reality it is WebKit that will be the winner, whether end-users are aware of this or not.

My problem is that WebKit stands to see their vision through, and yet such a sought after feature like reliable connections via a smarter DNS lookup is just dismissed as something for Safari (or Chrome, or Nokia) to implement. Perhaps one of them will, or perhaps Mozilla will beat them all to the punch, but it should be fairly obvious that all other browsers will scramble to catch up.

So why not make it a WebKit feature instead, and advance so many browsers at once and have Mozilla and Opera scrambling to be ahead of the curve for once? 


If it can't be done at the WebKit level, you know as well as I do it can be mandated at the WebKit level.