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
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.
- 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 inmnc
ormanc
Closing this in favor of multiformats/multiaddr#22