I'm adopting/setting up DNSSEC on my domains for the first time, and curious about the practical benefits I can expect. In theory, regardless of whether client/stub resolvers want checking, recursive nameservers can request signature chains, and, for any domain where the higher-level delegating one indicates that there's supposed to be a signature, treat the absence of a valid signature as a hard lookup error to return to the client, thereby protecting domain owners against forged records. What portion of ISP and public (Google, Cloudflare, etc.) recursive nameservers currently do this? Is it common or uncommon?
asked Mar 5, 2020 at 17:36
R.. GitHub STOP HELPING ICER.. GitHub STOP HELPING ICE
8,3261 gold badge25 silver badges36 bronze badges
-
This is dynamic by nature. I doubt it's a good idea to hard-code any figures in the answer, unless the author is going to maintain that answer for life. Maybe rephrase as "where can I track ongoing DNSSEC deployment progress"?– ximaeraMar 6, 2020 at 4:41
Add a comment
|
1 Answer
I want to mainly focus on the second part of your question, namely the deployment state of DNSSEC. But before getting into that, I thought it would be interesting to note, that beside the obvious advantage, i.e. mitigating DNS poisoning, there are other less known threats when you don't use DNSSEC. A recent paper from 2019 [1], for example, shows how DNS poisoning can grant you a DV certificate, practically allowing an attacker to spoof your domain and provide TLS at the same time, giving the impression of being legitimate!
Now for the second part: people have done measurements of DNSSEC deployment (NS side) and validation (client side) in different settings. A paper from 2013 [2] did this for the client side and came to the following conclusion:
After data cleaning, we gathered 131,320 results from 98,179 distinct IP addresses, out of which 4.8% had validation enabled. The ratio varies significantly per country, with Sweden, the Czech Republic and the United States having the largest ratios of validating clients in the field.
Another one from 2017 [3] measured the support both on name servers and resolvers:
We use this methodology to measure a total of 403,355 exit nodes—from 177 countries and 8,842 ASes—over a period of 13 days in early 2017. These exit nodes use a total of 59,513 unique resolvers. We observe that 49,424 of the resolvers (83.0% of resolvers, covering 65.9% of the exit nodes) send requests with the DO bit set, suggesting that a majority of resolvers support DNSSEC.
I suggest to read these papers as the excerpts copied here does not cover the whole picture. Finally, you can also checkout SecSpider to have an overview of up-to-date state of DNSSEC deployment or to use DNSViz to have a visualization of DNSSEC for a host name. If you want to force DNSSEC on your client side, I'd suggest DNSSEC Trigger from NLnet Labs.
Personally, I think the slow penetration of DNSSEC has also to do with lack of visual cues for end-users. In contrast to the green padlock which indicates authentication secure channel, there is no indication for authenticated DNS results.
[1] Schwittmann, L., Wander, M., & Weis, T. (2019). Domain impersonation is feasible: A study of CA domain validation vulnerabilities. Proceedings - 4th IEEE European Symposium on Security and Privacy, EURO S and P 2019, 544–559. https://doi.org/10.1109/EuroSP.2019.00046
[2] Wander, M., & Weis, T. (2013). Measuring Occurrence of DNSSEC Validation. In M. Roughan & R. Chang (Eds.), Passive and Active Measurement (pp. 125–134). Springer Berlin Heidelberg. https://doi.org/10.1007/978-3-642-36516-4_13
[3] Chung, T., Van Rijswijk-Deij, R., Chandrasekaran, B., Choffnes, D., Levin, D., Maggs, B. M., Mislove, A., & Wilson, C. (2017). A longitudinal, end-to-end view of the DNSSEC ecosystem. Proceedings of the 26th USENIX Security Symposium, 1307–1322.
