- From: timeless <timeless@gmail.com>
- Date: Wed, 15 Jun 2011 23:32:11 -0400
- To: public-webapps <public-webapps@w3.org>
http://www.w3.org/Bugs/Public/show_bug.cgi?id=12965 > Summary: Problem: I want to perform DNS queries from a HTML5 > app, but the networking functions available are too > restrictive to build a stub resolver. Why: DNS is not > just for machines - zones may contain extremely useful > Comment: > Problem: I want to perform DNS queries from a HTML5 app, but the networking > functions available are too restrictive to build a stub resolver. > > Why: DNS is not just for machines - zones may contain extremely useful and > rich information for humans too, e.g. the .tel TLD was provisioned > specifically to publish contact information (i.e. URIs) as DNS records (i.e. > NAPTR, TXT, LOC), there's also e164.arpa, and perhaps further innovation will > happen at the DNS layer in the future. > > Solution: Define a DNS interface. Some computers live behind proxies which do not provide for client based dns lookups. instead a client tells the proxy "i would like to talk to <host>" or "i would like to get <url>" and the proxy says "here's a connection for <host>" or "here's the data for <url>". An API for doing DNS work will not work in such situations. What you will probably have is something that "usually works" but fails on any interesting corporate network, which is unfortunate. This is the general reason that DNS APIs aren't exposed. The other reason is that DNS can easily include private information and browsers aren't particularly good at understanding what is private and shouldn't be exposed to web apps. I just finished reading https://bugzilla.mozilla.org/show_bug.cgi?id=354493 the bug report is 5 years old and unfinished, the problem is much older. Once fixed, I'm pretty sure it still won't handle the proxy cases. We really aren't in a position to add more attack surfaces until browser vendors manage to clean up the current surfaces (especially including that bug).
Received on Thursday, 16 June 2011 03:32:40 UTC