name resolve takes exactly 1 minute and loses cache after 30 seconds

[markg85]

Hi,

The obligatory version information:

Initializing daemon...
go-ipfs version: 0.4.22-4e981576b-dirty
Repo version: 7
System version: amd64/linux
Golang version: go1.12.8

Swarm listening on /ip4/10.0.3.73/tcp/4001
Swarm listening on /ip4/127.0.0.1/tcp/4001
Swarm listening on /ip4/172.17.0.1/tcp/4001
Swarm listening on /ip4/172.18.0.1/tcp/4001
Swarm listening on /ip6/::1/tcp/4001
Swarm listening on /p2p-circuit
Swarm announcing /ip4/10.0.3.73/tcp/4001
Swarm announcing /ip4/127.0.0.1/tcp/4001
Swarm announcing /ip4/172.17.0.1/tcp/4001
Swarm announcing /ip4/172.18.0.1/tcp/4001
Swarm announcing /ip6/::1/tcp/4001
API server listening on /ip4/127.0.0.1/tcp/5001
WebUI: http://127.0.0.1:5001/webui
Gateway (readonly) server listening on /ip4/127.0.0.1/tcp/8080
Daemon is ready

Now this site is a playground site with only pinata and a digitalocean server backing it. The timing of a resolve:

# time ipfs name resolve torgui.sc2.nl
/ipfs/QmYFXckSVjKAamyykdfik9bcQvLNVn6eAkqBn9pwgCoVFh
ipfs name resolve torgui.sc2.nl  0.01s user 0.01s system 0% cpu 1:00.03 total

Right after that resolve it works fast for, say, about 30 seconds or so.
Then it again needs to resolve and, and this really surprises me, takes again exactly 1 minute!
See:

# time ipfs name resolve torgui.sc2.nl
/ipfs/QmYFXckSVjKAamyykdfik9bcQvLNVn6eAkqBn9pwgCoVFh
ipfs name resolve torgui.sc2.nl  0.01s user 0.01s system 0% cpu 1:00.03 total

You'd think i copied and pasted the two timings from above, but they were really this EXACT in time.

That's no coincidence!
Something somewhere in the IPFS code that does name resolving is set at 1 minute. Or there are some timers or delays adding up to a total of 1 minute sharp.

I don't think my DNS record is wrong.

# dig txt +short torgui.sc2.nl        
"dnslink=/ipns/QmcxMK1fsQv4vLdbatNXFR21b6eDbfWaUyHrFTgJ5SHS8v"

I think there are 2 issues here.

1. The resolve takes exactly 1 minute.
2. It loses the result of the resolve in ~30 seconds and that too is consistent. I'm guessing some garbage collection kicking in.

Is there any additional information that i can provide to help tracking this?

Cheers,
Mark

To amend, this has likely been reported a lot before. I couldn't find github issues, but did find this thread on the forum: https://discuss.ipfs.io/t/why-ipns-is-so-slow/2161

[dirkmc]

Hi Mark,
Thank you for taking the time to fill out a detailed bug report.

At the moment IPNS is quite slow, because there are some issues with the IPFS DHT. Basically what's happening is that it tries to fetch a certain minimum number of records from the DHT but times out (after one minute) before it's able to get all of them, so it returns the best of the records that it was able to find.

There are some suggested work-arounds in this thread.

The good news is that we are very actively working on fixing the DHT slowness, and expecting a release candidate in the next few weeks that should improve things a lot.

You can track our progress in this issue