10 ms·

DNSSEC is designed to prevent DNS spoofing attacks, or DNS cache poisoning, not to prevent malicious actors from sniffing your DNS queries. I'm curious as to w

DNSSEC is designed to prevent DNS spoofing attacks, or DNS cache poisoning, not to prevent malicious actors from sniffing your DNS queries. I'm curious as to what you think the downside of deploying DNSSEC is. I use DNSSEC Validator(https://www.dnssec-validator.cz/ https://www.dnssec-validator.cz/) for Firefox and I like seeing when a webhost's DNS entry validates. Certain sites I visit regularly do validate, while others don't. If it ever happens that I'm on a public wifi network and I visit a site which I know regularly validates, but fails this time, then DNSSEC will have done its job. As more operators deploy DNSSEC more sites will validate, thereby allowing me to trust more DNS responses when I'm on a public network.

tptacek 12y ago
* It's complicated to deploy and misconfigurations cause outages, and those outages get more severe the more people deploy DNSSEC. * It sucks up all the oxygen from the effort to actually mitigate flaws in the DNS. The most important DNS security flaw is the last-mile problem between browsers and nameservers, and DNSSEC has practically nothing to say about that. DNSCurve, as a counterexample, does solve this problem, and it solves it regardless of whether 1 person deploys it or 300 million do. But all the oxygen has been stolen by DNSSEC. * It provides a setting for us to transition the CA system from untrustworthy companies directly to world governments, with the most commercially important domain names giving CA-like authority to (wait for it) the US government. * Any way you try to project the math out, it will be ludicrously expensive to deploy (the deployment numbers we see today are, effectively, trial/pilot deployments, since virtually no end-user software cares about DNSSEC). * Speaking of expensive: since virtually no modern networking software is built on the assumption that there can be (a) transient (b) security failures for DNS lookups, actually deploying DNSSEC is going to require forklift upgrades to huge amounts of already deployed code. Just to make that clear: imagine you're still using gethostbyname() to look up names, like lots of code does. How does your lookup code change to accommodate the fact that a query can, under DNSSEC, (a) fail (b) despite the fact that there was a response to the query with a usable record? TLS solves this with a pop-up dialog. Where does the dialog go? * The most common mode of deployment for DNSSEC leaks hostnames; it essentially re-enables public zone transfers. To avoid this problem, you can theoretically deploy minimum-covering NSEC ("whitelies"), but despite the fact that this is the only "safe" way to deploy DNSSEC, it's not the default. Why? Because whitelies requires online keys, and the original premise of DNSSEC was to keep keys offline. Net result: many many deployers of DNSSEC --- should we be so unfortunate as to have many deployers of DNSSEC --- will accidentally leak the contents of their zones to the Internet. This is a subset of the reasons I don't like DNSSEC (a more significant one to me is that I believe it's cryptographically obsolete); it's just the subset that, off the top of my head, I think demonstrates the harm DNSSEC would do beyond simply not solving the problem it ostensibly solves.
- danyork 12y ago
  Thomas, responding to some of your points: > * It's complicated to deploy and misconfigurations cause outages, and those outages get more severe the more people deploy DNSSEC. I would dispute that. Pretty much all of the authoritative name servers (Bind, NSD, Windows, Knot) have made the signing service a few lines in a configuration file. YES, there are operational steps you need to put in place, primarily related to KSK rollovers, but the actual deployment is pretty simple these days. Similarly, on the validation side, deploying DNSSEC validation is basically one line in a config file for BIND and Unbound and a little bit more in Windows Server 2012. It's simple to deploy. > * It sucks up all the oxygen from the effort to actually mitigate flaws in the DNS. The most important DNS security flaw is the last-mile problem between browsers and nameservers That may be the most important issue to YOU, but to others ensuring the integrity of the DNS info is more important. > * It provides a setting for us to transition the CA system from untrustworthy companies directly to world governments Huh? I keep hearing DNSSEC critics bring this up and I've yet to have anyone truly explain how this can happen. > * Any way you try to project the math out, it will be ludicrously expensive to deploy (the deployment numbers we see today are, effectively, trial/pilot deployments, since virtually no end-user software cares about DNSSEC). There are 18 million customers of Comcast in North America who are receiving the integrity protection of DNSSEC. Every Comcast user is having every DNS query validated by DNSSEC. Please take a moment to look at the stats off of this page: http://gronggrong.rand.apnic.net/cgi-bin/ccpage?c=XA&x=1&g=0&r=1&w=7 http://gronggrong.rand.apnic.net/cgi-bin/ccpage?c=XA&x=1&g=0... (which I know you've seen because we've discussed this on Twitter). There are very real deployments of DNSSEC validation happening around the globe. I've run out of time right now to answer... and the reality is that you and I could probably just go back and forth on this for quite some time. You don't like DNSSEC. I like DNSSEC for solving the problems it does (and also for providing additional capabilities such as DANE).
  - tptacek 12y ago
    Trust in DNSSEC rolls up the DNS hierarchy, the top of which is overwhelmingly controlled by governments. I'm at a loss to see why this isn't an obvious problem to you.

tptacek 12y ago

* It's complicated to deploy and misconfigurations cause outages, and those outages get more severe the more people deploy DNSSEC. * It sucks up all the oxygen from the effort to actually mitigate flaws in the DNS. The most important DNS security flaw is the last-mile problem between browsers and nameservers, and DNSSEC has practically nothing to say about that. DNSCurve, as a counterexample, does solve this problem, and it solves it regardless of whether 1 person deploys it or 300 million do. But all the oxygen has been stolen by DNSSEC. * It provides a setting for us to transition the CA system from untrustworthy companies directly to world governments, with the most commercially important domain names giving CA-like authority to (wait for it) the US government. * Any way you try to project the math out, it will be ludicrously expensive to deploy (the deployment numbers we see today are, effectively, trial/pilot deployments, since virtually no end-user software cares about DNSSEC). * Speaking of expensive: since virtually no modern networking software is built on the assumption that there can be (a) transient (b) security failures for DNS lookups, actually deploying DNSSEC is going to require forklift upgrades to huge amounts of already deployed code. Just to make that clear: imagine you're still using gethostbyname() to look up names, like lots of code does. How does your lookup code change to accommodate the fact that a query can, under DNSSEC, (a) fail (b) despite the fact that there was a response to the query with a usable record? TLS solves this with a pop-up dialog. Where does the dialog go? * The most common mode of deployment for DNSSEC leaks hostnames; it essentially re-enables public zone transfers. To avoid this problem, you can theoretically deploy minimum-covering NSEC ("whitelies"), but despite the fact that this is the only "safe" way to deploy DNSSEC, it's not the default. Why? Because whitelies requires online keys, and the original premise of DNSSEC was to keep keys offline. Net result: many many deployers of DNSSEC --- should we be so unfortunate as to have many deployers of DNSSEC --- will accidentally leak the contents of their zones to the Internet. This is a subset of the reasons I don't like DNSSEC (a more significant one to me is that I believe it's cryptographically obsolete); it's just the subset that, off the top of my head, I think demonstrates the harm DNSSEC would do beyond simply not solving the problem it ostensibly solves.

danyork 12y ago
Thomas, responding to some of your points: > * It's complicated to deploy and misconfigurations cause outages, and those outages get more severe the more people deploy DNSSEC. I would dispute that. Pretty much all of the authoritative name servers (Bind, NSD, Windows, Knot) have made the signing service a few lines in a configuration file. YES, there are operational steps you need to put in place, primarily related to KSK rollovers, but the actual deployment is pretty simple these days. Similarly, on the validation side, deploying DNSSEC validation is basically one line in a config file for BIND and Unbound and a little bit more in Windows Server 2012. It's simple to deploy. > * It sucks up all the oxygen from the effort to actually mitigate flaws in the DNS. The most important DNS security flaw is the last-mile problem between browsers and nameservers That may be the most important issue to YOU, but to others ensuring the integrity of the DNS info is more important. > * It provides a setting for us to transition the CA system from untrustworthy companies directly to world governments Huh? I keep hearing DNSSEC critics bring this up and I've yet to have anyone truly explain how this can happen. > * Any way you try to project the math out, it will be ludicrously expensive to deploy (the deployment numbers we see today are, effectively, trial/pilot deployments, since virtually no end-user software cares about DNSSEC). There are 18 million customers of Comcast in North America who are receiving the integrity protection of DNSSEC. Every Comcast user is having every DNS query validated by DNSSEC. Please take a moment to look at the stats off of this page: http://gronggrong.rand.apnic.net/cgi-bin/ccpage?c=XA&x=1&g=0&r=1&w=7 http://gronggrong.rand.apnic.net/cgi-bin/ccpage?c=XA&x=1&g=0... (which I know you've seen because we've discussed this on Twitter). There are very real deployments of DNSSEC validation happening around the globe. I've run out of time right now to answer... and the reality is that you and I could probably just go back and forth on this for quite some time. You don't like DNSSEC. I like DNSSEC for solving the problems it does (and also for providing additional capabilities such as DANE).
- tptacek 12y ago
  Trust in DNSSEC rolls up the DNS hierarchy, the top of which is overwhelmingly controlled by governments. I'm at a loss to see why this isn't an obvious problem to you.