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 under dns.resolve. 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. 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, 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 . https://bugzilla.mozilla.org/show_bug.cgi?id=1373640 . https://developer.mozilla.org/en-US/Add-ons/WebExtensions/API/dns . https://github.com/ipfs/go-dnslink#background . https://bugzilla.mozilla.org/show_bug.cgi?id=14328
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.
Component: WebExtensions: Untriaged → WebExtensions: Request Handling
Priority: -- → P5
Severity: normal → enhancement
Whiteboard: [design-decision-needed] → [design-decision-needed][dns]
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
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.
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.
(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.
Depends on: 14328
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?
(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.
You need to log in before you can comment on or make changes to this bug.