1449171 - Add DNS TXT resolution to dns.resolve WebExtensions API

Status: UNCONFIRMED

(WebExtensions :: Request Handling, enhancement, P5)

Description

[Marcin Rataj]

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:59.0) Gecko/20100101 Firefox/59.0
Build ID: 20180315233128

Steps to reproduce:

Mechanism for performing DNS lookups via the WebExtensions API has been added  recently[1] under dns.resolve[2].
Unfortunately it allows only for a lookup of A/AAAA records, which severely limits use cases for this DNS API.

TXT records are often used for publishing additional metadata in DNS
It may be PGP pubkeys, access-confirmation tokens, efficient shortening services and more. 
My personal interest is to use DNS TXT record lookup as a bridge between centralized and decentralized technologies. 
An example of this approach is TXT record with dnslink for IPFS[3]. 

Right now DNS TXT lookups need to be done over third-party HTTP APIs, which introduces significant overhead and introduces a vector for privacy leakage.

I propose an extension of this API to support lookups for DNS records other than A/AAAA, or at least just TXT ones.
It would enable extensions to do TXT lookups in efficient manner.

PS. I am aware there is 19 year old bug regarding SRV[4], but this is by no means a duplicate.
This bug is specific to (i) exposing lookup only via WebExtension API (ii) DNS TXT record, which proved to be more flexible than SRV

[1]. https://bugzilla.mozilla.org/show_bug.cgi?id=1373640
[2]. https://developer.mozilla.org/en-US/Add-ons/WebExtensions/API/dns
[3]. https://github.com/ipfs/go-dnslink#background
[4]. https://bugzilla.mozilla.org/show_bug.cgi?id=14328

Comment 1

[Shane Caraveo (:mixedpuppy)]

Not opposed to adding additional record types to the dns api, but that is going to require updates to the dnsservice (e.g. bug 14328 that you pointed out).  I don't see this becoming a priority for us, but contributions could be welcome.

Comment 2

[Caitlin Neiman [:caitmuenster]]

Hi Marcin, this has been added to the agenda for the WebExtensions APIs triage on April 10, 2018. Would you be able to join us? 

Here’s a quick overview of what to expect at the triage: 

* We normally spend 5 minutes per bug
* The more information in the bug, the better
* The goal of the triage is to give a general thumbs up or thumbs down on a proposal; we won't be going deep into implementation details

Relevant Links: 

* Wiki for the meeting: https://wiki.mozilla.org/WebExtensions/Triage#Next_Meeting
* Meeting agenda: https://docs.google.com/document/d/1cFcqNOLwp77aosh5QUeNKgW8FQONAzOBlqjbcbxdIXw/edit#
* Vision doc for WebExtensions: https://wiki.mozilla.org/WebExtensions/Vision

Comment 3

[Shane Caraveo (:mixedpuppy)]

I realize I put decision-needed, but I think we need an internal decision on this, since it requires low level work to be done first.

Comment 4

[Mike Conca [:mconca]]

I think what you are saying is that this isn't really a WebExtensions design decision; the DNS API will gladly support and expose it, but only if the underlying product implements it.  Bug 14328.

And implementing that bug is where the design decision is needed. Which is a different team.  I'd recommend we remove the design-decision-needed flag on this bug, keep it as P5, and make it dependent on bug 14328.  Once that lands (if it does), we can expose it via the existing DNS API.

Comment 5

[Shane Caraveo (:mixedpuppy)]

(In reply to Mike Conca [:mconca] (Denver, CO, USA UTC-6) from comment #4)
> I think what you are saying is that this isn't really a WebExtensions design
> decision; the DNS API will gladly support and expose it, but only if the
> underlying product implements it.  Bug 14328.

yep.

Comment 6

[Marcin Rataj]

I noticed that the behemoth Bug 14328 was closed as WONTFIX. 

What does this mean for proposed here support for TXT record lookups via browser.dns.resolve?
Does that decision make this feature easier (smaller number of dependencies) or harder (missing codepaths) to implement now?

If someone wants to contribute this feature, what would be first step?

Comment 7

[Andrew Swan [:aswan]]

(In reply to Marcin Rataj from comment #6)
> I noticed that the behemoth Bug 14328 was closed as WONTFIX. 
> 
> What does this mean for proposed here support for TXT record lookups via
> browser.dns.resolve?
> Does that decision make this feature easier (smaller number of dependencies)
> or harder (missing codepaths) to implement now?

I don't think it is related, that was about SRV records, not TXT records.

> If someone wants to contribute this feature, what would be first step?

Probably starting with the Necko team to see if they would be willing to maintain the client-side platform bits to handle TXT records.

Comment 8

[Daniel]

Would granting extension developers read-access to the network.trr.uri preference be enough?

Not sure any extension developer would want to deal with DNS wireformat (RFC1035) but at least they could send DNS queries to a user-configurable DNS-over-HTTPS service with a Mozilla guaranteed privacy-aware provider configured by default.

Comment 9

[Marcin Rataj]

Yes, read-access to network.trr.uri would be a small improvement (right now WebExtensions basically do DNS-over-thirdparty-HTTPS-provider).