/dns in multiaddrs #22

jbenet · 2016-09-16T23:12:15Z

There's been some conversation on how to handle DNS, in these issues and others:

Finally looking back at this-- sorry for the delay everyone -- @sivachandran @lgierth @Gaboose and more. I am going to collect the options here and make a decision in coming weeks.

Proposals so far

So far, the proposals are:

Proposal 1: `/dns/<domain>/<proto>`

# format
/dns/<domain>/<proto> 

# example
/dns/example.com/ip4  --resolves-to-->  /ip4/1.2.3.4

Proposal 2: `/dns/<domain>/<record-type>`

# format
/dns/<domain>/<record-type> 

# possibilities / examples 
/dns/example.com/A     --resolves-to-->  /ip4/1.2.3.4
/dns/example.com/AAAA  --resolves-to-->  /ip6/1::1
/dns/example.com/CNAME --resolves-to-->  /dns/another.com/*
/dns/example.com/MX    --resolves-to-->  /dns/mail.another.com/* 
/dns/example.com/A     --resolves-to-->  /dns/another.com/A  (through a CNAME)
/dns/example.com/TXT   --resolves-to-->  /ipfs/QmZS2PeM6rtSJXPPSBiqyNRss3M1JpuNAkkQmzEWR7aw1w  (through a dnslink)

Other Questions

could we support both proposals?
are there other proposals?
can we come up with a long list of all the concrete example resolutions we want? (engineer to the use case)
maybe (for CNAME, MX, etc) we can return a multiaddr that is "either ip4 or ip6" or a "combination"?
what would just /dns/example.com mean? a list or combination? (1 -> many)

The text was updated successfully, but these errors were encountered:

progval · 2016-09-18T10:37:02Z

Other proposal: have both a modified version of proposal 1 (let's call it 1b) and proposal 2.

proposal 1b: /resolution/name/proto

/resolution/name/proto could be resolved to any resolution protocol, eg. DNS.

For instance, /resolution/example.com/ip6 --> /dns/example.com/AAAA --> /ip6/1::1

progval · 2016-09-18T10:48:14Z

Other issue: how to differentiate “IP over DNS” (it is possible) and “IP over address resolved via DNS”?

Both seem to be represented as /dns/example.org/ip6/127.0.0.1

EDIT: actually, I think the former would be represented as /dns/example.org/ip6/127.0.0.1, but the latter as /dns/example.org/ip6/ip6/127.0.0.1 (prop 1) or /dns/example.org/aaaa/ip6/127.0.0.1 (prop 2)

progval · 2016-09-18T10:56:51Z

Proposal 3 (to be combined with either 1 or 2): Add address nesting to multiaddr.

This would allow more flexibility in the protocols used for resolution

Example:

/ip4/[/ip4/127.0.0.1/https/dns/example.com/aaaa]/tcp/443    -->    ip4/1.2.3.4/tcp/443
      \                                       /
               this is DNS over HTTPS

jbenet · 2016-09-18T23:57:16Z

nesting is an interesting idea we've discussed before without resolution.
There should be a separate issue tracking it.
but [ ] are unsafe characters. They may be used in addresses themselves
what is /resolution/... ? Looks like you just mean dns.
If you somehow mean that the DNS namespace is special/obvious and doesn't
need to be namespaced under /dns/... I disagree. It's not special or
obvious.
your ordering of https is backwards, https should come at the end
On Sun, Sep 18, 2016 at 6:56 PM Valentin Lorentz notifications@github.com
wrote:

Proposal 3 (to be combined with either 1 or 2): Add address nesting to
multiaddr.

This would allow more flexibility in the protocols used for resolution

Example:

ip4/[/https/127.0.0.1/dns/example.com/aaaa]/tcp/443 http://127.0.0.1/dns/example.com/aaaa%5D/tcp/443 --> ip4/1.2.3.4/tcp/443
\ /
this is DNS over HTTPS

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
#22 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAIcodV1WxJl1qC_QiDCrZYGPxhbCBP1ks5qrRj0gaJpZM4J_bQt
.

progval · 2016-09-19T15:32:28Z

what is /resolution/... ? Looks like you just mean dns.

Any name resolution system. DNS, /etc/hosts, namecoin, ...

If you somehow mean that the DNS namespace is special/obvious and doesn't need to be namespaced under /dns/...

I don't

your ordering of https is backwards, https should come at the end

fixed

ghost · 2016-11-02T02:04:15Z

I'll get to writing up a proposal and code in the next 3 weeks.

ghost · 2016-12-19T16:49:31Z

/dns in multiaddrs

We had a very productive call about /dns and /tls multiaddrs a while ago, here's the results.
For both /dns and /tls we want to with the simplest options that could possibly work.
These options also must not be in the way of expanding this in the future.

Comments on proposal 1:
- It specifies record types in terms of multiaddr protocols (ip4, ip6) which is GOOD.
- It has 3 segments. This is not a problem in itself, but complicates implementation and adoption,
  since there's tons of code that just blindly assumes multiaddr protocols always have 2 segments.
Comments on proposal 2:
- Has 3 segments too.
- Couples multiaddrs to DNS implementation details (record types).
- Includes unneccessary record types.

The plan

Based on proposal 3 which was brought up in the call.

Plain and simple: /dns/example.com
Multiaddrs will get Resolve() method which returns a list of resolved multiaddrs,
e.g. Multiaddr("/dns/example.com/tcp/4001").Resolve() returns
[]string{Multiaddr("/ip4/1.2.3.4/tcp/4001"), Multiaddr("/ip6/1:2:3:4::/tcp/4001")}.
Some part within the libp2p stack will decide which of the resolved addresses are usable.
- Based on which listeners and dialers are available.
- Based on the Happy Eyeballs algorithm (RFC 6555).
The domain name should be subject to go-is-domain,
which should get regex-based check in addition to the check based on the ICANN TLD list.

We'll tag this new multiaddr protocol as /dns-3 for now, and once it stabilizes promote it to /dns.

In addition to /dns, we could add two more protocols /dns4 and /dns6,
which are explicit about the protocol of the to-be-resolved address, and make
decisions based on listeners/dialers or RFC 6555 unneccessary.

Issues down the road:

Can't currently combine round-robin DNS with /ipfs multiaddrs,
since these contain the PeerID which is unique per host.
We could do something certificate-chain-like and have the node's key
signed by the key corresponding to the given PeerID.

Modification to the plan: we've started doing /dns4 and /dns6 instead of /dns. They yield /ip4 or /ip6 addresses respectively, instead of both /ip4 and /ip6. This helps in unambiguously addressing and endpoint.

We're also not doing experimental protocol names, to avoid the mistake of the various X- HTTP headers.

Also add a fourth column, for comments. - We'll be using the experimental /dns-exp protocol for now, as per #22. Once we're sure it's right, we'll make it into /dns. - Same procedure for /relay, where in addition to the semantics, we're not even sure about the name. - /wss on the other hand is pretty straightforward.

daviddias · 2017-01-18T09:24:50Z

Linking ipfs/team-mgmt#102, which has the notes from that discussion: https://hackmd.io/KbAcFYGYEME4AYC0BjALAMwEyI9YjYAjebVARgHZR5x1VoA2C2IA#

Also add a fourth column, for comments. - We'll be using the experimental /dns-exp protocol for now, as per #22. Once we're sure it's right, we'll make it into /dns. - Same procedure for /relay, where in addition to the semantics, we're not even sure about the name. - /wss on the other hand is pretty straightforward.

ghost · 2017-01-25T01:13:55Z

Modification to the plan: we've started doing /dns4 and /dns6 instead of /dns. They yield /ip4 or /ip6 addresses respectively, instead of both /ip4 and /ip6. This helps in unambiguously addressing and endpoint.

We're also not doing experimental protocol names, to avoid the mistake of the various X- HTTP headers.

kpcyrd · 2017-02-01T14:51:52Z

A quick question (as it's probably worth defining this), does /dns respect nsswitch? This way we would get support for /etc/hosts and a bunch of other resolution techniques.

ghost · 2017-02-01T15:02:19Z

That'd be an implementation detail, but most will probably just defer to the system for name resolution. In the browser, it defers to the browser and never actually gets to see an /ip4 address.

Thanks, should write down that implementations SHOULD defer to the system, but MAY come up with their own way of resolving names.

Nemo157 · 2017-02-15T08:45:24Z

I haven't looked through the linked discussions yet, but have SRV records been brought up at all, or is this all based off using A/AAAA records only?

olizilla · 2018-11-09T10:37:31Z

Without a /dns protocol in multiaddr it's not possible to convert from a URL with a domain name in it to a multiaddr without DNS requests to determine if it's of type dns4 or dns6. In the browser, I'd like to be able to convert window.location.origin to a multiaddr like:

Multiaddr.fromUrl(window.location.origin) // e.g https://github.com
// /dns/github.com/tcp/443/https ?

per multiformats/multiaddr#22 (comment)

Stebalien · 2019-07-09T20:32:33Z

Implementation of /dns in go: multiformats/go-multiaddr-dns#17. I did this as we already have to resolve to multiple addresses so this hardly makes the situation any worse. Objections/thoughts?

ntninja · 2019-07-09T22:35:33Z

👍

py-multiaddr already encodes it like the other DNS types: https://github.com/multiformats/py-multiaddr/blob/master/multiaddr/protocols.py#L130
py-ipfs-http-client resolves it as such: https://github.com/ipfs/py-ipfs-api/blob/master/ipfshttpclient/http.py#L168-L206 (Yes, this is my fault, but it's part of the API now. 😉)

OT:

What's the binary encoding for DNS addresses? py-multiaddr encodes them as IDNA, but I'm not sure that's interoperable with other implementations?
Could somebody with the required privileges finally rename the py-ipfs-http-client repo?

Stebalien · 2019-07-09T22:47:54Z

What's the binary encoding for DNS addresses? py-multiaddr encodes them as IDNA, but I'm not sure that's interoperable with other implementations?

I think the answer is "none". Could you file a new issue for domain name encoding, that's a question we need to answer.

Could somebody with the required privileges finally rename the py-ipfs-http-client repo?

Done (please bug me on #ipfs-dev if something like that falls through the cracks).

Stebalien · 2019-07-09T22:51:21Z

Also, it looks like the "dns4 and dns6 only" resolution was just a go thing. JS also supports dns.

ntninja · 2019-07-09T22:52:00Z

What's the binary encoding for DNS addresses? py-multiaddr encodes them as IDNA, but I'm not sure that's interoperable with other implementations?
I think the answer is "none". Could you file a new issue for domain name encoding, that's a question we need to answer.

Will do this.

Could somebody with the required privileges finally rename the py-ipfs-http-client repo?

Done (please bug me on #ipfs-dev if something like that falls through the cracks).

Will remember that in the future. Thanks for finally fixing this!

ntninja · 2019-08-11T22:22:51Z

see #100 for a spec fix

This is a defacto standard and is used by js-libp2p. Ported from multiformats/go-multiaddr-dns#17. This was decided in multiformats/multiaddr#22.

per multiformats/multiaddr#22 (comment)

Ericson2314 · 2020-07-15T21:17:05Z

I haven't looked through the linked discussions yet, but have SRV records been brought up at all, or is this all based off using A/AAAA records only?

I too am interested in SRV records. Are records besides A and AAAA decidedly out of scope, or just deemed lower priority and left for the future with the "proposal 3" that was chosen above and since implemented?

Edited README

daviddias added the js-ipfs-backlog label Sep 26, 2016

ghost self-assigned this Nov 2, 2016

ghost mentioned this issue Nov 2, 2016

Support DNS multiformats/go-multiaddr#7

Closed

ghost changed the title ~~Adding DNS to Multiaddr~~ /dns in multiaddrs Dec 19, 2016

ghost mentioned this issue Jan 2, 2017

multiaddr design discussion ipfs/team-mgmt#102

Closed

ghost mentioned this issue Jan 17, 2017

Add /dns, /wss, /relay, /p2p protocol codes #34

Merged

daviddias mentioned this issue Jan 18, 2017

Implementation of DNS Support multiformats/js-multiaddr#37

Closed

18 tasks

daviddias mentioned this issue Jan 20, 2017

Sprint: Browser accesses go-ipfs content ipfs/team-mgmt#310

Closed

50 tasks

olizilla mentioned this issue Nov 22, 2018

feat: use jsipfs as fallback instead of public gateways ipfs-shipyard/ipfs-share-files#44

Merged

olizilla mentioned this issue Jan 24, 2019

fix: assume dns4 for domain names multiformats/js-uri-to-multiaddr#2

Merged

Stebalien added a commit to multiformats/go-multiaddr-dns that referenced this issue Jul 9, 2019

add plain dns support

3362f75

per multiformats/multiaddr#22 (comment)

Stebalien added a commit to multiformats/go-multiaddr-dns that referenced this issue Jul 9, 2019

add plain dns support

885da41

per multiformats/multiaddr#22 (comment)

Stebalien added a commit to multiformats/go-multiaddr-dns that referenced this issue Jul 9, 2019

add plain dns support

835ae1f

per multiformats/multiaddr#22 (comment)

ntninja mentioned this issue Jul 9, 2019

DNS name binary encoding #94

Closed

ntninja mentioned this issue Aug 11, 2019

/dns has had a defacto standard meaning for years #100

Merged

Stebalien closed this as completed Aug 12, 2019

Stebalien added a commit to multiformats/go-multiaddr that referenced this issue Sep 19, 2019

feat: add dns support

a088a4a

This is a defacto standard and is used by js-libp2p. Ported from multiformats/go-multiaddr-dns#17. This was decided in multiformats/multiaddr#22.

Stebalien mentioned this issue Sep 19, 2019

feat: add dns support multiformats/go-multiaddr#113

Merged

Stebalien added a commit to multiformats/go-multiaddr-dns that referenced this issue Sep 19, 2019

add plain dns support

8c560f5

per multiformats/multiaddr#22 (comment)

Jorropo pushed a commit to Jorropo/multiaddr that referenced this issue Dec 4, 2021

Merge pull request multiformats#22 from multiformats/feat/readme

e4f63fc

Edited README

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

/dns in multiaddrs #22

/dns in multiaddrs #22

jbenet commented Sep 16, 2016

progval commented Sep 18, 2016 •

edited

Loading

progval commented Sep 18, 2016 •

edited

Loading

progval commented Sep 18, 2016 •

edited

Loading

jbenet commented Sep 18, 2016

progval commented Sep 19, 2016 •

edited

Loading

ghost commented Nov 2, 2016

ghost commented Dec 19, 2016 •

edited by ghost

Loading

daviddias commented Jan 18, 2017

ghost commented Jan 25, 2017

kpcyrd commented Feb 1, 2017

ghost commented Feb 1, 2017

Nemo157 commented Feb 15, 2017

olizilla commented Nov 9, 2018

Stebalien commented Jul 9, 2019

ntninja commented Jul 9, 2019

Stebalien commented Jul 9, 2019

Stebalien commented Jul 9, 2019 •

edited

Loading

ntninja commented Jul 9, 2019

ntninja commented Aug 11, 2019

Ericson2314 commented Jul 15, 2020

/dns in multiaddrs #22

/dns in multiaddrs #22

Comments

jbenet commented Sep 16, 2016

Proposals so far

Proposal 1: /dns/<domain>/<proto>

Proposal 2: /dns/<domain>/<record-type>

Other Questions

progval commented Sep 18, 2016 • edited Loading

progval commented Sep 18, 2016 • edited Loading

progval commented Sep 18, 2016 • edited Loading

jbenet commented Sep 18, 2016

progval commented Sep 19, 2016 • edited Loading

ghost commented Nov 2, 2016

ghost commented Dec 19, 2016 • edited by ghost Loading

/dns in multiaddrs

The plan

daviddias commented Jan 18, 2017

ghost commented Jan 25, 2017

kpcyrd commented Feb 1, 2017

ghost commented Feb 1, 2017

Nemo157 commented Feb 15, 2017

olizilla commented Nov 9, 2018

Stebalien commented Jul 9, 2019

ntninja commented Jul 9, 2019

Stebalien commented Jul 9, 2019

Stebalien commented Jul 9, 2019 • edited Loading

ntninja commented Jul 9, 2019

ntninja commented Aug 11, 2019

Ericson2314 commented Jul 15, 2020

Proposal 1: `/dns/<domain>/<proto>`

Proposal 2: `/dns/<domain>/<record-type>`

progval commented Sep 18, 2016 •

edited

Loading

progval commented Sep 18, 2016 •

edited

Loading

progval commented Sep 18, 2016 •

edited

Loading

progval commented Sep 19, 2016 •

edited

Loading

ghost commented Dec 19, 2016 •

edited by ghost

Loading

Stebalien commented Jul 9, 2019 •

edited

Loading