5 ms·

> Essentially, all you're signing up for when you use a 3rd-party DNSSEC server is that someone's misconfiguration is silently going to break your queries. Isn

by growse 12y ago

> Essentially, all you're signing up for when you use a 3rd-party DNSSEC server is that someone's misconfiguration is silently going to break your queries. Isn't this literally true of any service? > What's especially funny about this is that your DNS queries to these third-party servers are not themselves encrypted; This would be relevent if people were aiming to protect the confidentiality of their DNS queries. They're not though. They're trying to protect the integrity of the DNS queries. Anyhow, I find it useful in that I can store SSHFP records in my DNS zone and then use `VerifyHostKeyDNS` when I'm sshing into servers. This becomes especially useful if I've got servers sshing into other servers and I don't want to have to lug around a known_hosts file on every server. Saying things like "using DNSSEC is pure downside" is so easily demonstrably false and hyperbolic that it may cause people to ignore the rest of your argument. Which is a shame, because I know you have very insightful and interesting things to say about a lot of things.

tptacek 12y ago
I believe DNSSEC is, across the board, pure downside. But that statement is especially true here, in the case of a third-party resolver with DNSSEC enabled. And that's the case I was talking about. I don't think we have to reach the wisdom of SSHFP records to refute your rebuttal.
- opendais 12y ago
  https://eprint.iacr.org/2010/115.pdf https://eprint.iacr.org/2010/115.pdf I'm just going to leave this here and let people make up their own minds. I don't really have an opinion but I think you are being excessively negative without presenting any evidence.
  - tptacek 12y ago
    I don't understand what this paper is supposed to indicate. It's a survey and critique of DNSSEC (as a protocol).
  - cnst 12y ago
    http://cr.yp.to/talks.html#2009.08.11 http://cr.yp.to/talks.html#2009.08.11 Downsides of DNSSEC are pretty well known, actually. If you're worried about security yet still want to use a third-party DNS resolver, might much better off with OpenDNS.com and their DNSCurve client (called DNSCrypt), which encrypts and authenticates all communications. http://blog.opendns.com/2010/02/23/opendns-dnscurve/ http://blog.opendns.com/2010/02/23/opendns-dnscurve/ http://www.opendns.com/about/innovations/dnscrypt/ http://www.opendns.com/about/innovations/dnscrypt/
jingo 12y ago
"They're trying to protect the integrity of the DNS queries." Then why are they using a DNS cache run by a third party (who they do not know) on the open internet, and shared with other users they do not know? The entire focus on DNS insecurity that brought about the renewed interest in "DNSSEC" can be traced to a "cache poisoning" scare back in 2008. The rational response to that aspect of DNS insecurity is to move away from shared DNS caches on the open internet, aka "open resolvers". If "integrity" were the goal, then I would think downloading a trusted copy of the root.zone and running your own root and DNS cache on localhost would be a better approach. Additionally, if you have many double-digit GB's to spare, you could add in copies of the com, net, or org zones. Allowing users to download trusted copies of these is required by the ICANN rules. Alas, Country Code TLD's are not governed by these rules. Imagine if the telephone company would not allow you to have a copy of the telephone book and said you could only call the operator when you needed to look up a telephone number. That's what it's like when public registries withhold zone files. But I digress... Setting up and maintaining a local DNS cache is a lot easier than setting up DNSSEC. Really, the only queries you need to be sending out over the open internet are ones to the third party authoritative nameservers that are responsible for the information you are after. That means non-recursive queries only. I have been doing this for years and it works beautifully. In some cases, it can be faster to make only a series of non-recursive queries to authoritative nameservers than to make a recursive one to a cache. I also store the DNS information for hosts I know I might revisit in HOSTS and zone files. This minimizes my need to use DNS. And looking up information in HOSTS and zone files (in cdb format) is always faster than third party DNS. Once you have achieved this sort of localized setup, and you no longer rely on third parties for DNS (e.g. such as OpenDNS, GoogleDNS, DNS.Watch, etc.), then you may come to the conclusion that the more important DNS security issues are 1. how to verify that the authoritative nameservers you query are the right ones (not imposters), and then 2. how to secure the packets you exchange with the authoritative nameservers. There is a finished solution available for 2, but not for 1. Unless you think delegating 1 to a third party is a "solution" (e.g., PKI, CA's managed by third parties like Verisign, etc.). Lastly, even if you do not care much or at all about DNS security, there are gains in reliability and sometimes performance to be had by using a local cache (and ideally as much locally stored DNS information as possible) versus using a third party cache on the open internet. You get the additonal security of not using shared caches (i.e. minimized risk of cache poisoning) "for free."

by growse 12y ago

tptacek 12y ago

I believe DNSSEC is, across the board, pure downside. But that statement is especially true here, in the case of a third-party resolver with DNSSEC enabled. And that's the case I was talking about. I don't think we have to reach the wisdom of SSHFP records to refute your rebuttal.

opendais 12y ago
https://eprint.iacr.org/2010/115.pdf https://eprint.iacr.org/2010/115.pdf I'm just going to leave this here and let people make up their own minds. I don't really have an opinion but I think you are being excessively negative without presenting any evidence.
- tptacek 12y ago
  I don't understand what this paper is supposed to indicate. It's a survey and critique of DNSSEC (as a protocol).
- cnst 12y ago
  http://cr.yp.to/talks.html#2009.08.11 http://cr.yp.to/talks.html#2009.08.11 Downsides of DNSSEC are pretty well known, actually. If you're worried about security yet still want to use a third-party DNS resolver, might much better off with OpenDNS.com and their DNSCurve client (called DNSCrypt), which encrypts and authenticates all communications. http://blog.opendns.com/2010/02/23/opendns-dnscurve/ http://blog.opendns.com/2010/02/23/opendns-dnscurve/ http://www.opendns.com/about/innovations/dnscrypt/ http://www.opendns.com/about/innovations/dnscrypt/

jingo 12y ago

"They're trying to protect the integrity of the DNS queries." Then why are they using a DNS cache run by a third party (who they do not know) on the open internet, and shared with other users they do not know? The entire focus on DNS insecurity that brought about the renewed interest in "DNSSEC" can be traced to a "cache poisoning" scare back in 2008. The rational response to that aspect of DNS insecurity is to move away from shared DNS caches on the open internet, aka "open resolvers". If "integrity" were the goal, then I would think downloading a trusted copy of the root.zone and running your own root and DNS cache on localhost would be a better approach. Additionally, if you have many double-digit GB's to spare, you could add in copies of the com, net, or org zones. Allowing users to download trusted copies of these is required by the ICANN rules. Alas, Country Code TLD's are not governed by these rules. Imagine if the telephone company would not allow you to have a copy of the telephone book and said you could only call the operator when you needed to look up a telephone number. That's what it's like when public registries withhold zone files. But I digress... Setting up and maintaining a local DNS cache is a lot easier than setting up DNSSEC. Really, the only queries you need to be sending out over the open internet are ones to the third party authoritative nameservers that are responsible for the information you are after. That means non-recursive queries only. I have been doing this for years and it works beautifully. In some cases, it can be faster to make only a series of non-recursive queries to authoritative nameservers than to make a recursive one to a cache. I also store the DNS information for hosts I know I might revisit in HOSTS and zone files. This minimizes my need to use DNS. And looking up information in HOSTS and zone files (in cdb format) is always faster than third party DNS. Once you have achieved this sort of localized setup, and you no longer rely on third parties for DNS (e.g. such as OpenDNS, GoogleDNS, DNS.Watch, etc.), then you may come to the conclusion that the more important DNS security issues are 1. how to verify that the authoritative nameservers you query are the right ones (not imposters), and then 2. how to secure the packets you exchange with the authoritative nameservers. There is a finished solution available for 2, but not for 1. Unless you think delegating 1 to a third party is a "solution" (e.g., PKI, CA's managed by third parties like Verisign, etc.). Lastly, even if you do not care much or at all about DNS security, there are gains in reliability and sometimes performance to be had by using a local cache (and ideally as much locally stored DNS information as possible) versus using a third party cache on the open internet. You get the additonal security of not using shared caches (i.e. minimized risk of cache poisoning) "for free."