Proposal: Configurable DNS resolvers for human-readable names

[lidel]

• Main focus here is improving the story behind human-readable names
  • addressing low-hanging fruits to unblock more powerful work later (see "Future opportunities" at the end)
  • extremely impactful when it comes to user onboarding.
  • we have some gaps which limit the usefulness of DNSLink in the context of alternatives to DNS system managed by ICANN
• There is some overlap with Proposal: Reliable Mutability Primitive #19 around what needs to be fixed in IPNS, and if tackled separately could decrease the scope of this project.

cc @Gozala @autonome @aschmahmann – this summarizes various discussions/plans we had this year, give it a read in spare moment in case I missed or misrepresented something 🙏

[Gozala]

One thing that is not clear to me here is why IPFS needs to allow plugging alternative name resolution algorithms. Seems like they should be plugging themself at the OS layer instead.

My concern is that primary value of URL is that it provides universal way for sender to send a name that receiver can use to obtain content regardless of their configurations. If that becomes conditioned on node configurations of sender and receiver they loose value and in fact can harm the ecosystem by creating a reputation of unreliable or too complicated.

Another thing worth considering is that DIDs seem to be gaining momentum, at least in web3 space, maybe that could be a place to plug alternative naming and resolution schemes as opposed to overloading DNS.

Huge +1 on making IPNS reliable so that DNSLinks use /ipns/ as opposed to /ipfs/

[BigLep]

This is awesome - great work! No expectation to respond to everything in GitHub. I'm also game to connect verbally if that's easier.

One suggestion: should we scope this proposal to:

1. DNS over HTTPS is supported in js/go-ipfs/libp2p
2. DNSLink provides interop for human-readable names and enables independence from PKI and ICANN.

and let everything about "IPNS provides a reliable solution for cryptographically-verifiable mutable names that won't break, as long someone is re-publishing the latest record" live in #19 ?

This would allow this proposal to simplify a bit and I assume they could be executed/delivered in parallel (with the best customer value occurring when both are completed)?

[BigLep]

n00b questions:

1. Is there a DNS resolver that is capable of resolving all TLDs over ENS? Is this more about something that could come in the future (per https://ccnso.icann.org/sites/default/files/field-attached/presentation-dns-blockchain-ens-24jun19-en.pdf )?
2. Is this a general issue even at the OS level that a user won't be able to have DNS that works with ENS, OpenNIC, and UnstoppableDomains together? Can someone have a local DNS proxy that can resolve using ENS, OpenNIC, UnstoppableDomains, etc.?

[lidel]

Ad 1. Yes, https://eth.link provides endpoint at https://eth.link/dns-query, but we will use it only for resolving *.eth, unless (Brave) user chooses otherwise

Ad 2. Correct, my opinion is that requiring users to run DNS proxy is not realistic. Ability to specify DoH resolver per TLD removes the need for that, but if someone wants to run own DNS resolver, they can also do this here – just point at localhost one.

[BigLep]

The convenience makes sense. Question about .ENS users: are they going to be comfortable/supportive of mutating changes happening outside of the blockchain? Haven't they now effectively lost the transaction history for part of their domain (i.e., the CID for the content the domain is pointing to)?

[lidel]

ENS users have a choice between pointing at IPFS identifiers in one of two namespaces:

• ipfs-ns – immutable identifiers – never change
• ipns-ns - mutable cryptographic identifiers, only owner of the publishing key can make change and update there it points at

The latter is still a cryptographic identifier, but yes, it is being mutated outside of blockchain.
For many that is a killer feature, because it means they don't need to pay gas every time they want to update their website. IPNS makes ENS way cheaper, more practical and I'd argue safer – you don't need to take out your hardware wallet to update your blog.

[BigLep]

Do you have any anecdotes that lead to think this could be the case?

[lidel]

Cynical commentary goes like this:

• DoH by definition points at some centralized HTTPS server
• We don't want to ship some preconfigured DoH server for all ICANN names with go-ipfs, to avoid pointing all users at the same endpoint
  • DoH endpoint choice should be made by user or user agent
  • Still, it is possible that most people will use DoH endpoints from Google or Cloudflare, because those are fast and reliable, so we mitigated privacy leak and mitigated ISP-level spoofing, but then put all eggs in one basket

[BigLep]

Would customer actually be ok with this given the Gas fees to publish a new CID?

[lidel]

Chicken and egg, of sorts: fixing IPNS would remove the problem of gas cost.

However, the way I see it, the real problem here is not the cost of gas or chore of updating ENS record.
Using this as a global resolver would be just a charade: most domains will remain on ICANN network for years to come, so ENS would act as a centralized proxy for 99,9....% of ICANN lookups 🙈

[lidel]

@Gozala the ability to override OS-level resolver is crucial for both user choice/security (OS-level one is most likely plaintext from ISP) and for our browser integration story. Brave wants to add suport for ENS via DoH at https://eth.link/dns-query, with more systems to come, and I believe go-ipfs should provide primitives to follow DNS resolver choices user made via their user agent.

Being able to support non-ICANN names is something we get as a side effect of this work. We already support ENS in a hacky, hardcoded way in go-ipfs. What we propose to do here is to remove vendor-specific code and use DNS for interop.

My plan is to ship go-ipfs with some predefined DoH endpoints, so TLDs like .eth work out of the box, but the user has the choice to change the default resolver (right now, user has none).

As for DIDs, I don't believe there are any primitives for human-readable names, so out of scope here(?)

[lidel]

@BigLep Yes, we should remove the overlap. I'll try to move IPNS-related parts to #19 tomorrow.

[BigLep]

@lidel: one other comment/idea here: Does the work in this proposal and/or #19 help NFT creators/owners in any way? That is a key usecase we want to ensure the PL stack is supporting in a user-friendly way. If it is, can you call it out as that will help with prioritization.

[lidel]

@BigLep I refactored this proposal to focus on adding configurable DNS resolvers to our stack + mentioned how improving human-readable names improve user onboarding story for NFT / dapps / static websites.

IPNS parts are out of the scope of this proposal, but left them in explainer in the beginning, as it is important to see the full mutability picture. IPNS improvements will be tracked in #19, like you suggested.

[BigLep]

@lidel: should we also add in that Brave expecting this DoH work to get so that DNS queries are not leaked? I assume we'd add any links that provide more context about why this is important for this partner specifically.

[Stebalien]

Also see some prior work in ipfs/kubo#6560 (which unfortunately died in the bike-shed).

TL;DR: I'd really like to have this.

[Stebalien]

This isn't entirely true, from a protocol standpoint, at least. If the IPNS author sets an infinite "EOL" on an IPNS record, anyone can republish. However, IPNS records expire by-default to limit how "stale" of a record an attacker could return to a client.

[lidel]

While protocol is mostly ok, IPNS rot is a mixture of implementation choices:

• The default is not an infinite EOL, so everything expires unless original publisher bumps the record over and over again
• Expired records are ignored during resolution, even if no valid one is present and expired ones are all we have
• Only original publisher can bump EOL and keep record available by republishing it

[Stebalien]

There are actually several "well known" APIs for updating "dynamic" DNS records. We should support those.

[lidel]

Mind providing examples, so I know we talk about the same thing?

I think "several" is the problem here. I am not aware of any vendor-agnostic API for updating DNS records that is supported across multiple DNS vendors. Everything is a soup of vendor-specific HTTP APIs and I don't think IPFS project should endorse vendor lock-in like that.

[Stebalien]

Hm. Yeah, I'm seeing the same thing. For simple A records, it looks like you can basically just "template" a URL. But that's not going to work for custom records.

There is RFC 2136, but it doesn't look well supported. I guess IPNS is simpler...

[Stebalien]

Why? Purely so we don't have to have a way to auto-update DNS records?

[lidel]

Correct. It removes the need for keeping DNS credentials and in context of ENS it removes the cost of paying for gas during each update.

[Gozala]

@Gozala the ability to override OS-level resolver is crucial for both user choice/security (OS-level one is most likely plaintext from ISP) and for our browser integration story. Brave wants to add suport for ENS via DoH at https://eth.link/dns-query, with more systems to come, and I believe go-ipfs should provide primitives to follow DNS resolver choices user made via their user agent.

Being able to support non-ICANN names is something we get as a side effect of this work. We already support ENS in a hacky, hardcoded way in go-ipfs. What we propose to do here is to remove vendor-specific code and use DNS for interop.

My plan is to ship go-ipfs with some predefined DoH endpoints, so TLDs like .eth work out of the box, but the user has the choice to change the default resolver (right now, user has none).

As for DIDs, I don't believe there are any primitives for human-readable names, so out of scope here(?)

Thanks for elaborating, basically I would like if this was something that user could configure at OS level (even if in user space) so that brave, ipfs and others could recognize and respect as opposed to each coming up with own solution and creating a very complex user experience.

[lidel]

@Gozala this is way beyond this proposal, but in the future go-ipfs could expose own DoH endpoint on localhost, so other services can use it as DNS cache/resolver. No need for additional service.

[Gozala]

@Gozala this is way beyond this proposal, but in the future go-ipfs could expose own DoH endpoint on localhost, so other services can use it as DNS cache/resolver. No need for additional service.

Maybe I'm missing something here, but what I was trying to imply is not sticking more things into ipfs config, but rather looking at things in e.g. ~/.config that way other programs like brave could converge to doing the same. If other programs will need to have go-ipfs to do DNS resolution it's very unlikely to happen.

The reason I'm bringing this up is because there is a tendency to build things into ipfs, e.g. we have key manager, despite every OS having a native one. I realize that is not the case here, but talking to others teams might enable us to have a greater impact.

[lidel]

This is a valid point, but feels out of scope of this project:

• splitting go-ipfs config, or at least extracting secrets like keys to separate files is unrelated implementation detail already tracked in Separate identity values from configuration file ipfs/kubo#6262
• afaik no generic format for storing DNS resolution rules per TLD/wildcard exists,
  and I don't see any immediate need for IPFS project to invent one:
  • Things like this take a lot of spec work and are more complex than they sound: even simple ~/.config is not as simple as it look (macos, windows will have own conventions, and even linux expects XDG_CONFIG_HOME support that may override default location etc)
  • Browser vendors like Brave won't be interested in additional complexity that comes with supporting a new standard like this.
    • User agents like Firefox or Brave want to be "the source of truth":
      • Firefox has own CA store + one can set custom DoH resolver via network.trr* in about:config that overrides OS-level settings
      • In near future user will be able to set DNS resolver for ENS in Brave, which needs to have technical means of ensuring go-ipfs complies with that choice without bothering the user.
    • What we want to do in this PR is to make go-ipfs flexible enough to support Brave use case (dnslink in ipns://) and enable experimentation with non-ICANN naming systems.

TLDR: Introducing a OS-level config for DNS resolution is out of scope here, but could be added in the future, as a follow-up project ("if go-ipfs config does not have custom resolver defined, fallback to user/OS-level config").

[lidel]

Implementation can be tracked in the "Ongoing work" section of ipfs/kubo#6532