Support DNSLink on ENS (move namesys defaults out of Kubo)

[lidel]

Problem

bifrost-gateway must have feature and behavior parity with Kubo, but we have a bug around ENS:

• https://bifrost-gateway.ipfs.io/ipns/blog.almonit.eth fails because DNSLink can't be resolved
• https://ipfs.io/ipns/blog.almonit.eth (Kubo) works

Potential cause

Seems that we are running different namesys config than Kubo.

It should use the same set of defaultResolvers to support ENS and UD, as noted in the config docs, but *.eth resolution does not work atm.

Cleanup proposal

Move defaultResolvers to one of upstream libraries, and make them implicit default to avoid ENS failures like this one.

Option A: move to go-namesys (global)

• Move defaultResolvers from Kubo to https://github.com/ipfs/go-namesys
• Make namesys apply default resolvers by default

This applies defaults to both DNSLinks and Multiaddrs, allowing use of *.eth in /dnsaddr too

Option B: move to go-libipfs/gateway (minimal, scoped to DNSLinks)

• Move defaultResolvers from Kubo to https://github.com/ipfs/go-libipfs/tree/main/gateway
• feat: refactor gateway api to operate on higher level semantics ipfs/boxo#176 introduces WithNameSystem option for passing custom namesys – we could use that in bifrost-gateway to pass namesys with these additional resolvers, OR
• (optional) we could make the implicit namesys used in go-libipfs/gateway, so everyone using the library gets the same behavior

This would only apply to DNSLinks, but that is enough given the utility of ENS today (just DNSLinks).

---

@hacdias @aschmahmann Thoughts?

I feel (B) may be cleaner:

• WithNameSystem allows users to pass custom resolvers
• if no WithNameSystem is passed we apply defaultResolvers on the library level as implicit default

[hacdias]

@lidel I think the idea of moving to go-libipfs/gateway (approach B) is the best option to go, as it allows re-use without cluttering too much our other general packages (go-namesys).

[lidel]

@hacdias sgtm. do you prefer to do it as part of ipfs/kubo#9681 after?

[hacdias]

I think after would be better.

[hacdias]

@lidel I decided doing it during.