Support and test /dns/

[lidel]

It seems that this library supports /dns4 and /dns6 but does not support /dns

Given that

• JS fix: support dns and dnsaddr js-multiaddr#253 is adding support for /dns/
• and it is a valid code present in both multiaddr/protocols.csv and multicodec/table.csv

i think we should add it here as well.

Resolution order

Reuse prior art from https://en.wikipedia.org/wiki/Happy_Eyeballs ?

[lidel]

@schomatis is this something you'd be interested in adding to your queue?

[schomatis]

Adding it to queue (but haven't seen it in depth), anyone in the community is welcome to take a look at this issue in the meanwhile but please flag it here.

[schomatis]

Reading the code now.

Officially assigning this to me now (though I don't have triage permissions here to mark it on the issue). If someone is working on this please flag it now.

[schomatis]

@lidel Reading the code, we seem to support the /dns/ protocol:

go-multiaddr-dns/resolve.go

Lines 150 to 191 in 0bad63d

	case dns4Protocol.Code, dns6Protocol.Code, dnsProtocol.Code:
	// The dns, dns4, and dns6 resolver simply resolves each
	// dns* component into an ipv4/ipv6 address.
	v4only := proto.Code == dns4Protocol.Code
	v6only := proto.Code == dns6Protocol.Code
	// XXX: Unfortunately, go does a pretty terrible job of
	// differentiating between IPv6 and IPv4. A v4-in-v6
	// AAAA record will _look_ like an A record to us and
	// there's nothing we can do about that.
	records, err := rslv.LookupIPAddr(ctx, value)
	if err != nil {
	return nil, err
	}
	// Convert each DNS record into a multiaddr. If the
	// protocol is dns4, throw away any IPv6 addresses. If
	// the protocol is dns6, throw away any IPv4 addresses.
	for _, r := range records {
	var (
	rmaddr ma.Multiaddr
	err error
	)
	ip4 := r.IP.To4()
	if ip4 == nil {
	if v4only {
	continue
	}
	rmaddr, err = ma.NewMultiaddr("/ip6/" + r.IP.String())
	} else {
	if v6only {
	continue
	}
	rmaddr, err = ma.NewMultiaddr("/ip4/" + ip4.String())
	}
	if err != nil {
	return nil, err
	}
	resolved = append(resolved, rmaddr)
	}

$ madns /dns6/example.com
/ip6/2606:2800:220:1:248:1893:25c8:1946

$ madns /dns4/example.com
/ip4/93.184.216.34

$ madns /dns/example.com
/ip4/93.184.216.34
/ip6/2606:2800:220:1:248:1893:25c8:1946

---

Could you first confirm if the above is what you were requesting? If it is then we can talk some extra documentation (madns /dns/example.com is not part of the command example) and testing, but I need to know first if I'm understanding the issue correctly (I'm new in IPFS/DNS world).

[schomatis]

(just a guess) Maybe we were experience problems because of:

go-multiaddr-dns/resolve.go

Lines 157 to 160 in 0bad63d

	// XXX: Unfortunately, go does a pretty terrible job of
	// differentiating between IPv6 and IPv4. A v4-in-v6
	// AAAA record will _look_ like an A record to us and
	// there's nothing we can do about that.

[lidel]

@schomatis i think the bug was caused by the line fixed here: https://github.com/libp2p/go-libp2p/pull/1612/files#diff-8a203f70505b8dae3ee69421aa2326392c2f301091f557e44649fa40205f246fR26

With Kubo 0.14 (which uses go-libp2p with the above fix) I was able to connect to /dns just fine:

$ ipfs swarm connect /dns/ipfs.thedisco.zone/tcp/4430/wss/p2p/12D3KooWCyiHXACQpZxnvLTHXjFcFPPv69qPrX6svgdcmREZuS8A
connect 12D3KooWCyiHXACQpZxnvLTHXjFcFPPv69qPrX6svgdcmREZuS8A success

Can you validate my assumptions here? If so, I think we can close this, right?

[schomatis]

the bug was caused by

I'm still not sure what's the original bug being referenced here. I get the general issue but I have the impression there was an issue downstream that motivated this which I'm missing (it could be some of the background you listed which I didn't review in depth).

ipfs swarm connect /dns/ipfs.thedisco.zone/tcp/4430/wss/p2p/12D3KooWCyiHXACQpZxnvLTHXjFcFPPv69qPrX6svgdcmREZuS8A

Yes, this works for me.

[lidel]

The original one is libp2p/go-libp2p-relay-daemon#18 – Kubo 0.12 failed to connect to /wss + /dns relays:

$ ipfs swarm connect /dns/ipfs.thedisco.zone/tcp/4430/wss/p2p/12D3KooWCyiHXACQpZxnvLTHXjFcFPPv69qPrX6svgdcmREZuS8A
error: connect 12D3KooWCyiHXACQpZxnvLTHXjFcFPPv69qPrX6svgdcmREZuS8A failure: no good addresses

Since /dns handling got fixed, Kubo 0.14 connects fine:

$ ipfs swarm connect /dns/ipfs.thedisco.zone/tcp/4430/wss/p2p/12D3KooWCyiHXACQpZxnvLTHXjFcFPPv69qPrX6svgdcmREZuS8A
connect 12D3KooWCyiHXACQpZxnvLTHXjFcFPPv69qPrX6svgdcmREZuS8A success

Since it is fixed upstream, I guess we can close this one?

[schomatis]

Yes, makes sense, closing.

[schomatis]

(@lidel sorry, this is not in ipfs, you'll need to pull the lever)