Delegate resolution of DNSlink and IPNS records

[lidel]

Initial idea (for Feb 17 binary)

• For resolving /ipns/id content paths to /ipfs/cid ones
  • Delegate RPC at https://node[0-2].delegate.ipfs.io/api/v0/resolve (it handles both DNSlink and IPNS)
  • (TBD) if we need local cache per id to avoid sending lookup, we can do it in two stages:
    • naive mvp can be 1 minute LRU cache, matching current behavior in Kubo 0.18 (which we want to fix long term)
    • correct cache is based on record TTL, so we reuse resolution for subsequent requests
      • this may require us to switch away from /api/v0/resolve and handle IPNS and DNSLink separately
        • DNSLink: run own DNS lookup for TXT record, and cache based on TTL of TXT record
        • IPNS record: use /api/v0/routing/get and cache based on TTL of the IPNS record
• For resolving raw IPNS record
  • Delegate RPC at https://node[0-2].delegate.ipfs.io/api/v0/routing/get (cc @hacdias to confirm, I believe we already do this is tests)
• Ensure resolution is as fast as possible:
  • run IPNS over Pubsub and Accelerated dht client
  • have a caching DNS server set up or use reliable catch-all DoH endpoint for .

Long term, we want to use delegated HTTP routing for IPNS (follow-up for IPIP-337, when that API supports IPNS lookups), and DoH for DNSLink (https://github.com/libp2p/go-doh-resolver/ ?)

[hacdias]

@lidel I wonder if using the ?type=ipns-record couldn't also be an option so would not necessarily need to rely on the RPC API. Also, /api/v0/routing/get is not available on the delegate nodes, and relying on /api/v0/resolve would mean we fully trust the delegated nodes. I would prefer to run my own DNS lookup and have a way of fetching raw IPNS records I could cheaply verify myself.

[lidel]

@hacdias we won't have ?type=ipns-record because bifrost-gateway we will be the gateway that is supposed to implement it. We won't be running DHT client (no go-libp2p is hard requirement for bifrost-gateway binary atm), and we don't have IPIP specs or implementation for ipfs/someguy#15 yet, so the only option that works for Feb 17 deliverable is /api/v0/routing/get from preexisting delegates.

I filled https://github.com/protocol/bifrost-infra/issues/2327 to expose /api/v0/routing/get there, but if you have better idea lmk (i also don't like this, but don't see anything else that would work for 17th).

[BigLep]

Discussion/analysis of v0 api usage on ipfs.io was done here: https://www.notion.so/pl-strflt/API-v0-Distribution-9342e803ecee49619989427d62dd0f42

[lidel]

Done in #19