Run DNS lookup for --api endpoint provided in CLI

[raulk]

This is my first PR to go-ipfs, so please be gentle ;-)

Imports go-multiaddr-dns and calls madns.Resolve() with the provided multiaddr. There's no need to call Matches() explicitly, as the resolution will do no-op if no DNS protocols are found in the input multiaddr (I'm assuming this is part of the contract of madns.Resolve()).

If multiple results are returned, only the first one is used. See #5249 (comment).

I've added several unit tests in the dnsresolve_test.go file. Not sure if that's the best place. I'm happy to change it.

I initially added the call to madns.Resolve() in apiClientForAddr() but I couldn't assert on the address of http.Client as its private, so I had to put it in a separate function to enable unit testing.

Fixes #5249.

[Stebalien]

Nice! We usually don't bother unit testing small helper functions like that but that's just because we're horrible, lazy coders so I definitely won't say no to it.

Mind adding an integration test? You can find the others in test/sharness. Basically, all we need to do is start an ipfs daemon test_init_ipfs and test_launch_ipfs_daemon, test that ipfs --api=/dns4/localhost/tcp/5001 SOMETHINGworks, and then stop the daemon withtest_kill_ipfs_daemon`.

[raulk]

@Stebalien – added a sharness test, modelled after t0235.

Only testing the appearance of the POST, which is enough to assert that the DNS resolution is happening.

Had to use an existing domain that resolves to 127.0.0.1, localtest.me, as the kernel resolves localhost through /etc/hosts, not a DNS lookup.

[Stebalien]

Had to use an existing domain that resolves to 127.0.0.1, localtest.me, as the kernel resolves localhost through /etc/hosts, not a DNS lookup.

Actually, I'd much rather use localhost. That way the tests pass while offline (e.g., when on a plane). Really, we don't care about actually using DNS, we just want to hit the multiaddr-dns resolver.

[Stebalien]

(figured I might as well just fix that rather than make you do yet another round of CR).

Rebased and probably ready...

[raulk]

Thanks @Stebalien, somehow I had missed this.

I had wrongly assumed that net.Resolver.LookupIPAddr() behaved like nslookup, which does not resolve localhost because it goes straight to the nameservers. However, LookupIPAddr() does resolve localhost properly as it goes via the kernel.

All good, thanks 👍