
Using DNSSEC and DNSCrypt in Debian - ashitlerferad
http://feeding.cloud.geek.nz/posts/using-dnssec-and-dnscrypt-in-debian/
======
tptacek
DNSCrypt is marginally useful. But don't bother with DNSSEC. It does more harm
than good.

[http://sockpuppet.org/blog/2015/01/15/against-
dnssec/](http://sockpuppet.org/blog/2015/01/15/against-dnssec/)

~~~
AndyMcConachie
Every time there's an article on DNSSEC here I find you bringing out the same
mischaracterized arguments against it.

If you are ever in the Washington DC area I would be happy to take you out to
dinner/beers and have a long friendly conversation about DNSSEC and why you
dislike it so much. I'm completely serious, and I'm paying.

~~~
tptacek
DNSSEC is a terrible idea, and articles encouraging people to set it up and
describing the security benefits that work will bring deserve an informed
rebuttal.

If you feel any of my arguments are "mischaracterized", you are welcome to try
to rebut them.

~~~
lwhalen
Alright, I'll bite: I run a small personal network from soup to nuts - I host
the DNS, the web server(s), the mail server(s), you name it. Why should I not
set up DNSSEC - what's the downside for me?

~~~
tptacek
See above blog post.

------
wsfull
If you are using your own DNS cache listening on a loopback interface, then
the risks of "DNS cache poisoning" are not what they are when you use a third
party cache like your ISP's, OpenDNS, Google or the ones in the CSV file at
the github page referenced in this blog entry.

Unless you are sharing your loopback with the network somehow, one could argue
that with a localhost cache the risk is nonexistent.

According to this blog entry the reason for using DNSSEC is to "prevent DNS
posioning".

If that is true, and that is what I would expect, and we've minimized the risk
of cache poisoning by using a localhost cache exlcusively (no third party
caches), then why use DNSSEC?

If there are other reasons, like making centralized control (censorship?) of
DNS easier for ICANN, etc., then this blog post has omitted them. Does that
imply they are insignificant?

~~~
wtallis
> If that is true, and that is what I would expect, and we've minimized the
> risk of cache poisoning by using a localhost cache exlcusively (no third
> party caches), then why use DNSSEC?

How have you authenticated that your ISP isn't intercepting DNS requests and
serving them out of their own cache that lies?

~~~
regularfry
Connecting to the remote service and validating the ssl cert.

~~~
wsfull
Yes.

As yet, there's still no foolproof way to verify/authenticate an endpoint on
the internet. Not to mention the issue of so-called "host security".

Checking for a file on the remote host, e.g., a cert or a key a la ssh, seems
to me a more sensible approach than relying solely on the promises of a
"trusted third party" (CA's, ICANN, registrars, etc.) that you have never met.

Fears of ISP's intercepting port 53 traffic was not the reason why DNSSEC was
revived from the failed protocol graveyard. ISP's do not have to go through
the trouble. Most of their customers have the ISP's resolver addresses in
their DNS settings, not a loopback address.

And although the software is available almost no ISP customers are encrypting
their DNS packets.

DNS data for the public www is public information like the telephone book. It
is easy to obtain. And once you have it, not only can you monitor changes, but
there's little need to even run a cache.

You can just pluck out the names you need and plug them into your own
authoritative server. Edit resolv.conf to point to it and you're done.

Easy way to speed up your www browsing and still very effective at blocking
ads, apps phoning home, etc.

