Specifically you want to be able to perform arbitrary DNS lookups, right, not just A record lookups?  This might have security implications for clients behind intranet firewalls.

Correct - arbitrary lookups. The record types I'm specifically interested in querying are NAPTR, LOC, and TXT. What are the security implications you have in mind?

Mostly that we don't know what kind of things intranets might be storing in DNS.  Maybe it's nothing sensitive, but it's dangerous to rely on such assumptions.  JavaScript normally has no network access other than same-origin for this kind of reason.

However, if we restrict it to same-origin access or similar, that should be fine.  If that's not good enough, we could at least blacklist private-use IP addresses unless the current site is itself on a private IP address.  Or something.

But I imagine you'd have to provide some pretty broadly applicable use-cases to convince browser implementers that it's worth implementing.  There are tons of proposed features out there that would benefit 50% or more of web users, so anything that doesn't seem like it will really benefit a lot of people is unlikely to get implemented.  I'd advise you to explain in detail what you're trying to do, why it would be useful to a very large number of web users if you could do it, and why you can't do it in some other way with existing technologies.

(In reply to comment #3)

I have no knowledge of whether private resolvers may contain confidential information or not, but I certainly take your point about making assumptions.

Restricting to same-origin wouldn't be sufficient for the kinds of applications I envisage. But as you said, a solution might be to blacklist queries on private networks, such that only resolvers on public networks are queried.

At this time it's very difficult for me to explain why I believe this is going to be desirable, without breaching confidentiality, but suffice to say some very large mobile operators are now developing interesting services based on DNS.

People may suggest using a web service to proxy DNS queries through to HTML5 apps, but we'd lose many of the benefits of DNS this way (distributed, lightweight, low latency, etc).

I should point out that according to this blog post, about 1% of Chrome (Linux) users don't have the ability to resolve arbitrary DNS record types, due to firewalls and so on:

http://www.imperialviolet.org/2011/06/16/dnssecchrome.html

This would be a significant impediment to the usability of any sort of general DNS querying service from web browsers.  New web browser-based protocols, like SPDY or WebSockets, normally have to either use TLS or masquerade as HTTP to ensure that they're usable even behind firewalls.  So again, strong use-cases would be needed that demonstrate that DNS is really the right way to solve this before it could be seriously considered.

(In reply to comment #4)
> Restricting to same-origin wouldn't be sufficient for the kinds of applications
> I envisage. But as you said, a solution might be to blacklist queries on
> private networks, such that only resolvers on public networks are queried.

Discussion in #whatwg today suggests that it's unlikely that would be enough.  Private networks might also be using public IP ranges and relying on firewalls to protect them.  We don't know whether there will be security consequences or not, but if there are, we'll probably only figure out long after the feature is widely used, so that we can't fix it.  This has happened before in the history of the web and provides recurring security headaches to this day -- e.g., information leakage through embedding cross-origin images.  We don't want to risk it for the future.

The way AJAX and so on work these days is that they're same-origin by default, but origins can opt in to allowing cross-origin requests using CORS.  If there's a strong use-case for allowing DNS queries of this sort, a similar solution could be devised, like a special DNS record that would allow browsers cross-origin access.

> At this time it's very difficult for me to explain why I believe this is going
> to be desirable, without breaching confidentiality, but suffice to say some
> very large mobile operators are now developing interesting services based on
> DNS.

Unfortunately, it's unlikely anyone will be interested in implementing an API like this in a major web browser on that basis.  There are potential security issues, and the possibility that it won't work for a significant minority of users, plus it's not at all a trivial feature to spec or implement.  If you or your employer is interested in seeing such a feature added to browsers, you should probably wait until you can discuss your use-cases publicly.

If you really don't want to wait, you could try privately approaching major browser implementers and explaining your use-cases to them.  Ian Hickson, the editor of HTML5, has been known to make decisions based on private feedback before when the feedback can't be publicly disclosed (e.g., on video codec patent issues).  However, I can't make any guarantees about how successful this approach would be.

Basically, the bottom line for this kind of feature is that if it's not obvious that it's a really good idea, you want to contact browser implementers about it.  We mostly standardize stuff if and only if implementers want to implement it.  In my judgment, it's unlikely that any major browsers would be interested in implementing this feature based on the information you've provided.  If you're able to prove me wrong, feel free.

(In reply to comment #5)
> I should point out that according to this blog post, about 1% of Chrome (Linux)
> users don't have the ability to resolve arbitrary DNS record types, due to
> firewalls and so on:
> 
> http://www.imperialviolet.org/2011/06/16/dnssecchrome.html
> 
> This would be a significant impediment to the usability of any sort of general
> DNS querying service from web browsers.  New web browser-based protocols, like
> SPDY or WebSockets, normally have to either use TLS or masquerade as HTTP to
> ensure that they're usable even behind firewalls.  So again, strong use-cases
> would be needed that demonstrate that DNS is really the right way to solve this
> before it could be seriously considered.

I'm not too worried about that ~1%, because applications should simply fall back to a (slower) HTTP request when DNS is unavailable - it's trivial for a server to proxy a DNS request/response to the client through JSON, or whatever.

> Discussion in #whatwg today suggests that it's unlikely that would be enough. 
> Private networks might also be using public IP ranges and relying on firewalls
> to protect them.  We don't know whether there will be security consequences or
> not, but if there are, we'll probably only figure out long after the feature is
> widely used, so that we can't fix it.  This has happened before in the history
> of the web and provides recurring security headaches to this day -- e.g.,
> information leakage through embedding cross-origin images.  We don't want to
> risk it for the future.

After having thought about it I've realised that some private nameservers will contain confidential information, e.g. about internal network topology, so you were right to recognise this as an issue.

> The way AJAX and so on work these days is that they're same-origin by default,
> but origins can opt in to allowing cross-origin requests using CORS.  If
> there's a strong use-case for allowing DNS queries of this sort, a similar
> solution could be devised, like a special DNS record that would allow browsers
> cross-origin access.

This seems like it could be a neat solution. We could predicate that a zone MUST contain a (TXT?) record to explicitly allow cross-origin requests, the result of which could be cached by the browser (using the record's TTL if it exists, or a minimum default of something like 5 minutes if it doesn't exist).

I'm specifically interested in the .tel TLD - clients could whitelist this and skip the cross-origin check, since it's not relevant.

> Unfortunately, it's unlikely anyone will be interested in implementing an API
> like this in a major web browser on that basis.  There are potential security
> issues, and the possibility that it won't work for a significant minority of
> users, plus it's not at all a trivial feature to spec or implement.  If you or
> your employer is interested in seeing such a feature added to browsers, you
> should probably wait until you can discuss your use-cases publicly.

Yeah, it's difficult to seriously demonstrate demand until there are some real world applications being used by lots of people, but hopefully it won't be too long before I can put forward a stronger case.

Without commenting on whether the suggestion here is a good one or not, it's not in scope for the Web Sockets API, which is just about exposing the Web Sockets protocol. If you want a DNS API at the W3C, you should propose it to the working group.

If you want the WHATWG to work on such an API, please see this FAQ entry:
http://wiki.whatwg.org/wiki/FAQ#Is_there_a_process_for_adding_new_features_to_a_specification.3F
(The same steps would also help on the W3C side, in practice.)