Implement DNS query API

[lidel]

Background

The /api/v0/dns/ API was created in go-ipfs as a workaround for doing dnslink lookups in webpage and browser addon contexts (ipfs/kubo#1054, ipfs/ipfs-companion#44).

Problem

Mozilla bug #1343849 means we won't have a native WebExtension API for DNS TXT lookups. Even if Mozilla decides to add a custom API for this to Firefox, it won't be present in Chromium-based browsers.

Our long term goal is to have an option to run js-ipfs node in WebExtension (ipfs/ipfs-companion#248) without relying on external HTTP Gateway provided bygo-ipfs.

Solution

We need a robust, portable DNS lookup solution that works everywhere. This means js-ipfs needs to provide in-house implementation for /api/v0/dns/ that works in "browserified" version. We won't be able to support dnslink in web browsers without it.

Request-Response Examples

DNS lookup API is already implemented by go-ipfs (ipfs/kubo#1054):

Site with dnslink:

GET http://localhost:5001/api/v0/dns/ipfs.io

{"Path":"/ipfs/QmbB5He9XBy7TpsuEwF8twUA2FvK4x8DTUjsANVaQAPDDh"}

Site without dnslink in TXT record:

GET http://localhost:5001/api/v0/dns/google.com:

{"Message":"could not resolve name.","Code":0}

Other thoughts

• time-bound LRU cache could be used within js-ipfs to improve performance of multiple API requests asking for the same domain in short period of time,
• if done, js-ipfs-api should provide support for this API (Support for /api/v0/dns/ ipfs-inactive/js-ipfs-http-client#501).

[lidel]

I want to emphasize that DNS TXT lookup needs to work in "browserified" version of js-ipfs.
Is it even technically feasible?

[daviddias]

Thanks for opening this up, @lidel :)

I want to emphasize that DNS TXT lookup needs to work in "browserified" version of js-ipfs.
Is it even technically feasible?

I think that the answer is no and you provided the answer on your first comment #904 (comment)

We can implement this in the Node.js only version.

[lidel]

Hm.. that is unfortunate 🙃

Perhaps we could fallback to HTTP-based queries when in browser contexts?

• The Public Gateway already provides DNS-over-HTTPS service: https://ipfs.io/api/v0/dns/ipfs.io
• There is also Google's DNS-over-HTTPS: https://dns.google.com/resolve?name=ipfs.io&type=TXT

The question remains: should this fallback be hidden from API consumers and handled internally by js-ipfs, js-ipfs-api or is it something every client needs to anticipate and implement over and over again?

[daviddias]

@hacdias shipped this one! 👏🏽❤️🤘🏽 Thank you!