3 ms·

You really think resolvers are going to be willing to forge the AD (authenticated data) bit when the data isn't authenticated? Even when it's so easy for a clie

by trotsky 16y ago

You really think resolvers are going to be willing to forge the AD (authenticated data) bit when the data isn't authenticated? Even when it's so easy for a client or downstream caching only server to be set to validating and thus discover the forgery? Once you've determined that your server is willing to forge AD surely you'd have no reason to trust any other response it gives. DNSSEC deployment seems to be going rather well to me, compared to a year ago the root servers are signing, several major TLD's are signed, and common registrars support signed zones in those TLDs. Individual zone signing really isn't that difficult, and besides, almost everyone uses third party DNS hosting. Once a few major DNS hosters start signing zones by default you'll see adoption skyrocketing, don't you think?

davidu 16y ago
No. tptacek is entirely correct. DNSSEC won't help here. DNSSEC is not exposed to applications the way SSL is and so you will never see widespread adoption. Take Chrome for example. Chrome is in the best position to make use of DNSSEC since it does it's own resolving, and even they don't see the value in it. They may do it in the background, but they won't make it user visible any time soon. Reasons from Chrome devs are very well articulated here: http://code.google.com/p/chromium/issues/detail?id=50874 http://code.google.com/p/chromium/issues/detail?id=50874 That said, I do believe that stub resolvers will go away, with every client running a full-blown recursor, but that still won't make DNSSEC solve the problems that need solving.
- trotsky 16y ago
  It would seem relevant to note that your company openDNS has publicly promoted and rolled out DNSCurve, a non-IETF track set of extensions to DNS intended to compete with DNSSEC. DNSCurve makes no attempt to authenticate the source of the DNS data and instead relies on only securing the connection between the the client and server (or server and server). In this way, DNSCurve does not prevent a service provider like openDNS from replacing NXDOMAIN returns with their own sponsored pages. DNSSEC instead aims to "protect DNS content from third party modification" which would include third parties like openDNS. Performing this modification is the basis of DNS redirection. OpenDNS's strong complaints about DNSSEC and adoption of an obscure replacement (DNSCurve - About 6,620 results; DNSSEC - About 6,730,000 results) would seem to confirm my original suggestion much better than I can do myself. Paul Vixie on the matter: The problem statement for DNSSEC was: "how can we protect DNS content from third party modification?" The first parties in this case are the the zone administrator who produces the primary zone content and the ultimate end user or application who consumes that content. Third parties include Dan Kaminsky or anyone else who might bombard a client with spoofed replies attempting to guess transaction ID's and port numbers; secondary name server operators or hackers who break into those systems; recursive name server operators who may want to rewrite www.google.com to their own search page or to rewrite negative responses to point to their own advertising servers; firewall and IDS operators who might want to rewrite all answers containing profanity or pornography or other illicit content to point at a walled garden. From DNSSEC's point of view, only the zone administrator should be able to produce content within the namespace of a zone. There are no exceptions. http://www.isc.org/community/blog/201002/whither-dnscurve http://www.isc.org/community/blog/201002/whither-dnscurve
  - blasdel 16y ago
    Wow, that does a lot to confirm my initial impression of them: Neither 'open' nor DNS
  - davidu 16y ago
    I strongly disagree with the notion that only the zone owner should be able to generate records for it. Nothing else on the Internet behaves like that. And anyways, Paul has changed his thinking since then on this subject too. He now prefers the model that OpenDNS has done since 2005: http://www.isc.org/community/blog/201007/taking-back-dns-0 http://www.isc.org/community/blog/201007/taking-back-dns-0 He may disagree with the NXDOMAIN wildcard that we do (which we will probably phase out in the long run anyways) but there is no question that allowing end-users to control their responses as they see fit makes tremendous sense. Do you think you should have to receive all email sent to your mail server? Of course not. Why should DNS be any different? Your network, your rules.
    - trotsky 16y ago
      I'm confused as to why you claim DNSSEC removes user choice. Clearly any client that wishes to can simply fail to set DO and ED and will receive a traditional, non-validated response. If the client identifies that they wish authenticated data, they still have plenty of opportunities to act once they receive the authentic zone response. You mention mail host blacklisting, but typical DNS based blacklists have always been based on secondary lookups ie - 1.2.3.4.dnsbl.example.com - and not by forging the originator domain records. I'm returning signed content from my server to an end user, whether I am a root server, tld, or single domain server. There is no more reason you should have the authority to alter that data than there would be if I was returning an HTTPS response. It's only in the case where the client explicitly asks you to provide authenticated original zone data but you wish to return to them unauthenticated and modified zone data that you run into problems with DNSSEC.
      - davidu 16y ago
        Actually, you are not returning signed content from your server to an end user. End users are stub resolvers, which are not DNSSEC aware. I believe that should change, as I mentioned previously, but even the DNSSEC proponents pretend to assume the edge is DNSSEC-aware. It most certainly was and is not from their design and implementation stand-point. A position I find ridiculous. But back to your point -- Of course, we could support DNSSEC and validate responses and then modify them as we see fit. Which is exactly why DNSSEC does not prevent our service from working. We already have some of the largest companies in the world forwarding DNS to us, when we enable DNSSEC validation for them, nothing will change. FWIW, none of them have us wildcard NXDOMAIN responses either, which is not surprising. They do have us block content, however. Some of these are Fortune 50 companies, btw.

by trotsky 16y ago

davidu 16y ago

No. tptacek is entirely correct. DNSSEC won't help here. DNSSEC is not exposed to applications the way SSL is and so you will never see widespread adoption. Take Chrome for example. Chrome is in the best position to make use of DNSSEC since it does it's own resolving, and even they don't see the value in it. They may do it in the background, but they won't make it user visible any time soon. Reasons from Chrome devs are very well articulated here: http://code.google.com/p/chromium/issues/detail?id=50874 http://code.google.com/p/chromium/issues/detail?id=50874 That said, I do believe that stub resolvers will go away, with every client running a full-blown recursor, but that still won't make DNSSEC solve the problems that need solving.

trotsky 16y ago
It would seem relevant to note that your company openDNS has publicly promoted and rolled out DNSCurve, a non-IETF track set of extensions to DNS intended to compete with DNSSEC. DNSCurve makes no attempt to authenticate the source of the DNS data and instead relies on only securing the connection between the the client and server (or server and server). In this way, DNSCurve does not prevent a service provider like openDNS from replacing NXDOMAIN returns with their own sponsored pages. DNSSEC instead aims to "protect DNS content from third party modification" which would include third parties like openDNS. Performing this modification is the basis of DNS redirection. OpenDNS's strong complaints about DNSSEC and adoption of an obscure replacement (DNSCurve - About 6,620 results; DNSSEC - About 6,730,000 results) would seem to confirm my original suggestion much better than I can do myself. Paul Vixie on the matter: The problem statement for DNSSEC was: "how can we protect DNS content from third party modification?" The first parties in this case are the the zone administrator who produces the primary zone content and the ultimate end user or application who consumes that content. Third parties include Dan Kaminsky or anyone else who might bombard a client with spoofed replies attempting to guess transaction ID's and port numbers; secondary name server operators or hackers who break into those systems; recursive name server operators who may want to rewrite www.google.com to their own search page or to rewrite negative responses to point to their own advertising servers; firewall and IDS operators who might want to rewrite all answers containing profanity or pornography or other illicit content to point at a walled garden. From DNSSEC's point of view, only the zone administrator should be able to produce content within the namespace of a zone. There are no exceptions. http://www.isc.org/community/blog/201002/whither-dnscurve http://www.isc.org/community/blog/201002/whither-dnscurve
- blasdel 16y ago
  Wow, that does a lot to confirm my initial impression of them: Neither 'open' nor DNS
- davidu 16y ago
  I strongly disagree with the notion that only the zone owner should be able to generate records for it. Nothing else on the Internet behaves like that. And anyways, Paul has changed his thinking since then on this subject too. He now prefers the model that OpenDNS has done since 2005: http://www.isc.org/community/blog/201007/taking-back-dns-0 http://www.isc.org/community/blog/201007/taking-back-dns-0 He may disagree with the NXDOMAIN wildcard that we do (which we will probably phase out in the long run anyways) but there is no question that allowing end-users to control their responses as they see fit makes tremendous sense. Do you think you should have to receive all email sent to your mail server? Of course not. Why should DNS be any different? Your network, your rules.
  - trotsky 16y ago
    I'm confused as to why you claim DNSSEC removes user choice. Clearly any client that wishes to can simply fail to set DO and ED and will receive a traditional, non-validated response. If the client identifies that they wish authenticated data, they still have plenty of opportunities to act once they receive the authentic zone response. You mention mail host blacklisting, but typical DNS based blacklists have always been based on secondary lookups ie - 1.2.3.4.dnsbl.example.com - and not by forging the originator domain records. I'm returning signed content from my server to an end user, whether I am a root server, tld, or single domain server. There is no more reason you should have the authority to alter that data than there would be if I was returning an HTTPS response. It's only in the case where the client explicitly asks you to provide authenticated original zone data but you wish to return to them unauthenticated and modified zone data that you run into problems with DNSSEC.
    - davidu 16y ago
      Actually, you are not returning signed content from your server to an end user. End users are stub resolvers, which are not DNSSEC aware. I believe that should change, as I mentioned previously, but even the DNSSEC proponents pretend to assume the edge is DNSSEC-aware. It most certainly was and is not from their design and implementation stand-point. A position I find ridiculous. But back to your point -- Of course, we could support DNSSEC and validate responses and then modify them as we see fit. Which is exactly why DNSSEC does not prevent our service from working. We already have some of the largest companies in the world forwarding DNS to us, when we enable DNSSEC validation for them, nothing will change. FWIW, none of them have us wildcard NXDOMAIN responses either, which is not surprising. They do have us block content, however. Some of these are Fortune 50 companies, btw.