-
-
Notifications
You must be signed in to change notification settings - Fork 3k
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
Added custom DNS resolver with support for DNS-over-TLS and DNS-over-HTTPS #6560
Conversation
Note: tests will fail until ipfs/go-ipfs-config#40 is merged |
Thanks! This is awesome! What if we took the configuration in as a multiaddr? That is:
|
That way, we can even specify a set of resolvers (to be tried in series). |
I actually like that idea! Would we just have a single configuration entry, then, something like "DNS" (as a string)? If that's empty, it would fallback to the system's resolver. Does go-ipfs already have a multi-address parser built-in? If you could please give me a pointer to that, I'll look at making the update tonight (unless you want to make it yourself, you do have write access to my forks :) ) |
Just to be safe, I'd have:
We may want to make security requirements, caching, etc. configurable in the future. |
https://github.com/multiformats/go-multiaddr/ However, we need to quickly add a TLS protocol (we already need one anyways). |
PR to define TLS multicodec: multiformats/multicodec#145 |
Doesn’t look like multiaddress would support something like this however?
I could add the TLS protocol but I’m more worried about the host part? To be frank, the Host part isn’t even strictly necessary:
|
See multiformats/multiaddr#63 (comment). The current proposal is to define HTTP (which isn't really used in practice yet) as Looking around, it seems that the real issue is that js-libp2p has gone off and used the ... I'll bring this up at the next core implementations meeting. For now, we can support |
So, let me see if I understand correctly:
I won't be able to join the call next week, but I assume you'll want to discuss this PR :) If there are comments/feedback, we can take them offline here? |
We have a rule: it didn't happen if it isn't written somewhere on github. So yes, all resolutions and reasons will end up here. Note: we'll likely schedule a second call during the first call to actually resolve the issue. I'll keep you in the loop in case you're interested (but it's only tangentially related to this issue). |
Ok I pushed the code changes you requested:
As before, this depends on ipfs/go-ipfs-config#40 (which I just updated) and tests will fail until that's merged. Does this design look good to you now? If so, I will start working on the unit tests tonight or tomorrow night -- EDIT |
As I'm working on this, I noticed that some other parts of the codebase use a DNS resolver, calling the one inside https://github.com/multiformats/go-multiaddr-dns I will need to update that too, likely |
I hit a road block while working on this during the weekend. Turns out that https://github.com/multiformats/go-multiaddr-dns queries DNS too, and I believe that's used to resolve domain names inside multi-addresses in the config file (e.g. when the peers are defined with a DNS multi-address). I could replace the DNS inside go-multiaddr-dns (either by changing the library or I believe at runtime too). The problem is that the DNS server to use is defined inside the .ipfs/config file, and I'm afraid of creating a bunch of spaghetti code because the config file is read after go-multiaddr-dns is loaded... Thoughts? |
@Stebalien any update from today's call? |
Yes. Sorry for the delay. The conclusion was to ignore everything I've told you and to just manually configure all of this. We realized that, technically, we need to be able to specify a path for DNS-over-HTTPS and didn't feel like we'd be able to solve that issue in a single meeting. I'm really sorry for the confusion, it just looks like multiaddr isn't quite ready for this use-case. |
So yeah. Let's have a |
The real issue is that the HTTP multiaddr really needs to be a URL template (https://tools.ietf.org/html/rfc8484#section-4.1). Something like Library: https://godoc.org/google.golang.org/api/googleapi/internal/uritemplates (?) |
Sorry for the radio silence on this, I have been very busy and I will be for at least another couple of weeks. My biggest problem remains on how to reconcile the fact that go-multiaddr-dns needs a DNS resolver too. go-multiaddr-dns is used while loading the config file of IPFS (in fact, it's what resolves the DNS names within the config file). So, when go-multiaddr-dns is loaded, there's no way to pass it the IPFS configuration to set a DNS server The cleanest solution would be:
Without that, I'm afraid we have a chicken-and-egg problem. |
How about adding test on dns_test.go? |
return &DNSResolver{lookupTXT: net.LookupTXT} | ||
func NewDNSResolver(cfg *config.Config) (*DNSResolver, error) { | ||
// Check if we're using a custom DNS server | ||
if len(cfg.DNS.Resolver) > 0 { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Please add system environmental variables.
Superseded by #8068 which takes bit different approach (go-multiaddr-dns) that works for both multiaddrs and dnslink (also, namesys got moved to https://github.com/ipfs/go-namesys). See "Ongoing work" in #6532 for full context. Thank you @ItalyPaleAle for taking the first stab at this and identifying relevant code paths! ❤️ |
This PR should fix #6532
In the current implementation, go-ipfs uses the machine's DNS resolver for querying TXT records used by DNSLink. As highlighted in #6532, this can come with some issues related to censorship, privacy, and support for TOR.
I've implemented a custom DNS resolver that supports:
Note that the PR is still not complete. At the moment, I am missing: