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

Custom/local DNS name resolver support without ipfs server dns configuration #6915

Closed
matyapiro31 opened this issue Feb 20, 2020 · 12 comments · Fixed by #8068
Closed

Custom/local DNS name resolver support without ipfs server dns configuration #6915

matyapiro31 opened this issue Feb 20, 2020 · 12 comments · Fixed by #8068
Labels
kind/feature A new feature

Comments

@matyapiro31
Copy link

I'm using OpenNIC domain and want to go with ipfs web hosting, but any public ipfs gateway server don't support OpenNIC domain, pointing my domain to ipfs fails.

This will be a problem when using intranet.

Even if local ipfs server's dns configuration is correct, client has no way to check it.

So I want a feature of custom dns server.

@matyapiro31 matyapiro31 added the kind/feature A new feature label Feb 20, 2020
@hsanjuan
Copy link
Contributor

I've been looking into how we do /ipns/domain resolution.

For .eth we detect that suffix use .eth.link. This is a single domain (although I see things like .kred).

OpenNIC does not have (to my knowledge) a similar DNS-domain proxy that we can use similarly. We would need to use a Resolver with a custom dialer to their anycast servers (https://wiki.opennic.org/start).

I suppose there is a stable list of actual TLD domains under the OpenNIC federation (still to find the full one). People can apply for whatever new ones they want so it's subject to change.

Anyways, we could potentially support this so that people can get dnslink-ing etc on OpenNIC TLDs, which is probably a good thing and not overly different from supporting .eth.

@matyapiro31
Copy link
Author

matyapiro31 commented Mar 17, 2020

#6776 will solve this issue.
Related issues are:

#5982
ipfs/ipfs-companion#678
#6532

@matyapiro31
Copy link
Author

@hsanjuan At first, how about adding function to return 500 internal server error when DNS resolve failed?

@hsanjuan
Copy link
Contributor

@hsanjuan At first, how about adding function to return 500 internal server error when DNS resolve failed?

Can you show where/how that does NOT happen already?

@lidel
Copy link
Member

lidel commented Mar 22, 2020

@matyapiro31 @hsanjuan I believe setting custom DNS server won't be enough to support OpenNIC TLDs.

Context: go-ipfs performs additional go-is-domain checks in both namesys and http gateway code. Recently added .eth support required PR against that repo: jbenet/go-is-domain#13

First step to unblock use of OpenNIC would be to do the same: submit a PR extending ExtendedTLDs list with OpenNIC TLDs, then switch go-ipfs to updated version.

@matyapiro31
Copy link
Author

@lidel I sent PR, but .eth is also not supported still now?

@lidel
Copy link
Member

lidel commented May 10, 2020

.eth is supported since #6448 (via https://eth.link).

Do you mind linking your PR?

@matyapiro31
Copy link
Author

@lidel jbenet/go-is-domain#15
Here.

@matyapiro31
Copy link
Author

I think that I add special support for OpenNIC this time is faster answer now,
How about using http://proxy.opennicproject.org/ proxy for OpenNIC domain?

@lidel
Copy link
Member

lidel commented May 13, 2020

@matyapiro31 iiuc that "proxy" is a PHP script running on remote server, it won't work for go-ipfs. We need to merge your PR and switch go-ipfs to use updated domain validator.

Be patient, it will happen :-)

ps. I opened issue to move mentioned package under IPFS org: jbenet/go-is-domain#16

@matyapiro31
Copy link
Author

Those just solve opennic domain, but there's no idea to resolve custom dns server address.
I suggest that you use dns address as subdomain.

matyapiro31 added a commit to matyapiro31/go-ipfs that referenced this issue May 27, 2020
This commit is for ipfs#6915.
This enables dns resolver to select server.
@lidel
Copy link
Member

lidel commented Apr 26, 2021

FYSA this will be closed when #8068 and #8071 land.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
kind/feature A new feature
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants