4 ms·
> Query ID prediction attacks are not in fact the point of DNSSEC Do you deny DNSSEC's goal is to protect DNS data? Do you deny "Query ID prediction attacks" (
by dc396 1y ago
> Query ID prediction attacks are not in fact the point of DNSSEC
Do you deny DNSSEC's goal is to protect DNS data? Do you deny "Query ID prediction attacks" (or more generally, flooding attacks) aim to corrupt DNS data? Do you deny the 16-bit transaction ID allows for effective flooding attacks?
As for "almost nothing in the DNS is signed", while it's true the percentage of second-level domains aren't signed, the DNS root is signed, all generic top-level domains, and the vast majority of country code TLDs are signed. In some countries (e.g., The Netherlands) more than 50% of the zones in their ccTLD are signed. As we've seen empirically, with improved automation/tools and authoritative servers that turn on DNSSEC-signing by default, the percentage will go up.
- tptacek 1y agoI deny that query ID protection was the impetus for the development of DNSSEC and that the earliest advocacy for it as an operational security tool, rather than a (government-funded) design improvement for the entire TCP/IP stack, was about query ID prediction. Like you, I was there at the time; if the NANOG archives go back that far, you'll see me on the threads babbling about this. This notion of DNSSEC signatures being widespread comes up in every thread about the protocol. Here's a little thingy I threw together because I got tired of typing out the bash "dig" loop to regenerate it in threads: https://dnssecmenot.fly.dev/ https://dnssecmenot.fly.dev/ Note that the Tranco list is international, so captures popular zones in places that have automatic (and security-theatric) DNSSEC signatures, as well as amplifying the impact of vendors like Cloudflare who have several different zones in the top 1000. Even with all that included: single digits. It's been over 30 years of tooling work on DNSSEC --- in recent time intervals, DNSSEC adoption in North America has gone down. Stick a fork in it.
- teddyh 1y ago> in recent time intervals If you get to pick the specific time interval, you can prove anything. Why don’t you link the full graph? <https://www.verisign.com/en_US/company-information/verisign-labs/internet-security-tools/dnssec-scoreboard/index.xhtml https://www.verisign.com/en_US/company-information/verisign-...> (The graph shows that DNSSEC usage is instead increasing since the end of last year, and at that time, its lowest point, was only ever as low as it was back in 2023.)
- tptacek 1y agoThat page doesn't load right now, but when it does, I encourage people to click through to it and see what I was talking about. Thanks for sourcing it for me!
- furgot 1y agoI took a look at it. It comports much closer with what GP was saying. It shows adoption being flat as a percentage and rising in absolute terms.
- tptacek 1y agoIt's still not loading for me but as I recall from the last time this was posted, it showed 2023 with a 15% (!) drop in North American signed zones, and us still well below the peak --- that peak being less than 1% of all North American zones.
- furgot 1y agohttps://web.archive.org/web/20250720163940/https://www.verisign.com/en_US/company-information/verisign-labs/internet-security-tools/dnssec-scoreboard/index.xhtml https://web.archive.org/web/20250720163940/https://www.veris... There is a 15% drop like you describe, but as the other commenter said, it doesn't show usage falling for the past year (as you had implied). I have no dog in this race, I don't care about DNSSEC. If you can't access the page, that's your business. But it bothers me that you would assert this data agrees with your point without even looking at it. That's pretty uncharitable.
- teddyh 1y ago> it doesn't show usage falling for the past year (as you had said). Note how he cleverly did not say that; he said “in recent time intervals”. And you can certainly count the time from 2023-2024 as being “recent”. He technically was not wrong, and technically did not lie.
- dc396 1y agoI guess you and I were at different meetings. I was at meetings at NSF with TIS folks that resulted in funding for DNSSEC implementation in BIND where the presentation focused on the 16-bit transaction field (and included a live demonstration), so I'll stand by my view that the point of DNSSEC was to address that particular flaw. In any event, that's a nice site that provides useful stats.
- tptacek 1y agoThanks! For what it's worth: I think hashing out the origins of DNSSEC is a super interesting conversation to have, and I'm happy you're here pushing back on what I'm saying (the truth is going to be somewhere in between the two of us).
- colmmacc 1y agoI remember tearing my hair out in the pre-2008 era as folks tried to get source-port randomization into Bind. The response was "That's what DNSSEC is for" ... which further supports your narrative. But it's still very damning. Source port randomization, BCP38, and then the 0x20 qname capitalization trick, all turned out to be far more practical mitigations for query-id concerns and others prioritized them. "We really need this massive internet-wide jobs-program lift of the entire Internet, without even providing confidentiality, to solve this query-id issue. Never mind the easier fixes."
- mike_d 1y agoWow this brings up memories. I was at OpenDNS when Dan gave us the heads up. I'll just leave this here: https://blog.netherlabs.nl/articles/2008/07/09/some-thoughts-on-the-recent-dns-vulnerability https://blog.netherlabs.nl/articles/2008/07/09/some-thoughts...
- colmmacc 1y agoI found that post so cathartic. This whole episode reminds me of the story of the Citigroup Center in New York. Years after its completion, an architecture student uncovered that key supports for the building had been done incorrectly and unsafely. It was at risk of collapse in high winds. The structural engineer worked with the building owner and city to repair the building in secret, before everything was eventually made public. It makes for a story of a folk hero, and it's a great narrative of recovery. Meanwhile the stories of the structural engineers and construction supervisors who weren't woefully negligent and who just quietly built safe buildings go uncelebrated.