Support .nodeAddress() for /dnsaddr

[hacdias]

@jacobheun Are there any plans to support conversion to a node address from a dns addr? If so, I can take a stab at it and open a PR. If not, why? Should it be done in some other package?

I also wonder since we would need to check the DNS records if it would need to be async or not. Surely we could keep the API sync.

[jacobheun]

@hacdias we should add it, it looks like it just wasn't added to the nodeAddress list when it was added. Ideally I think we'd have some type of resolver in the protocol table instead of it being hard coded in the nodeAddress function so protocols are less likely to get missed in the future.

I also wonder since we would need to check the DNS records if it would need to be async or not. Surely we could keep the API sync.

What do we need to do this for? IIRC the existing transports are handling the dns resolution. .resolve does need to get implemented at some point, I'm just not sure on the priority, and that will need to be an async function. That should be the function that handles any lookup for protocols in the table that are marked as resolvable

[hacdias]

Hmm... as far as I understood, we need to resolve the /dnsaddr/example.com to be able to return something acceptable for nodeAddress since dnsaddr is a TXT record in the DNS on example.com domain. Please correct me if I'm wrong.

[jacobheun]

Ah yes, you're right, we need to resolve the TXT record.

We'll need to implement resolve so we can get the updated addresses and then perform nodeAddress on those.

It might be good to do some level of cacheing so we don't need to resolve the address frequently. We can't do a replace after the resolve as the TXT records are mutable, so we need to keep a record of the original address. But the cacheing is probably something that should be handled in PeerBook/PeerInfo anyway.

[richardschneider]

Since its DNS, the TXT record will provide a TTL. A good DNS client should do the caching for us.

[lidel]

The way I see it:

1. Add .resolve method to multiaddr instances (returns self by default)
2. Decide what whappens when .nodeAddress() is called on unresolved /dnsaddr (undefined ? throw?)

[jacobheun]

what to return when .nodeAddress() is called on /dnsaddr? undefined ?

I would expect this to throw an error, as it needs to be resolved. The addresses we get from .resolve() should be used to perform .nodeAddress().

We should really be performing resolution on any resolvable address we learn about before attempting to connect, and then using the resolved addresses to do the connecting.

[hacdias]

I could take a look at this effort. Is there anything else that should be done other than adding .resolve() on this package? I'll certain have a few questions during the process though.

[jacobheun]

Is there anything else that should be done other than adding .resolve() on this package?

That should be sufficient. Libp2p will need to get updated to do resolutions as part of the dialing and/or peer discovery pipeline.

While I don't think it's necessary for this iteration, we should keep in mind that in the future we may need different resolvers per address type.

[olizilla]

This is blocking js-ipfs from making use of the new bootstrappers see ipfs/js-ipfs#2581

@hacdias did you get anywhere with it? Will you pick it up again?

[hacdias]

@olizilla probably not and I haven't made any further progress on this one... :'(

[vasco-santos]

From my understanding after reading this and discuss a little bit with @jacobheun , we want the following:

• Support custom resolvers per codec
• Each resolver should be responsible for caching its data
• .nodeAddress() should throw if a dnsaddr multiaddr was not resolved (only case?)

This will unblock dnsaddr multiaddr to be resolved using a dns resolver, as well as other cases that might appear.

Moreover, we need a resolver for dnsaddr. The challenging part is resolving it in a browser context