Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add DNS Fallback Resolvers #8173

Open
johnnywu-namebase opened this issue Jun 2, 2021 · 3 comments
Open

Add DNS Fallback Resolvers #8173

johnnywu-namebase opened this issue Jun 2, 2021 · 3 comments
Labels
effort/days Estimated to take multiple days, but less than a week exp/intermediate Prior experience is likely helpful help wanted Seeking public contribution on this issue kind/feature A new feature P3 Low: Not priority right now topic/dns
Milestone

Comments

@johnnywu-namebase
Copy link

johnnywu-namebase commented Jun 2, 2021

TLDR if someone wants to implement this: #8173 (comment)


This issue arises from a chat between Namebase team and @lidel from Protocol Labs about integrating Handshake with IPFS

Given the goals of:

  • IPFS doesn’t want to choose winners
  • IPFS wants to decouple from ICANN and support non-ICANN namespaces
  • IPFS wants to avoid introducing privacy and security risks in implicit defaults
  • IPFS wants the alternative namespaces to be DNS compatible. Preferably they can use DoH endpoints

IPFS can accomplish these goals while supporting non-ICANN namespaces by adding a “fallback” resolver option to DNS.Resolvers that points to a list of DoH endpoints. Each DoH endpoint can point to a different decentralized naming system. When a query fails to resolve through the “.” resolver, query all of the “fallback” resolvers. If one of the resolvers has a match without conflict, then proceed with fetching the IPFS file. Otherwise if there’s a conflict, return an error code (ie HTTP 409 conflict).

The “fallback” setting can be set by default to [“https://query.hdns.io/dns-query”] which is HDNS.io’s Handshake DoH resolver (note that HDNS.io doesn’t log or store IP addresses or any other personal information, as specified in the privacy policy linked on the website). Polkadomain.org and butterflyprotocol.io — two other decentralized naming systems which issue TLDs — can be added as well when they create their own DoH resolvers and issue a PR

@johnnywu-namebase
Copy link
Author

For community members who may be interested in submitting a PR for this, some great pointers from @lidel:

Before starting implementation, one should post the proposed design as a comment here (how config would look like, what implicit default would be, and what needs to be changed to make that possible). Please also ping @lidel and myself to ensure the proposed design is included during their weekly triage session. By getting confirmation on design and config bikeshed first, we avoid investing time into approach that can't be accepted into the main branch and have more confidence moving forward.

@lidel
Copy link
Member

lidel commented Feb 7, 2022

Dropping a quick implementation note if anyone wants to work on this:

  • add DNS.FallbackResolvers to the config
    • should be a list of DoH endpoints to try in order when a default resolver return an error

This behavior should be enough to support HNS while minimizing privacy concerns around sending all DNS queries to Handshake community-maintained server – we would only send things that were not found on ICANN system, which makes a way safer behavior and is an useful feature for increased robustness of DNS lookup in general

@lidel lidel changed the title Implement "fallback" resolver Add DNS.FallbackResolvers Feb 7, 2022
@lidel lidel added exp/intermediate Prior experience is likely helpful help wanted Seeking public contribution on this issue P2 Medium: Good to have, but can wait until someone steps up and removed need/triage Needs initial labeling and prioritization labels Feb 7, 2022
@BigLep BigLep modified the milestones: Best Effort Track, TBD Mar 10, 2022
@lidel
Copy link
Member

lidel commented Apr 15, 2022

An additional feature request coming from #8836 is to allow passing more than one resolver per TLD in DNS.Resolvers, and use them in-order if the first one fails.

In Kubo's config we have a special type which is "String or Array of Strings" – prior art in Addresses.Gateway and Addresses.API. I think we could convert values of DNS.Resolvers to that and use additional ones as fallbacks if the default is down.

@lidel lidel added P3 Low: Not priority right now effort/days Estimated to take multiple days, but less than a week topic/dns and removed P2 Medium: Good to have, but can wait until someone steps up labels Apr 15, 2022
@lidel lidel changed the title Add DNS.FallbackResolvers Add DNS Fallback Resolvers Apr 15, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
effort/days Estimated to take multiple days, but less than a week exp/intermediate Prior experience is likely helpful help wanted Seeking public contribution on this issue kind/feature A new feature P3 Low: Not priority right now topic/dns
Projects
No open projects
Status: No status
Development

No branches or pull requests

3 participants