/dns in multiaddrs

[jbenet]

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

• Support DNS  go-multiaddr#7
• add support for dns go-multiaddr#26

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)

[progval]

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]

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]

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]

• 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]

• 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

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

/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.

[daviddias]

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