4 ms·

>if you're a Comcast customer, for example, they are performing DNSSEC validation for you transparently. Also, if you are using Google's public DNS (8.8.8.8),

by mino 10y ago

>if you're a Comcast customer, for example, they are performing DNSSEC validation for you transparently. Also, if you are using Google's public DNS (8.8.8.8), they are doing DNSSEC validation for you... that is a significant percentage of the Internet today.

tptacek 10y ago
So what? You yourself are speaking plain-ol'-DNS over the public Internet, probably using UDP packets, to some data center that happens to have a Google DNS server in it. Why do you trust that link? And if you do: what is DNSSEC doing for you? Google's DNS servers are the most heavily cached and carefully monitored on the Internet. Here we see the single most batshit aspect of DNSSEC: validation is done on the servers and not on the endpoints (you "can" do endpoint validation, in the same sense as you "can" run your own recursive caching server locally). This is a relic of the early-mid 1990s, when the core DNSSEC design was finalized and any kind of encryption was thought to be too expensive to deploy to end-systems. It's also the reason DNSSEC is signing-only, with no privacy protections. The people who made those decisions were wrong. It was in fact possible to predict that cycles-per-byte costs for encryption would be driven down a rounding error in just a dozen or so years. But we're still forced to live with that bad decision, because nobody in the IETF wants to admit they were wrong.
- mino 10y ago
  I was not implying the opposite (and I agree that all of this without end-to-end is less than effective), simply stating that DNSSEC is used much more than the parent assumes.
  - tptacek 10y ago
    Since very little of the Internet is DNSSEC-signed, I think it's used a lot less than you think it is.
    - okket 10y ago
      1493 TLDs in the root zone in total 1343 TLDs are signed; 1330 TLDs have trust anchors published as DS records in the root zone; 5 TLDs have trust anchors published in the ISC DLV Repository. http://stats.research.icann.org/dns/tld_report/ http://stats.research.icann.org/dns/tld_report/
      - tptacek 10y ago
        It matters that the TLDs are signed in the sense that DNSSEC is on its face a weird joke if BANKOFAMERICA.COM can get a signature, but .COM is itself not signed. After 20+ years of standardization effort, we finally reached the point just a few years ago where Bank of America could theoretically get a meaningful signature, because .COM was signed (chaining to an RSA-1024 signature!). But BANKOFAMERICA.COM is not signed. Nor is the overwhelming majority of the Internet. Most of the TLD's are signed, because they can be required to sign by fiat, and were. But for BANKOFAMERICA.COM to be signed, the market has to recognize some value for the effort of signing and then keeping the site signed (because if they screw it up somehow once they do sign, they'll be taken off the Internet by the small but unfortunately significant portion of end-users whose ISPs are, without them asking for it, validating DNSSEC lookups). Smart operators are unlikely to do anything like that, because they all saw (for instance) what happened to HBO NOW, which was unavailable to anyone with a Comcast connection on its launch day due to a DNSSEC glitch.
- bluejekyll 10y ago
  > Google's DNS servers are the most heavily cached and carefully monitored on the Internet Is your point that we trust Google's DNS too much? > most batshit aspect of DNSSEC: validation is done on the servers and not on the endpoints (you "can" do endpoint validation, in the same sense as you "can" run your own recursive caching server locally). You "can" and we "should" be validating this at the client. So why don't we start doing this? We should be beating on the security layer in DNS as heavily as we do with HTTPS and other TLS implementations. > This is a relic of the early-mid 1990s, when the core DNSSEC design was finalized and any kind of encryption was thought to be too expensive to deploy to end-systems. It's also the reason DNSSEC is signing-only, with no privacy protections. There are several proposals at this point that resolve the privacy issue, DNSCrypt, DNSCurve, and DNS over TLS. > But we're still forced to live with that bad decision, because nobody in the IETF wants to admit they were wrong Given the number of revisions to the DNS RFCs, specifically around DNSSec, I don't think it would be accurate that they didn't admit being wrong, people are constantly working to resolve issues with the system.
  - tptacek 10y ago
    If we're going to accept that shit is broken and we should go ahead and fix it, why can't we fix DNSSEC itself? It's a terrible, broken, already-obselete protocol that sees virtually no meaningful real-world deployment. Why would we spend tens of millions of dollars to deploy something we already know is broken.
    - bluejekyll 10y ago
      see my comment in a sibling thread: https://news.ycombinator.com/item?id=12392121 https://news.ycombinator.com/item?id=12392121

by mino 10y ago

tptacek 10y ago

So what? You yourself are speaking plain-ol'-DNS over the public Internet, probably using UDP packets, to some data center that happens to have a Google DNS server in it. Why do you trust that link? And if you do: what is DNSSEC doing for you? Google's DNS servers are the most heavily cached and carefully monitored on the Internet. Here we see the single most batshit aspect of DNSSEC: validation is done on the servers and not on the endpoints (you "can" do endpoint validation, in the same sense as you "can" run your own recursive caching server locally). This is a relic of the early-mid 1990s, when the core DNSSEC design was finalized and any kind of encryption was thought to be too expensive to deploy to end-systems. It's also the reason DNSSEC is signing-only, with no privacy protections. The people who made those decisions were wrong. It was in fact possible to predict that cycles-per-byte costs for encryption would be driven down a rounding error in just a dozen or so years. But we're still forced to live with that bad decision, because nobody in the IETF wants to admit they were wrong.

mino 10y ago
I was not implying the opposite (and I agree that all of this without end-to-end is less than effective), simply stating that DNSSEC is used much more than the parent assumes.
- tptacek 10y ago
  Since very little of the Internet is DNSSEC-signed, I think it's used a lot less than you think it is.
  - okket 10y ago
    1493 TLDs in the root zone in total 1343 TLDs are signed; 1330 TLDs have trust anchors published as DS records in the root zone; 5 TLDs have trust anchors published in the ISC DLV Repository. http://stats.research.icann.org/dns/tld_report/ http://stats.research.icann.org/dns/tld_report/
    - tptacek 10y ago
      It matters that the TLDs are signed in the sense that DNSSEC is on its face a weird joke if BANKOFAMERICA.COM can get a signature, but .COM is itself not signed. After 20+ years of standardization effort, we finally reached the point just a few years ago where Bank of America could theoretically get a meaningful signature, because .COM was signed (chaining to an RSA-1024 signature!). But BANKOFAMERICA.COM is not signed. Nor is the overwhelming majority of the Internet. Most of the TLD's are signed, because they can be required to sign by fiat, and were. But for BANKOFAMERICA.COM to be signed, the market has to recognize some value for the effort of signing and then keeping the site signed (because if they screw it up somehow once they do sign, they'll be taken off the Internet by the small but unfortunately significant portion of end-users whose ISPs are, without them asking for it, validating DNSSEC lookups). Smart operators are unlikely to do anything like that, because they all saw (for instance) what happened to HBO NOW, which was unavailable to anyone with a Comcast connection on its launch day due to a DNSSEC glitch.
bluejekyll 10y ago
> Google's DNS servers are the most heavily cached and carefully monitored on the Internet Is your point that we trust Google's DNS too much? > most batshit aspect of DNSSEC: validation is done on the servers and not on the endpoints (you "can" do endpoint validation, in the same sense as you "can" run your own recursive caching server locally). You "can" and we "should" be validating this at the client. So why don't we start doing this? We should be beating on the security layer in DNS as heavily as we do with HTTPS and other TLS implementations. > This is a relic of the early-mid 1990s, when the core DNSSEC design was finalized and any kind of encryption was thought to be too expensive to deploy to end-systems. It's also the reason DNSSEC is signing-only, with no privacy protections. There are several proposals at this point that resolve the privacy issue, DNSCrypt, DNSCurve, and DNS over TLS. > But we're still forced to live with that bad decision, because nobody in the IETF wants to admit they were wrong Given the number of revisions to the DNS RFCs, specifically around DNSSec, I don't think it would be accurate that they didn't admit being wrong, people are constantly working to resolve issues with the system.
- tptacek 10y ago
  If we're going to accept that shit is broken and we should go ahead and fix it, why can't we fix DNSSEC itself? It's a terrible, broken, already-obselete protocol that sees virtually no meaningful real-world deployment. Why would we spend tens of millions of dollars to deploy something we already know is broken.
  - bluejekyll 10y ago
    see my comment in a sibling thread: https://news.ycombinator.com/item?id=12392121 https://news.ycombinator.com/item?id=12392121