5 ms·

That depends on how you define a client. If you're a Comcast customer, for example, they are performing DNSSEC validation for you transparently. Recursive resol

by kijeda 10y ago

That depends on how you define a client. If you're a Comcast customer, for example, they are performing DNSSEC validation for you transparently. Recursive resolvers on most Linux distributions have DNSSEC validation by default. One school of thought is to migrate DNSSEC from relying on validating resolvers sitting within the network provider, and moving it closer to the edge, in web browsers and so forth. Not much of that has happened to date.

snuxoll 10y ago
> One school of thought is to migrate DNSSEC from relying on validating resolvers sitting within the network provider, and moving it closer to the edge, in web browsers and so forth. Not much of that has happened to date. Fedora is actively working to including a system-local DNS resolver by default that will validate DNSSEC-signed zones. The change was originally slated for F24 but was deferred due to lack of resources, but I suspect it should make it in by F26/F27 if all goes well and some of the NAT64 issues that were discovered with Unbound are fixed.
- hannob 10y ago
  What Fedora plans to do is to use a local resolver with a fallback in case DNSSEC doesn't work. By this trick they try to prevent the inevitable deployment problems of DNSSEC. Of course they also make it completely insecure and it doesn't make any sense.
  - snuxoll 10y ago
    The fallback is to be configurable, but breaking the entire UX is not desirable when a full recursive resolver is unable to function. Personally, I would like to see some indication as part of the GNOME Network icon whether the resolver is secure or not, but I have a hard time determining what that would look like and how to implement it without giving users false assurances or worrying them if they don't care. It's a tricky problem to solve, but Rome wasn't built in a day either. I'll probably disable the insecure fallback myself and only turn it on when I connect to my work VPN, I already don't trust public hotspots so unless I can connect to my OpenVPN server at home I don't use them.
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/

by kijeda 10y ago

snuxoll 10y ago

> One school of thought is to migrate DNSSEC from relying on validating resolvers sitting within the network provider, and moving it closer to the edge, in web browsers and so forth. Not much of that has happened to date. Fedora is actively working to including a system-local DNS resolver by default that will validate DNSSEC-signed zones. The change was originally slated for F24 but was deferred due to lack of resources, but I suspect it should make it in by F26/F27 if all goes well and some of the NAT64 issues that were discovered with Unbound are fixed.

hannob 10y ago
What Fedora plans to do is to use a local resolver with a fallback in case DNSSEC doesn't work. By this trick they try to prevent the inevitable deployment problems of DNSSEC. Of course they also make it completely insecure and it doesn't make any sense.
- snuxoll 10y ago
  The fallback is to be configurable, but breaking the entire UX is not desirable when a full recursive resolver is unable to function. Personally, I would like to see some indication as part of the GNOME Network icon whether the resolver is secure or not, but I have a hard time determining what that would look like and how to implement it without giving users false assurances or worrying them if they don't care. It's a tricky problem to solve, but Rome wasn't built in a day either. I'll probably disable the insecure fallback myself and only turn it on when I connect to my work VPN, I already don't trust public hotspots so unless I can connect to my OpenVPN server at home I don't use them.

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/