Hey there, for a long time I have been using dnscrypt with the resolver "dnscrypt.eu-nl". Mainly because it seems to be secure but also very fast (NL has a good connection to most countries in Europe, including mine). How ever, dnscrypt.eu-nl is down quite often (just like it was/is today) and I often ended up looking for the problem on "why my internet isn't working" just to find out it was "dnscrypt.eu-nl". Are there any other dnscrypt resolvers (preferable in Europe) that you can recommend and/or are using instead of dnscrypt.eu-nl? Thanks !
@zakazak List of resolvers https://github.com/jedisct1/dnscrypt-proxy/blob/master/dnscrypt-resolvers.csv Find one that suites you best. Preferably with "No logs", "namecoin" and DNSSec Validation" all "yes" Do some research beforehand none the less. As CHEFKOCH mentioned, trust is important. But considering your from .nl the soltysiak one seems your best fit.
Nope I am not from NL but close from it. Poland tends to have bad connection to my country (or generally any countries). Thanks, I know the list, I have a hard time deciding and thought someone could share he choice & thoughts From Switzerland to Poland.. the routing should be terrible? Or am I wrong?
No problem, have a look at the logging, namecoin and dnssec as mentioned in the list and see whats important to you. regards.
I never had much troubles but I'm not a gamer so I not need a low ping or a ow response. If you need performance then you should take a look at CloudNS. Since, I also use dnscrypt together with UnBound I anway not need much because my Unbound act likes a DNS cache so the only what might be a sow down problem is if the upstream resolver not answer within 60 seconds (default) and this never happened for me. But I agree on Ipv6 there are definitely more slowdowns because the timeout is much lower and this mostly ends up with a lot of log spam because it reports then a lot of fragmented packages or timeouts.
If I don't use "DNSSec" (which is a different/additonal package to dnscrypt?), is it still relevant for me? Should I still use a resolver which has this as "yes" ? Thanks !
Yes, dnssec should pre prefered because dnscrypt isn't an replacement for this, it act more like an extensions for this.
But to my understanding it only uses DNSSec if I have it installed and my apps configured/patched to use DNSSec? So only if I do that, DNSSec on the resolver is relevant for me?
The specific RFC must be implemented in the Browser and OS but that's not a problem because this is implemented in every OS/Browser. Your chosen server simply must support this and then you're fine. I suggest to read the wikipedia article what DNSSEC is and how it works to understand why this is maybe important for you, or may not important. For dnscrypt the resolver must support this, but if you installing it you get an overview what the resolver supports or simply look in the resolver.csv list or at the page. Just read some docs first and then you can make the decision.
Thanks for your quick reply. I am checking the Arch wiki (https://wiki.archlinux.org/index.php/DNSSEC) and according to that I would need to install a specific DNSSec package and enable it in all kind of packages?
Please read something before you post, the install instructions are given on the dnscrypt-page together with some examples. You simply need a server which supports it and that's it.
If im not mistaken, Dnssec allows resolvers to verify the records received (ie ensures what they send to what you receive are identical) whereas dnscrypt allows clients to verify the records sent by the resolver locally (ie what you send as a request) with the use of a cryptic key, as opposed to comparing two sets of secure records with dnssec. You are right in a sense, both are different means of verification. Both have strengths in different areas, you can use both to get the best of both worlds. But IMO using one or both is okay because you are using dnscrypt. So that using dnssec or not is okay because dnscrypt has you covered.
Maciej from DNSCrypt Poland here Apart from interesting exceptions it's usually best to choose geographically-close services, so NL should be best for you then. As I have some servers across europe to test ping latency from, I did a test from a server in NL to: - OpenDNS (208.67.222.222) I get <1 ms! (cool, has DNS, but is a corpo and breaks NX records) - Google (8.8.8.8 I get 5 ms (great, but google, doesn't break NX AFAIK) - DNSCrypt Poland I get 19.5 ms - DNSCrypt EU (NL) I get 4 ms Those are measurements from a servers, measurements from home through an ISP will be worse for sure. In my home case, DNSCrypt Poland is actually the best option with 8 ms. Best not because I run it and trust myself, but actualy the least latent. The hosting company is in my city. Generally, the connections are very stable from what I saw, it's just latency being a key factor for DNS to be snappy gives you a vote for DNSCrypt EU (NL) if you want independent DNSCrypt. Or OpenDNS if you trust them as they do provide DNSCrypt. As usual, it's not the destination location itself that matters, it's the path and border routing, so I always suggest you do a ping and a mtr to see how a connection rates. Depends on your route and weather condition as always. Measure and chose best for you. Some people prefer Poland because it's network-wise closer to them, e.g. users from CZ and SK have contacted me. For asian users, Poland is still better than France e.g.
What you mean by 'not supporting'? Dnscrypt is an extensions and they not need to 'support it'. Maybe read some docs about this. According to Wikipedia, Google uses DNSSEC so you can use there server and use dnscrypt without any problems. On Android this is default because the default DNS on Android is always (8.8.8.8 + ceullar providers one). But as I mentioned on dnscrypt project issue tracker on Android you get the problem that e.g. on cellular connection your provider want to override the default DNS and there is no option to stop this, so on Android I only recommend it if you're on Wifi because on this you can force the DNS server directly with 'advance' options.
I guess English isn't your native language, because your statements are constantly contradicting themselves. DNSCrypt does need to be supported both client and server side. Client side, one must use the DNSCrypt proxy (this is simpler on Windows via SimpleDNSCrypt), a list of servers that support the DNSCrypt encryption protocol is available here, Google is not one of them. DNSCrypt has nothing to do with DNSSEC. Since you're so adamant on people "reading docs", read this and learn.
Well, I just was not specific enough it seems, I talked about DNSSEC together with dnscrypt. Of course, you're right dnscrypt on server needs dnscrypt-wrapper and on client site dnscrypt. Sue and I never said something about this, but read above things, someone asked what he needs or should look at. I only said sever you choose not need to support it.
The thread was about DNSCrypt, so talking about servers that don't support it (Google) is just off-topic. The only reason DNSSEC was mentioned was because some of the servers that support DNSCrypt also support DNSSEC. However, I would not use DNSSEC as a main contributing factor in deciding which DNSCrypt-supporting server you want to use. More important factors are latency, stability and trust, but I guess that may vary in the opinions of others.
DNSSEC is too dependent on the integrity and independence of CAs and has a history of being privacy hostile. Practically, it's also a whole load more unproven code, and we have enough problems with the codebase we have, as glibc has shown.
I see, I was wondering why OpenDNS hadn't adopted it yet, but it never really bothered me. I care mostly about reliability, I don't want to be bothered messing around with DNS resolvers that go down (looking at the changelog for the DNSCrypt resolvers list, a lot of them go down very often). I want my internet to just work, the security and lower latency benefits are positive side effects of using OpenDNS for me. Speaking of the glibc issue, the OpenDNS engineering team seem pretty confident with their implementations: https://engineering.opendns.com/2016/02/29/a-brief-history-of-opendnscache/ https://engineering.opendns.com/2016/02/17/2980/