ipns public key resolution single point of failure

[kallisti5]

Checklist

• This is a bug report, not a question. Ask questions on discuss.ipfs.io.
• I have searched on the issue tracker for my bug.
• I am running the latest go-ipfs version or have an issue updating.

Installation method

ipfs-update or dist.ipfs.io

Version

ipfs version --all
go-ipfs version: 0.10.0-64b532fbb
Repo version: 11
System version: amd64/linux
Golang version: go1.17.4

Description

IPNS public key resolution is extremely failure prone.

Example:

• I have a node continuously publishing content to MFS
• Today, I have IPNS resolution configured as follows:
  • _dnslink.hpkg.haiku-os.org. 3170 IN TXT "dnslink=/ipns/k51qzi5uqu5dgnsdtttsbgsu7rbpky52k7lwi55mk8eywf2o0ds749syqiq6g9"
  • /ipns/k51qzi5uqu5dgnsdtttsbgsu7rbpky52k7lwi55mk8eywf2o0ds749syqiq6g9 -> /ipfs/current-CID
  • current-CID is obtained from the current MFS cid.

The problem is there is a single point of failure resolving content, no matter how many mirrors of /ipns/hpkg.haiku-os.org we have. As soon as the node which hosts the private/public ipns key for /ipns/k51qzi5uqu5dgnsdtttsbgsu7rbpky52k7lwi55mk8eywf2o0ds749syqiq6g9 does down, all content for hpkg.haiku-os.org becomes unavailable globally on all IPFS nodes.

I don't update _dnslink.hpkg.haiku-os.org to point directly to a CID since our content changes nightly and that would require updating external DNS records pretty much continuously.

It appears that almost no caching of ipns public key to CID mapping exists on the network?

[hsn10]

I think you can upload key to more machines and let them announce IPNS.

I don’t use ipns in DNS link, there are no advantages from adding less reliable ipns layer on top of ipfs cid in DNS.

[kallisti5]

I think you can upload key to more machines and let them announce IPNS.

I don't think it works like that? I mean, maybe you could independently upload the private key, and re-sign the ipns record... but wouldn't it potentially have a random public key based on your current private key?

I can't find any docs covering this stuff either.

I don’t use ipns in DNS link, there are no advantages from adding less reliable ipns layer on top of ipfs cid in DNS.

The advantage is content updates continuously, so the ipns record can be updated daily from the serving ipfs node with the MFS storage.

[Winterhuman]

@kallisti5 Having multiple nodes publish using the same private key isn't officially supported, there was an issue related to this, but I can't find it. However, the rest of the original issue is concerning.

IPNS Records, the key to CID mappings you mentioned, are supposed to be cached in nodes other than the node who holds the key; the IPNS Record is placed in the nodes whose PeerIDs are most similar to the IPNS key. But, your issue seems to be that the IPNS address just isn't resolving to these nodes, there are a few possibilties as to why that I can think of:

1. The IPNS publisher node isn't distributing the IPNS Record to others. This would be a bug. (Maybe test with IPNS-PubSub and see if it changes?)
2. IPNS Records are not being cached in nodes that are accessible, the DNSLink tries to resolve, but, no one can be found since they're all behind NATs or are otherwise offline. This is hard to avoid, but still a problem.
3. Nodes are not serving or keeping the IPNS Records they receive. This would be a bug, or, the nodes have cleared their cache and deleted the IPNS Record.

[aschmahmann]

The main/common IPNS issues are tracked in #7572. This one in particular is a duplicate of #3117 and is related to #4435.

If you have questions about discuss.ipfs.io is a better place as GitHub issues (especially when closed as this one will be since it appears to be a duplicate) are not great for discovery.

Some brief notes though:

As soon as the node which hosts the private/public ipns key for /ipns/k51qzi5uqu5dgnsdtttsbgsu7rbpky52k7lwi55mk8eywf2o0ds749syqiq6g9 does down

It appears that almost no caching of ipns public key to CID mapping exists on the network?

The IPNS records are cached in the DHT for around a day, but then someone needs to republish them. The records can be republished by anyone (e.g. ipfs dht put on a record you got with ipfs dht get, go-ipfs should have better tooling for this (tracked in the linked issues) but it's already doable today.

Having multiple nodes publish using the same private key isn't officially supported, there was an issue related to this, but I can't find it.

Correct, there are some issues around races from multiple peers publishing both in the implementation and theoretically (#5816 (comment)). However, you can keep the record alive without having the private key by just republishing the existing record to the DHT. It does come with some tradeoffs around record longevity though. For example, the longer a record's lifetime is the longer the author can be offline, but since IPNS is partition tolerant a longer record lifetime makes it possible for you to be in a partition and receive an old record as the newest one available and still accept it. Depending on the criticality of updates this may/may not be a problem for a particular IPNS user. This is effectively the CAP Theorem.

If you've got more questions happy to discuss this more on discuss.ipfs.io though.