Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
expose a DNS API (for MX, SRV) records, leave it to apps to use the TCP/UDP API, or leave it to servers via HTTP? (for e-mail app)
101 views
Skip to first unread message
Andrew Sutherland
Apr 12, 2012, 7:41:44 PM4/12/12
to dev-w...@lists.mozilla.org
For the e-mail app we are planning to reuse Thunderbird's
auto-configuration mechanism to facilitate account setup:
https://developer.mozilla.org/en/Thunderbird/Autoconfiguration
One of its heuristics after failing to find explicit autoconfiguration
directives for a domain is to look up the MX entry for the domain to
attempt to determine the hosting provider which may in turn have
configuration information available.
There are three main ways to accomplish this for the e-mail app:
1) Expose a Web API for DNS resolution capable of providing other record
types.
2) Have apps use the pending TCP API and/or a new UDP API to issue DNS
queries themselves. There is an MIT licensed node library that could be
used as a basis for this: https://github.com/tjfontaine/node-dns
3) Don't try and run the query on the client, but instead have a
(web)server do the query. Because of past and current Gecko platform
limitations, this is what Thunderbird does, but not what it wants to do
( https://bugzilla.mozilla.org/show_bug.cgi?id=563958 ). There is some
promising platform work happening to address the Gecko platform
limitation: https://bugzilla.mozilla.org/show_bug.cgi?id=735967
I understand from the bug traffic and elsewhere that XMPP clients would
also be interested in this functionality.
The main argument in favor of such an API is the ability of the platform
to eventually provide additional confidence in replies, such as
performing DNSSEC validation and/or being augmented to securely ask
other observers on the internet to confirm their lookups returned
similar-enough values.
Potential arguments against such an API are that DNS queries can be used
to leak information (ex: tcp-over-dns) and it might be hard to explain
the permission and do so without being confusing/annoying. Information
leakage would only be relevant in a tightly locked down execution model
where an app is running without meaningful network access or in an
attack where the attacker has managed to get some JS running in the
app's context but CSP/other policy makes it hard for the attacker to
exfiltrate the information to a server they control via easier means.
Andrew
auto-configuration mechanism to facilitate account setup:
https://developer.mozilla.org/en/Thunderbird/Autoconfiguration
One of its heuristics after failing to find explicit autoconfiguration
directives for a domain is to look up the MX entry for the domain to
attempt to determine the hosting provider which may in turn have
configuration information available.
There are three main ways to accomplish this for the e-mail app:
1) Expose a Web API for DNS resolution capable of providing other record
types.
2) Have apps use the pending TCP API and/or a new UDP API to issue DNS
queries themselves. There is an MIT licensed node library that could be
used as a basis for this: https://github.com/tjfontaine/node-dns
3) Don't try and run the query on the client, but instead have a
(web)server do the query. Because of past and current Gecko platform
limitations, this is what Thunderbird does, but not what it wants to do
( https://bugzilla.mozilla.org/show_bug.cgi?id=563958 ). There is some
promising platform work happening to address the Gecko platform
limitation: https://bugzilla.mozilla.org/show_bug.cgi?id=735967
I understand from the bug traffic and elsewhere that XMPP clients would
also be interested in this functionality.
The main argument in favor of such an API is the ability of the platform
to eventually provide additional confidence in replies, such as
performing DNSSEC validation and/or being augmented to securely ask
other observers on the internet to confirm their lookups returned
similar-enough values.
Potential arguments against such an API are that DNS queries can be used
to leak information (ex: tcp-over-dns) and it might be hard to explain
the permission and do so without being confusing/annoying. Information
leakage would only be relevant in a tightly locked down execution model
where an app is running without meaningful network access or in an
attack where the attacker has managed to get some JS running in the
app's context but CSP/other policy makes it hard for the attacker to
exfiltrate the information to a server they control via easier means.
Andrew
Andreas Gal
Apr 13, 2012, 12:12:35 AM4/13/12
to Andrew Sutherland, dev-w...@lists.mozilla.org
I think the UDP API sounds like the best path forward. Can you file a gecko bug?
Andreas
> dev-webapi mailing list
> dev-w...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-webapi
Andrew Sutherland
Apr 13, 2012, 3:32:31 PM4/13/12
to dev-w...@lists.mozilla.org
On 04/12/2012 09:12 PM, Andreas Gal wrote:
> I think the UDP API sounds like the best path forward. Can you file a gecko bug?
I filed https://bugzilla.mozilla.org/show_bug.cgi?id=745283 under
> I think the UDP API sounds like the best path forward. Can you file a gecko bug?
B2G/General which is where the TCP API (
https://bugzilla.mozilla.org/show_bug.cgi?id=733573 ) is currently
filed. (nsISocketTransportService already provides the ability to open
UDP sockets, so no platform work is required.) Should they both be in
Core/DOM: Device Interfaces instead? I also updated the wiki.
The one question this raises as it relates to DNS is how it figure out
what DNS server to talk to. Options include:
1) Use the DNS server the device is using:
1a) Have the UDP API itself expose a magic/synthetic name that is
automatically resolved to the first DNS server the device is using. This
could simplify permissions since we'd only need permission for the one
magical name. Of course, autoconfiguration will only happen a limited
number of times during short windows when it is unlikely the device's
effective DNS server will change. It is not immediately clear to me how
the API would find out the DNS server's name in a cross-platform
fashion. (/etc/resolv.conf is pretty straightforward on linux.)
1b) Get the list of DNS servers the device is using somehow. Our
existing network APIs do not appear to expose this information
currently. This may result in a lot more permission requests if the
device does not always use the same DNS server.
2) Hardcode use of a server, like Google's public DNS server
https://developers.google.com/speed/public-dns/ at 8.8.8.8 or 8.8.4.4.
3) The resolution logic should perform recursive lookup starting from
the root servers itself. This would be a nightmare permission-wise
unless we provide blanket UDP permissions.
Andrew
0 new messages