multiformats/go-multiaddr

Support DNS

jbenet opened this issue · 17 comments

Multiaddrs like these should work:

/dns/ipfs.io
/dns/foo.bar.com/http

This format in ambiguous regarding IPv4/IPv6. Other options:

/ip4/ipfs.io
/dns6/foo.net
/dnsAAAA/bar.com
/dns/baz.org/ip4

All of these would roughly resolve to /ip4/1.2.3.4 and /ip6/123::4. The last one has the most appeal imo.

also, which record? just A? or allow TXT to work too:

/dns/baz.org/

vs

/dns/baz.org/a/
/dns/baz.org/txt/

(hard to do defaults...)

(update: ahh i see you mentioned dnsAAAA too)

i like /dns/baz.org/ip4 though that's a bit tricky.

maybe:

/dns/baz.org/ip   # either 4 or 6
/dns/baz.org/ip4  # ipv4
/dns/baz.org/ip4  # ipv6

maybe:

/dns/baz.org/ip   # either 4 or 6
/dns/baz.org/ip4  # ipv4
/dns/baz.org/ip4  # ipv6

yeah that's what i was after :)

A full example:

/dns/bootstrap1.ipfs.io/ip4/tcp/4001/ipfs/QmaCpDMGvV2BGHeYERUEnRQAwe3N8SzbUtfsmvsqQLuvuJ

It'd break with the quasi-rule that a protocol is a 2-tuple, but we can say that you MUST know how many segments follow once you see the first one -- e.g. you see /dns, and know there will be two more segments.

@lgierth that sounds good to me

It'd break with the quasi-rule that a protocol is a 2-tuple, but we can say that you MUST know how many segments follow once you see the first one -- e.g. you see /dns, and know there will be two more segments.

Yep, i think that's fine too (deterministic)

i also havent seen other multiaddr impls, so easy to change for us

@lgierth we should probably support record types here.

/dns/bootstrap1.ipfs.io/A/ip4

?

Do you mean for SRV/TXT/etc. records? Cause A and AAAA always implicate ip4/ip6.

ah right 👍

Some comment i got by email is missing. for posterity:

I want to extend go-multiaddr and go-multiaddr-net to support dialing to /dns/baz.org/ws/80 and listening on /ip4/12.45.56.78/ws/80. Should I use /dns/baz.org/ip/tcp/80/ws and /ip4/12.45.56.78/tcp/80/ws instead? Also, what protocol codes you'd recommend for dns, ws and ip?

Yes you should use the /tcp/80/ws version instead.

That's my comment. Thought it was a little off topic so I deleted it 🐰

But since you mention it, I'll have you know that I got /dns/baz.org/tcp/4324 and /dns/baz.org/tcp/4324/ws/echo to work on my modest attempt to a pluggable manet, no /dns/baz.org/ip4 though, because you can't create those with this library.

no /dns/baz.org/ip4 though, because you can't create those with this library.

Yes we'll have to make a few changes to go-multiaddr, namely support for triplets, and some kind of resolution step that turns /dns/example.net/ip4 into /ip4/1.2.3.4

The problem with "resolving /dns/example.net/ip4 to /ip4/1.2.3.4 and be done with it" for me was that /ws needs to know the hostname to include in http request headers, otherwise cloud services refuse the connection. So those two addresses are not equivalent.

Your application code would be working with /dns addrs, while manet resolves these to /ip4 for internal use. Does that sound useful for your case?

Well, I have my case solved, it doesn't matter to me much. But I do like (and did in my reimplementation) manet to handle connection differences between /dns/example.net/tcp/80/ws/echo and /ip4/127.0.0.1/tcp/4324 internally and make them interchangable for the external user. It makes things like manetcat possible.

EDIT: I'm just trying to seduce you with the neatness of this, and saying that it's possible and available. Not asking for anything.

@Gaboose

  • very nice work with your manet fork
  • have you seen the pluggability that @whyrusleeping added in-- what are your thoughts?
  • Good work on manetcat i made something similar in https://github.com/multiformats/ma-pipe -- it still needs more work, but worth a look. maybe we should converge in mnc or manc

Closing this in favor of multiformats/multiaddr#22