4 ms·

And actually... > And actually, in case of the latter, all bets are off anyways. Because client resolvers DO NOT CHECK DNSSEC. ... please visit APNIC's DNSSEC

by danyork 12y ago

And actually... > And actually, in case of the latter, all bets are off anyways. Because client resolvers DO NOT CHECK DNSSEC. ... please visit APNIC's DNSSEC Statistics site where you will see that about 12% of all DNS queries globally ARE being validated by DNSSEC: http://stats.labs.apnic.net/dnssec/XA?c=XA&x=1&g=1&r=1&w=7&g=0 http://stats.labs.apnic.net/dnssec/XA?c=XA&x=1&g=1&r=1&w=7&g... In Sweden this is about 71%: http://stats.labs.apnic.net/dnssec/QM?o=cXAw7x1g1r1 http://stats.labs.apnic.net/dnssec/QM?o=cXAw7x1g1r1 Slovenia 67%, Estonia 55%, Denmark 48% ... on down to the USA at 23%: http://stats.labs.apnic.net/dnssec/XQ?o=cXAw7x1g1r1 http://stats.labs.apnic.net/dnssec/XQ?o=cXAw7x1g1r1 So DNSSEC validation very definitely * IS * happening out there!

tptacek 12y ago
This is "checking" in the sense that "everyone at Comcast was 'checking' when HBO Now broke".
icebraining 12y ago
Checks being made doesn't mean the clients are checking. What's the point of validating the communication between the servers if the last mile is unprotected?
- danyork 12y ago
  > What's the point of validating the communication between the servers if the last mile is unprotected? It's all incremental ways of reducing the attack surface. Get DNSSEC validation happening at large public DNS services... then at ISPs... then on network edge devices... then into operating system (in stub resolvers) ... then perhaps into applications themselves. Each step reduces the attack surface a bit more. I wrote about this at: http://www.internetsociety.org/deploy360/resources/plan-dnssec-validation/ http://www.internetsociety.org/deploy360/resources/plan-dnss... This is why some people are using libraries like the GetDNS API to build DNSSEC validation directly into apps: https://getdnsapi.net/ https://getdnsapi.net/ And solving the "last mile" problem is exactly why the DPRIVE working group was chartered within IETF: https://datatracker.ietf.org/wg/dprive/charter/ https://datatracker.ietf.org/wg/dprive/charter/ (And anyone is welcome to contribute to the group.)

by danyork 12y ago

tptacek 12y ago

This is "checking" in the sense that "everyone at Comcast was 'checking' when HBO Now broke".

icebraining 12y ago

Checks being made doesn't mean the clients are checking. What's the point of validating the communication between the servers if the last mile is unprotected?

danyork 12y ago
> What's the point of validating the communication between the servers if the last mile is unprotected? It's all incremental ways of reducing the attack surface. Get DNSSEC validation happening at large public DNS services... then at ISPs... then on network edge devices... then into operating system (in stub resolvers) ... then perhaps into applications themselves. Each step reduces the attack surface a bit more. I wrote about this at: http://www.internetsociety.org/deploy360/resources/plan-dnssec-validation/ http://www.internetsociety.org/deploy360/resources/plan-dnss... This is why some people are using libraries like the GetDNS API to build DNSSEC validation directly into apps: https://getdnsapi.net/ https://getdnsapi.net/ And solving the "last mile" problem is exactly why the DPRIVE working group was chartered within IETF: https://datatracker.ietf.org/wg/dprive/charter/ https://datatracker.ietf.org/wg/dprive/charter/ (And anyone is welcome to contribute to the group.)