4

Can we reasonably expect an API to access the browser's own DNS resolver? If not, why?

I know of the few workarounds available (HTTP encapsulation with a remote proxy, use of browser plugins), but these will either not take advantage of the browser's cache (which is usually the system's cache), or will require potentially undesired dependencies on the user's client.

I've read a reasonable amount of information regarding the security aspects of the issue but none ever really convinced me. Is it simply that nobody got around to propose and push a spec under WHATWG/W3C yet, or are there truly good reasons against such an API?

Related questions:

Community
  • 1
  • 1
tne
  • 7,071
  • 2
  • 45
  • 68
  • +1 to counter the downvote. It's a fine question, you've demonstrated you've searched for answers. While I think those answers are conclusive, it might be worth expanding your question to include your use-case, as maybe there are alternatives. – Paul Dixon Jul 29 '13 at 14:44
  • Thanks; my very specific use-case involves resolving SRV records that contain references to a host the script can then issue XHR requests to (using CORS). I would expand, but I fear it would add a little bit of noise to the question, I'm sure anyone can think of a few simpler examples where querying a DNS server would be useful (javascript network tools, ...). – tne Jul 29 '13 at 14:56

1 Answers1

1

Went digging a second time (properly now) on the W3C lists.

This was discussed in May 2011. I didn't find anything else on other relevant lists, nor at the WHATWG, so I now assume that this is the current state of things (as of July 2013).

To summarize:

  • There are legitimate concerns,
  • It's not clear that they can't be overcome,
  • A formal proposal has yet to be submitted to either the W3C or the WHATWG,
  • Support from browser vendors is probably required first since the feature appears to be non-trivial,
  • A collection of use-cases is needed.

PS: Also retrieved the logs for the discussion at #whatwg on Freenode mentioned in the bug entry; it doesn't seem directly relevant (although I did scan this very quickly).

Edit: Oh, and about the potential use of WebSockets; it still doesn't leverage the browser/system cache, and you still need a proxy server for the WebSockets HTTP handshake.

Update: The sysapps working group is writing a spec for a proper raw socket API which would support both UDP and TCP.

tne
  • 7,071
  • 2
  • 45
  • 68