DNSCrypt – A protocol to improve DNS security(dnscrypt.org)
dnscrypt.org
DNSCrypt – A protocol to improve DNS security
https://dnscrypt.org
76 comments
So much to respond to here.
I am one of those companies running a recursive DNS service, DNSFilter.com
We are not advertising driven. OpenDNS cut the ads a few years ago.
We do not run open resolvers, we just have paying customers who wish to use our service.
The DNS extensions you are referring to are the EDNS0 Client Subnet extension. It is in wide use by authoritative servers for major CDNs and is supported by a number of recursive DNS providers. See the spec here: https://tools.ietf.org/html/draft-ietf-dnsop-edns-client-sub... Section 11 addresses your concerns about IP addresses being shared: It is encouraged to provide only as much granularity as is necessary based on network architecture. At no time is there a reason to share the last octect of an address (since Internet BGP routing is limited to a /24)
We do not run an authoritative DNS service, yet are working to improve encrypted communications... in coordination with industry authoritative partners. Very early stages, but we are driven to protect our customers and the Internet at large. Every time I hear someone misunderstanding what DNSSEC is, and why they think they want it, I'm encouraged to work on solutions such as dnscrypt or DNS over TLS: https://tools.ietf.org/html/rfc7858
I am one of those companies running a recursive DNS service, DNSFilter.com
We are not advertising driven. OpenDNS cut the ads a few years ago.
We do not run open resolvers, we just have paying customers who wish to use our service.
The DNS extensions you are referring to are the EDNS0 Client Subnet extension. It is in wide use by authoritative servers for major CDNs and is supported by a number of recursive DNS providers. See the spec here: https://tools.ietf.org/html/draft-ietf-dnsop-edns-client-sub... Section 11 addresses your concerns about IP addresses being shared: It is encouraged to provide only as much granularity as is necessary based on network architecture. At no time is there a reason to share the last octect of an address (since Internet BGP routing is limited to a /24)
We do not run an authoritative DNS service, yet are working to improve encrypted communications... in coordination with industry authoritative partners. Very early stages, but we are driven to protect our customers and the Internet at large. Every time I hear someone misunderstanding what DNSSEC is, and why they think they want it, I'm encouraged to work on solutions such as dnscrypt or DNS over TLS: https://tools.ietf.org/html/rfc7858
Hi there, I work in advertising, and I absolutely use the EDNS0 data to track users. I'm okay with a 1:250ish potential error rate since outside of facebook and google, you probably don't go to the same websites as your neighbour.
Thanks for your hard work.
Thanks for your hard work.
I'm curious: what's the reason for doing this rather than just logging the IP addresses that hit your server directly? Is this a way to get around VPNs that leak the real IP via DNS? Or does this allow you to get something back from users with ad blockers that block the request, but no the DNS lookup (I don't know if this is the case)? Is it just a performance optimization (just a DNS lookup vs. a HTTP request)?
I don't have a server for them to hit directly: My DNS server always returns NXDOMAIN.
How does that work?
I log the requests to my DNS servers.
My client embeds information I need into the host part and the custom DNS server always returns NXDOMAIN.
My client embeds information I need into the host part and the custom DNS server always returns NXDOMAIN.
From section 11 of the draft:
"To protect users' privacy, Recursive Resolvers are strongly encouraged to conceal part of the IP address of the user by truncating IPv4 addresses to 24 bits. 56 bits are recommended for IPv6, based on [RFC6177]. ISPs should have more detailed knowledge of their own networks. That is, they might know that all 24-bit prefixes in a /20 are in the same area. In those cases, for optimal cache utilization and improved privacy, the ISP's Recursive Resolver SHOULD truncate IP addresses in this /20 to just 20 bits, instead of 24 as recommended above. Users who wish their full IP address to be hidden need to configure their client software, if possible, to include an ECS option specifying the wildcard address (i.e. SOURCE PREFIX-LENGTH of 0). As described in previous sections, this option will be forwarded across all the Recursive Resolvers supporting ECS, which MUST NOT modify it to include the network address of the client".
So it's suggested that DNS providers and ISPs use only a portion of the IP address but they aren't forced to do so (and how could they be forced anyway?). Then it says that users that don't want to send their IP address should configure their software accordingly, but again only "if possible" so again no guarantee that it would be possible. Now a question: I don't see why a DNS packet would contain the client's IP address and a (I admit too quick) look at the draft didn't provided any information. Could you please elaborate on the supposed advantages of this practice?
So it's suggested that DNS providers and ISPs use only a portion of the IP address but they aren't forced to do so (and how could they be forced anyway?). Then it says that users that don't want to send their IP address should configure their software accordingly, but again only "if possible" so again no guarantee that it would be possible. Now a question: I don't see why a DNS packet would contain the client's IP address and a (I admit too quick) look at the draft didn't provided any information. Could you please elaborate on the supposed advantages of this practice?
It's to return local DNS records so you resolve to a nearby server.
I have one more question. DNS requests are carried by the IP protocol, so when someone makes a DNS interrogation the DNS server already gets the client's full IP address in the IP header. Isn't redundant to place (a portion of) the IP address in a DNS packet? Or maybe for some reason the DNS server is quicker to get this information from the DNS packet rather than from the IP packet's header?
I use e.g. 8.8.8.8 as my DNS server. When that server needs to request a record for me, the other servers it connects to will only see 8.8.8.8. With this extension, the 8. server will embed my subnet into the request and allow upstream servers to see part of my IP.
How was OpenDNS able to cut the ads yet provide free service?
Full Disclosure - work for Cisco/OpenDNS. https://www.opendns.com/no-more-ads/ talks about why we shut off ads. As to "how" we were able to. We do offer paid services to both home and business (SMB through Enterprise) users. Additionally, we are a security and data company -- free service feeds into data driven models for security that benefits all suers.
It quite easy to setup DNSCrypt with OpenNIC[1] and then a lot of the downsides that you mention go away.
Here is some background and setup instructions:
https://markbrown778.wordpress.com/2014/08/08/dns-privacy-us...
[1] https://www.opennicproject.org/
Here is some background and setup instructions:
https://markbrown778.wordpress.com/2014/08/08/dns-privacy-us...
[1] https://www.opennicproject.org/
I am skeptical to its architecture. This is 2017 and there are compelling reasons for endpoints to do resolving on their own. To get rid of open resolvers would be nice.
"But .. caching", well, the performance of resolvers is perhaps not as clear cut as that. Performance would suffer for some, but they can clearly handle it, and does it really matter?
Some real world testing would surely be beneficial. In the mean time, I'm not sure about solutions to the resolver data leak problem. It is a solution to a problem we should not have.
"But .. caching", well, the performance of resolvers is perhaps not as clear cut as that. Performance would suffer for some, but they can clearly handle it, and does it really matter?
Some real world testing would surely be beneficial. In the mean time, I'm not sure about solutions to the resolver data leak problem. It is a solution to a problem we should not have.
>The reason? Advertising.
Or the ability to accurately direct users to the nearest POP.
Or the ability to accurately direct users to the nearest POP.
Yes, for people who don't know, this is how many things like directing users to a closer TLS endpoint for HTTP such that the overall connection suffers less latency.
Isn't anycast ip usually used for that instead?
It entirely depends, anycast is great for getting a request to the closest DNS endpoint via routing weight rules.
After that, there are many options. But the GP was specifically mentioning a valid use case where this is applicable and not shady.
After that, there are many options. But the GP was specifically mentioning a valid use case where this is applicable and not shady.
For all the attention that https gets, I'm amazed how little (relatively speaking) attention plaintext dns gets.
If a site is https then even if an attacker is MITM-ing DNS to their own site they presumably won't have a valid cert for the site they're intercepting, although it has happened many times before, and 50% of the internet is still unencrypted. But even assuming that doesn't happen it's still a huge privacy/data leak.
If a site is https then even if an attacker is MITM-ing DNS to their own site they presumably won't have a valid cert for the site they're intercepting, although it has happened many times before, and 50% of the internet is still unencrypted. But even assuming that doesn't happen it's still a huge privacy/data leak.
> But even assuming that doesn't happen it's still a huge privacy/data leak.
Meh, if an attacker can sniff your packets, they can already tell what IP addresses you're talking to, which certainly narrows down which domain names you're talking to.
I'm far more concerned with the possibility of intercepting or hijacking http traffic. Sure, an attacker could do this with any non-TLS connection in theory, but it's way way easier to hijack that one DNS response and change the A record.
Meh, if an attacker can sniff your packets, they can already tell what IP addresses you're talking to, which certainly narrows down which domain names you're talking to.
I'm far more concerned with the possibility of intercepting or hijacking http traffic. Sure, an attacker could do this with any non-TLS connection in theory, but it's way way easier to hijack that one DNS response and change the A record.
The IP address does not always tell you to which site you are connecting to. Many different sites can point to the same IP, more when services like Cloudflare are being used.
Most clients nowadays sent the "server name indication" (SNI) TLS extension though, which contains the name of the site you are connecting to.
The extension is sent unencrypted, even when using TLS 1.3. So everyone sniffing the traffic can tell where you are surfing to, even without DNS.
The extension is sent unencrypted, even when using TLS 1.3. So everyone sniffing the traffic can tell where you are surfing to, even without DNS.
I don't think many people know this, or at least never think about it. "https means encrypted, that means secret."
And in order to support clients that don't support SNI, you need to have one domain per IP address so an attacker can just try and connect to that IP and then look at the SSL cert that's sent back to get the domain name.
>And in order to support clients that don't support SNI
There is little reason to support clients that do not support SNI. By supporting those clients you are likely putting your entire encrypted infrastructure at risk. SSL3 should be disabled by now. XP clients are legacy and should be taken out back and shot. Older mobile phones are enormous security risks.
There is little reason to support clients that do not support SNI. By supporting those clients you are likely putting your entire encrypted infrastructure at risk. SSL3 should be disabled by now. XP clients are legacy and should be taken out back and shot. Older mobile phones are enormous security risks.
With increasing IPv6 adoption this would be less and less true.
Your viewpoint is like the post "DNSCrypt – Not Fundamental Enough" (2011) from TrendMicro.
http://blog.trendmicro.com/trendlabs-security-intelligence/d...
http://blog.trendmicro.com/trendlabs-security-intelligence/d...
>Meh, if an attacker can sniff your packets, they can already tell what IP addresses you're talking to, which certainly narrows down which domain names you're talking to.
Honest question: with an increasing amount of sites being hosted via cloud infrastructure, does an IP really let you know if you are talking to Amazon, Google, or Microsoft vs the multitude of sites hosted by AWS, GCP, or Azure?
I'm assuming they use their own infrastructure, but I could be wrong.
Honest question: with an increasing amount of sites being hosted via cloud infrastructure, does an IP really let you know if you are talking to Amazon, Google, or Microsoft vs the multitude of sites hosted by AWS, GCP, or Azure?
I'm assuming they use their own infrastructure, but I could be wrong.
IPs don't matter. SNI tells eavesdroppers the exact domain you are talking to.
Hopefully we will get Encrypted SNI with TLS 1.3
https://www.ietf.org/proceedings/94/slides/slides-94-tls-8.p...
https://www.ietf.org/proceedings/94/slides/slides-94-tls-8.p...
Yes, VPS services will still assign your instance an IP address of its own.
As far as I understand this doesn't encrypt communication but authenticates it to ensure it hasn't been tampered with. So it's still out in the open. I also don't understand what the benefit over DNSSEC is.
Edit: Nvm, DNSSEC still has to trust the validating resolver, DNSCrypt solves this.
Edit: Nvm, DNSSEC still has to trust the validating resolver, DNSCrypt solves this.
dnscrypt is an encrypted channel back to the DNS server. They can tell it's going to OpenDNS because of the IP address, but the cannot see the payload.
Why would you forward to opendns with a local dnssec enabled resolver? Just implement dnssec and run a proper dns infrastructure.
No DNS operator reading HN? This thread is full of misinformation.
Good to know, couldn't find that on their website.
Right, but what advantage does DNSCrypt have over a local DNSSEC aware resolver? If you can't trust the local resolver you have more serious problems than DNS.
DNSSEC provides no privacy. In fact, DNSSEC provides in the real world very few benefits of any kind, which is one of the reasons it's seen so little uptake in the 22 years during which the IETF has been working on it. Its most credible technical application is as a replacement for the CA system (which is a terrible idea).
https://sockpuppet.org/blog/2015/01/15/against-dnssec/
In the real world, for privacy, there are essentially two competing approaches: DNSCrypt and DNS-Privacy. Both are unrelated to DNSSEC. DNSCrypt uses a custom protocol to encrypt DNS transactions, and DNS-Privacy uses TLS. Neither require, or even benefit from, deployment of DNSSEC.
https://sockpuppet.org/blog/2015/01/15/against-dnssec/
In the real world, for privacy, there are essentially two competing approaches: DNSCrypt and DNS-Privacy. Both are unrelated to DNSSEC. DNSCrypt uses a custom protocol to encrypt DNS transactions, and DNS-Privacy uses TLS. Neither require, or even benefit from, deployment of DNSSEC.
As others have stated, DNSSec only solves for authenticity of the data, not privacy.
DNSCrypt has been designed to both authenticate, authorize and encrypt the channel.
Using both in conjunction means that you have a private connection with authenticated data coming from the upstream resolver. Now the obvious issue is you don't know what the upstream resolver does with that...
DNSCrypt has been designed to both authenticate, authorize and encrypt the channel.
Using both in conjunction means that you have a private connection with authenticated data coming from the upstream resolver. Now the obvious issue is you don't know what the upstream resolver does with that...
An easy way to think about this stuff is:
DNSSec => Authenticity of resource records
DNSCrypt, DNSoverTLS => Privacy of the connectionThat's a little of an oversimplification. DNSSEC is indeed limited to authenticity. But the idea of DNSCrypt is that with very widespread deployment, you get most of the benefit of resource integrity, in the same way that we do with TLS even though no system in TLS explicitly "signs" HTML pages.
Sure. But who's running every node in the DNSCrypt graph? I've never been clear about what that looks like.
I still see DNSSec as providing value before the entire graph of DNSCrypt or DNSoverTLS exists.
I still see DNSSec as providing value before the entire graph of DNSCrypt or DNSoverTLS exists.
There isn't one DNSCrypt graph. It's a forest of graphs that, in the event DNSCrypt became mainstream, would effectively converge. But, unlike DNSSEC, DNSCrypt doesn't require universal adoption to provide value.
DNSSEC provides no value at all until graph coverage is reached, and even then provides absolutely no privacy.
DNSSEC provides no value at all until graph coverage is reached, and even then provides absolutely no privacy.
> If a site is https then even if an attacker is MITM-ing DNS to their own site they presumably won't have a valid cert for the site they're intercepting
Kinda. It still can add a CNAME there, and make you go into another site for what it has a valid cert.
Kinda. It still can add a CNAME there, and make you go into another site for what it has a valid cert.
A CNAME isn't a redirect; if you add a CNAME record from thing1.example.net pointing to thing2.example.com, the browser still uses the domain name thing1.example.net for certificates, and just does a DNS lookup on thing2.example.com.
Put another way, a CNAME literally says the answer for any record type for thing1. is found by querying its canonical name, thing2. They're most comparable to symlinks. There is no data for this label; ask over there in that label. (This is why you can't CNAME the top of a zone, because you need SOA and NS there and CNAME can't coexist with other types. It wouldn't make sense.)
In most DNS stacks when an application asks for thing1. the usual way (something like gethostbyname), the resolver side will quietly follow a CNAME answer and resolve thing2. without telling the application anything happened. It's not part of the usual APIs, but that's not to say applications can't find out if desired. Same story with symlinks, where one uses a different API to read the link instead of the target. So for the browser case mentioned, a naive resolver wouldn't even be aware of the CNAME, hence the CN not changing for TLS purposes and the address bar staying the same. No modern browser has a naive resolver, just saying.
People trip up on this a lot, just clarifying.
In most DNS stacks when an application asks for thing1. the usual way (something like gethostbyname), the resolver side will quietly follow a CNAME answer and resolve thing2. without telling the application anything happened. It's not part of the usual APIs, but that's not to say applications can't find out if desired. Same story with symlinks, where one uses a different API to read the link instead of the target. So for the browser case mentioned, a naive resolver wouldn't even be aware of the CNAME, hence the CN not changing for TLS purposes and the address bar staying the same. No modern browser has a naive resolver, just saying.
People trip up on this a lot, just clarifying.
Just pointing out, there's now a standardized way to do encrypted DNS via TLS:
https://tools.ietf.org/html/rfc7858
Probably more likely that that one will succeed. DNScrypt has been around for a long time and hasn't really seen any significant adoption.
https://tools.ietf.org/html/rfc7858
Probably more likely that that one will succeed. DNScrypt has been around for a long time and hasn't really seen any significant adoption.
Why are you being downvoted?
https://kb.isc.org/article/AA-01386/30/DNS-over-TLS.html
This article shows how to set it up according to ISC with stunnel.
I was hoping for a native implementation in Bind but maybe it's coming.
https://kb.isc.org/article/AA-01386/30/DNS-over-TLS.html
This article shows how to set it up according to ISC with stunnel.
I was hoping for a native implementation in Bind but maybe it's coming.
Bind is still a mess after all these years. It seems to me like I get an update every other week that fixes a trivial DoS that hits an unchecked assertion.
bind is a software that is only 80% finished. The missing 20% that take 80% of the time will only be implemented via CVEs.
bind is a software that is only 80% finished. The missing 20% that take 80% of the time will only be implemented via CVEs.
Do they need help? Or a more rigorous test suite? Or pushing more errors to the compiler to trap these kind of things?
What's a good alternative open source DNS that supports views and DDNS updates?
Take a look at PowerDNS. I use it for my day job and it causes very little trouble. I can only recall one annoying bug and one security issue in about the last two years.
It also has an OK, if not great, API for integrating with, e.g., your provisioning system, inventory system, etc.
It also has an OK, if not great, API for integrating with, e.g., your provisioning system, inventory system, etc.
This can't be repeated often enough:
If you have some ssh server somewhere (who hasn't), you can very easily create a 'VPN over ssh' by calling:
sshuttle -r user@remote_host 0.0.0.0/0 --dns
It works nicely together with dnscrypt
If you have some ssh server somewhere (who hasn't), you can very easily create a 'VPN over ssh' by calling:
sshuttle -r user@remote_host 0.0.0.0/0 --dns
It works nicely together with dnscrypt
This only moves the problem slightly. You then have to trust the network surrounding your SSH box.
It does more than that. AWS or Linode are not, to my knowledge, deploying the sort of intrusive, ad-centric deep packet inspection that Comcast, for instance, is. It is also a layer of separation from your actual IP address, which is worth less than it may seem at first, but helps.
Of course, that could change if everyone starts using homebrew VPNs. That's a bit hard to imagine, but stranger things and all that.
Of course, that could change if everyone starts using homebrew VPNs. That's a bit hard to imagine, but stranger things and all that.
Your default setup probably involves using your ISPs DNS resolver, which leaks your DNS queries to your ISP. Your ISP can also see which IP addresses you are connecting to and which website hostnames you're visiting thanks to unencrypted HTTP, and to SNI.
You could re-point your DNS resolver to one of the public DNSCrypt resolvers, but by doing so, all you're doing is making it so that another party gets to see your traffic. Your ISP still knows what you're doing, but now your DNS provider knows too.
From their own front page:
You could re-point your DNS resolver to one of the public DNSCrypt resolvers, but by doing so, all you're doing is making it so that another party gets to see your traffic. Your ISP still knows what you're doing, but now your DNS provider knows too.
From their own front page:
Please note that DNSCrypt is not a replacement for a VPN,
as it only authenticates DNS traffic, and doesn't prevent
third-party DNS resolvers from logging your activity. By
design, the TLS protocol, as used in HTTPS and HTTP/2,
leaks websites host names in plain text, so DNSCrypt is
not enough to hide this information.>Your default setup probably involves using your ISPs DNS resolver
You also have to make sure your ISP isn't transparently capturing your DNS packets, which they probably are.
You also have to make sure your ISP isn't transparently capturing your DNS packets, which they probably are.
Oddly they never say that DNSCrypt encrypts your DNS traffic, just that it's cryptographically secure.
The OpenDNS page on DNSCrypt does state that traffic is encrypted.
Confusing...
The OpenDNS page on DNSCrypt does state that traffic is encrypted.
Confusing...
I'm a bit rusty, and not to knock DNSCrypt or change the subject, but in the past I did a lot of reading and came to the conclusion that DNSCurve is the thing we should be pushing to adopt instead, due to some inherent flaws in DNSCrypt/DNSSEC.
To me, DNS is the current primary weakness of the internet in it's modern form, mainly due to centralization. I think we should also be focused more on secure connection techniques independent of the DNS system.
To me, DNS is the current primary weakness of the internet in it's modern form, mainly due to centralization. I think we should also be focused more on secure connection techniques independent of the DNS system.
DNSCrypt is unrelated to DNSSEC.
Wasn't saying it was, perhaps I could have worded that more carefully.
In case nobody has pointed it out yet.
By default, with Ubuntu's dnscrypt-proxy package - the resolver is "cisco".
That's right, you're encrypting your DNS traffic just so Cisco can read it...
There are alternate resolvers but most people wouldn't change it out of the box.
By default, with Ubuntu's dnscrypt-proxy package - the resolver is "cisco".
That's right, you're encrypting your DNS traffic just so Cisco can read it...
There are alternate resolvers but most people wouldn't change it out of the box.
Cisco doesn't log the traffic. Don't believe me, just ask davidu who founded OpenDNS and resides at Cisco.
Is there any plan to let smartphones, both Android and iOS, tu support changing the DNS at system level without rooting the device? So that it works with cellular data and that you don't need to change it for every wifi?
I am waiting for this as well.
The default port of 443 is somewhat bizarre, it's almost guaranteed to conflict on a server. They could have applied to IETF / IANA for port 253 (it currently reserved / unassigned).
As long as you can set it on both ends it doesn't really matter. It's actually better for clients that the servers listen on 443.
If it conflicts then that means you're putting multiple services on your server. Don't.
Personally I've put dnscrypt on my regular dns servers, they only listen on 53.
If it conflicts then that means you're putting multiple services on your server. Don't.
Personally I've put dnscrypt on my regular dns servers, they only listen on 53.
It is intentional. There are creepy providers out there that really want you to use their DNS so they can surveil/gaslight you, so they block or redirect traffic to well-known DNS ports.
Putting it on 443 forces a choice between letting people manage their own DNS or blocking every store on the planet.
Putting it on 443 forces a choice between letting people manage their own DNS or blocking every store on the planet.
Definitely this. Also lots of weird hardware/software out there that tends to discard packets it can't understand (i.e. this doesn't look like a DNS packet going to port 53, let's drop it.) 443 generally works as it is expected to be encrypted by most middleware.
I would also say that most DNSCrypt-capable providers I know of can also do it on port 53.
I would also say that most DNSCrypt-capable providers I know of can also do it on port 53.
This looks like a great option to validate the seed IP's used to connect to the bitcoin p2p network have not been tampered with. As would be possible with a plain text DNS lookup.
When you use a VPN (OpenVPN) is there still a way to use DNSCrypt? My VPN provider seems to force their own DNS. Tried OpenVPN config manual pages to no help.
Manually updating you network settings after connecting will do the trick.
Use --script-security and --up if you'd like to script the DNS update and have it run everytime after you connect
Use --script-security and --up if you'd like to script the DNS update and have it run everytime after you connect
This was the original.
Other than having to modify their ksh script, it is painless to set up.
In my opinion, authoritative nameservers, and therefore DNSCurve forwarders like CurveDNS, are more important than recursive resolvers/caches such as OpenDNS and DNSCrypt.
A recursive resolver should be authoritative for nothing. They are middlemen. Companies that offered this "service", such as OpenDNS, had to pander to advertisers, or were run by advertising companies themselves, e.g., Google.
The "rules" of DNS are easily broken. This applies to caches. One does not need to look very far to find resolvers that someone has designated as "authoritative". dnsq: "weird ra". This often means an open resolver IME.
A while back some companies including the ones named above if I am not mistaken were pushing for extensions in DNS to put at least part of user IP addresses into DNS packets so cache operators could track them. The reason? Advertising. (Although maybe they would cite other reasons.) Not sure what ever happened with that. BIND had started to implement it. Thankfully djbdns will never support this garbage.
This kind of nonsense is why I cannot get excited about the latest extensions to internet protocols anymore.
Too often they are for the benefit of web companies and advertisers, not users.
The "encrypted DNS revolution", if it ever comes, is not going to be initiated by companies running recursive resolvers. (Unless they also run authoritative nameservers.)
Note: When the user runs their own cache on localhost there is no need to determine nearest POP.