5 ms·

This is only for DNSSEC signing for the root zone, right? If you don’t use DNSSEC, those 14 people don’t affect you in any way.

by guan 10y ago

AndyMcConachie 10y ago
8.8.8.8 DNSSEC validates. So that's a lot of people right there. I think Comcast also validates. There are others but I think you get the point. You might be relying on DNSSEC validation without knowing it.
- tptacek 10y ago
  Where by "relying on" you mean "impacted by outages and little else", since we systemically do not validate DNSSEC and any attack that DNSSEC "prevents" can simply be aimed at a different part of the communications infrastructure. Also, obviously, people who "rely on" 8.8.8.8 doing DNSSEC lookups are in fact relying on a single bit in an unencrypted DNS response packet that vouches for the validation that the server did. Nothing 8.8.8.8 can do will protect the link between the user's stub resolver and Google's DNS server.
  - AndyMcConachie 10y ago
    > Where by "relying on" you mean "impacted by outages and little else", since we systemically do not validate DNSSEC and any attack that DNSSEC "prevents" can simply be aimed at a different part of the communications infrastructure. You could make that statement about nearly any security mechanism. It still doesn't explain why you think unsigned DNS responses are better than signed ones. > Also, obviously, people who "rely on" 8.8.8.8 doing DNSSEC lookups are in fact relying on a single bit in an unencrypted DNS response packet that vouches for the validation that the server did. Nothing 8.8.8.8 can do will protect the link between the user's stub resolver and Google's DNS server. Yes, which is why the kind folks at the IETF are working on DNSoTLS. But that's orthogonal to DNSSEC.
    - tptacek 10y ago
      No, you don't understand what I'm saying. I'm saying that by using Google DNS to "verify" DNSSEC, you're playing pretend, because DNSSEC doesn't do anything to protect the last mile between your stub resolver and Google's servers; instead, it sets a single bit in the header to reassure your resolver that "yes, Google verified this DNSSEC request". But any coffee shop MITM can simply flip that bit back! Google DNS's DNSSEC support is pure security theater.
      - AndyMcConachie 10y ago
        Which is why I brought up DNSoTLS which you conveniently ignored. That 'last mile' problem you speak of is being worked on at the IETF. It's not an easy problem to solve. But I suspect this argument of yours, which is valid BTW, will be less of problem in 5 years. We're already starting to see DNSoTLS testing happening. You could also run a DNSSEC validating stub resolver on your laptop. Or you can run DNSMasq on my home router with DNSSEC validation enabled. Both of these effectively prevent the MITM you bring up.

This is only for DNSSEC signing for the root zone, right? If you don’t use DNSSEC, those 14 people don’t affect you in any way.

by guan 10y ago

This is only for DNSSEC signing for the root zone, right? If you don’t use DNSSEC, those 14 people don’t affect you in any way.

AndyMcConachie 10y ago

8.8.8.8 DNSSEC validates. So that's a lot of people right there. I think Comcast also validates. There are others but I think you get the point. You might be relying on DNSSEC validation without knowing it.

tptacek 10y ago
Where by "relying on" you mean "impacted by outages and little else", since we systemically do not validate DNSSEC and any attack that DNSSEC "prevents" can simply be aimed at a different part of the communications infrastructure. Also, obviously, people who "rely on" 8.8.8.8 doing DNSSEC lookups are in fact relying on a single bit in an unencrypted DNS response packet that vouches for the validation that the server did. Nothing 8.8.8.8 can do will protect the link between the user's stub resolver and Google's DNS server.
- AndyMcConachie 10y ago
  > Where by "relying on" you mean "impacted by outages and little else", since we systemically do not validate DNSSEC and any attack that DNSSEC "prevents" can simply be aimed at a different part of the communications infrastructure. You could make that statement about nearly any security mechanism. It still doesn't explain why you think unsigned DNS responses are better than signed ones. > Also, obviously, people who "rely on" 8.8.8.8 doing DNSSEC lookups are in fact relying on a single bit in an unencrypted DNS response packet that vouches for the validation that the server did. Nothing 8.8.8.8 can do will protect the link between the user's stub resolver and Google's DNS server. Yes, which is why the kind folks at the IETF are working on DNSoTLS. But that's orthogonal to DNSSEC.
  - tptacek 10y ago
    No, you don't understand what I'm saying. I'm saying that by using Google DNS to "verify" DNSSEC, you're playing pretend, because DNSSEC doesn't do anything to protect the last mile between your stub resolver and Google's servers; instead, it sets a single bit in the header to reassure your resolver that "yes, Google verified this DNSSEC request". But any coffee shop MITM can simply flip that bit back! Google DNS's DNSSEC support is pure security theater.
    - AndyMcConachie 10y ago
      Which is why I brought up DNSoTLS which you conveniently ignored. That 'last mile' problem you speak of is being worked on at the IETF. It's not an easy problem to solve. But I suspect this argument of yours, which is valid BTW, will be less of problem in 5 years. We're already starting to see DNSoTLS testing happening. You could also run a DNSSEC validating stub resolver on your laptop. Or you can run DNSMasq on my home router with DNSSEC validation enabled. Both of these effectively prevent the MITM you bring up.