Using DNSSEC and DNSCrypt in Debian(feeding.cloud.geek.nz)
feeding.cloud.geek.nz
Using DNSSEC and DNSCrypt in Debian
http://feeding.cloud.geek.nz/posts/using-dnssec-and-dnscrypt-in-debian/
2 comments
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.
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.
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.
If you feel any of my arguments are "mischaracterized", you are welcome to try to rebut them.
DNSSEC is useful for SMTP SSL encryption (at least from you to your server).
https://blog.filippo.io/the-sad-state-of-smtp-encryption/
https://blog.filippo.io/the-sad-state-of-smtp-encryption/
Nope! They fixed that: there's now SMTP Strict Transport Security, sponsored by Google, Microsoft, and Yahoo. SMTP STS explicitly does not require DNSSEC --- because nobody thinks at-scale DNSSEC is going to happen anymore.
Isn't this still a draft? Also, it does not fix MX record spoofing, only downgrade attacks IIRC?
EDIT: Just reviewed the draft, seems like it addresses MX spoofing, but it seems to do it either via HTTPS or DNSSEC, so DNSSEC seems to be used by it
EDIT: Just reviewed the draft, seems like it addresses MX spoofing, but it seems to do it either via HTTPS or DNSSEC, so DNSSEC seems to be used by it
What does "still a draft" mean? That a bunch of randos at IETF haven't approved it yet? Three of the most important email providers on the planet sponsored it. It's what's going to happen.
It means it's not implemented in most SMTP clients/SMTP servers. The randos have a huge impact.
Not everyone uses Gmail/Outlook
Not everyone uses Gmail/Outlook
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?
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?
> 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?
How have you authenticated that your ISP isn't intercepting DNS requests and serving them out of their own cache that lies?
Connecting to the remote service and validating the ssl cert.
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.
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.
Where does your local DNS cache gets the record from ? Unless you can verify the information is legit it actually aggravates the problem. Now any MITM can poison your computer for the duration of the cache TTL whereas before they had to maintain the MITM or poison upstream for the same effect.
http://sockpuppet.org/blog/2015/01/15/against-dnssec/