
DNSCrypt – A protocol to improve DNS security - geuis
https://dnscrypt.org
======
gwu78
I prefer [http://curvedns.on2it.net](http://curvedns.on2it.net)

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.

~~~
LogicX
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...](https://tools.ietf.org/html/draft-ietf-dnsop-edns-client-subnet-08)
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](https://tools.ietf.org/html/rfc7858)

~~~
geocar
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.

~~~
pfg
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)?

~~~
geocar
I don't have a server for them to hit directly: My DNS server always returns
NXDOMAIN.

------
arkadiyt
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.

~~~
openasocket
> 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.

~~~
wslh
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.

~~~
0xxon
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.

~~~
MertsA
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.

~~~
pixl97
>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.

------
hannob
Just pointing out, there's now a standardized way to do encrypted DNS via TLS:

[https://tools.ietf.org/html/rfc7858](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.

~~~
INTPenis
Why are you being downvoted?

[https://kb.isc.org/article/AA-01386/30/DNS-over-
TLS.html](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.

~~~
Tepix
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.

~~~
INTPenis
What's a good alternative open source DNS that supports views and DDNS
updates?

~~~
_jal
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.

------
singularity2001
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

~~~
Tepix
This only moves the problem slightly. You then have to trust the network
surrounding your SSH box.

~~~
_jal
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.

------
mike-cardwell
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:

    
    
      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.

~~~
pixl97
>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.

------
cptskippy
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...

------
arca_vorago
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.

~~~
tptacek
DNSCrypt is unrelated to DNSSEC.

~~~
arca_vorago
Wasn't saying it was, perhaps I could have worded that more carefully.

------
cryptolect
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.

~~~
feld
Cisco doesn't log the traffic. Don't believe me, just ask davidu who founded
OpenDNS and resides at Cisco.

------
riquito
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?

~~~
WadeJohnson
I am waiting for this as well.

------
tankenmate
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).

~~~
_jal
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.

~~~
tresni
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.

------
theveloped
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.

------
snowpanda
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.

~~~
coniptor
You need to upgrade to OpenVPN v 4.0 or greater. Then investigate the option
string below:

pull-filter ignore "dhcp-option DNS"

~~~
coniptor
Correction: 2.4.0 or greater.

