Content routing hint via DNS records

[Stebalien]

A common use-case for IPFS is to host websites using DNSLink. That is, /ipns/foo.com would resolve to /ipfs/Qm....

This is the perfect place to stash additional content routing information:

TXT provider=/p2p/QmProvider1
TXT provider=/p2p/QmProvider2

The tricky part is somehow feeding this information through to the right place in go-ipfs.

[moritonal]

So.. I do a hacky version of this in the gateway I'm writing.. it roughly say that if it finds a TXT dns record that looks like:

ipfsnode=["/ip4/142.93.42.95/tcp/4001/ipfs/QmcKptbruY57iSgQNasNB58R6t2tnaZj2PrUHoYk77ZGL9"]

Then it tells IPFS to connect to that peer before doing the next requests (for content which that node will likely have). It's very basic but it helps a lot. I'd agree doing it as part of the dnslink resolution phase would also be cool. Obvious downsides are things like the id changing.

[yiannisbot]

I believe the discussion here is related to libp2p/notes/issues/14 - especially the fact that this can be done at the gateway level.

[Stebalien]

Somewhat but they take very different approaches:

• This issue is about allowing deliberate content hints that can be interpreted by, for example, a gateway. It's not very peer-to-peer but gives us a good fallback while we search for alternative sources for some content.
• That issue is about automatically spreading content routing hints around the network.

[yiannisbot]

Sure, I got this difference, but apart from deliberately adding routing hints through DNSLinks, could we not also automatically add routing hints when we see a request for some content coming through the DNS resolver or the gateway? This second form of routing hints would have to expire after a while, depending on the "characteristic time" [1] [2] of the node's cache (i.e., how long we project that the content will stay in the node's cache).

[Stebalien]

request for some content coming through the DNS resolver

That gives us some believe that the user is looking for the content but not necessarily that they managed to find it. That's why libp2p/notes#14 uses bitswap.

the gateway?

That's what the bitswap issue is about, really.

---

But yeah, both of these are content-routing side-channels.

[lidel]

Note to self: I don't think we need to invent a new TXT record format.
Existing dnsaddr={multiaddr} would do just fine.

When DNSLink is resolved for a domain, IPFS node would check if dnsaddr exist for the domain, and use lookup result as additional provider discovery method.

[Stebalien]

I'd rather have a new format. I might want /dnsaddr/mydomain to point to my peer but /ipns/mydomain to fetch data from my pinning service.

[lidel]

Fair enough. But would records with provider= hint still reside on _dnslink subdomain?
I'd argue yes, because we already get TXT records for that, so no additional lookup is necessary to read those hints.

[Stebalien]

Yes. It's "part" of the dnslink record.