Query ID prediction attacks are not in fact the point of DNSSEC, which will not actually meaningfully address this attack because almost nothing in the DNS is signed.
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.
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:
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.
In any event, that's a nice site that provides useful stats.
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."
I'll just leave this here: https://blog.netherlabs.nl/articles/2008/07/09/some-thoughts...
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.
* https://dns.cr.yp.narkive.com/fAkXdiM0/update-on-the-djb-bug...
It should tell you something that even I, who am and was on a different continent to all of these people, knew about this stuff well before it became an ISC press release. I'd like to say that it was Paul Jarc who went into the consequences of what one could do with response forgeries, on Bernstein's dns mailing list, but I might be remembering the wrong person. Certainly, list regulars had read Bernstein's discussion of DNS security and realized the implications.
The logical consequences of being able to forge whatever response one likes were readily apparent. Bert Hubert noted publicly at the time of the Kaminsky announcements that xe had been not only aware of this for years,
* https://mailman.powerdns.com/pipermail/pdns-users/2008-July/...
but had even been trying to get an IETF draft approved about port+ID randomization, and bailiwick checking, acknowledging the factors involved and promoting the adoption of the well-known mitigations as mandatory.
Amusingly for the instant case of researchers rediscovering the well-known, you can read M. Hubert's first draft from a year and a half before the ISC press release, and it lays out there exactly what I laid out here elsewhere in this very discussion, about a query to Google Public DNS taking a second from cold to answer for ~.www.example.com and that being more than enough time to send a tonne of forged responses at 2006 network speeds.
* https://datatracker.ietf.org/doc/html/draft-ietf-dnsext-forg...
Daniel Bernstein was right in the late 1990s about randomizing source ports, and randomization did effectively foreclose on Kaminsky's vulnerability. But I'm unaware of a cite in which he outlines Kaminsky's attack in any detail. His djbdns countermeasure was a sensible response to BIND's QID prediction problem, which Paul Vixie was reluctant to fix because the QID only gave him 16 bits of randomness to work with.
I'm not saying you're certainly wrong that other people had discovered the random-name / authority spoofing attack Kaminsky came up with, only that I'm intimately familiar with this whole line of security research and I'm unaware of a source laying it out --- I am thus skeptical of the claim.
Kaminsky figured out how to build a much more practical way to exploit what was known already. This was very significant, and it's one of the ultimate examples of PoC||GTFO finally triggering action. He deserves a lot of credit.
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-...>
(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.)
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.
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.
All I'm saying is that I find it remarkable that DNSSEC adoption in North America sharply dropped over the course of 2023 --- that, and the fact that the graph tops out at 7MM zones, a big-looking number that is in fact very small.
I think it's funny that the graph serves my argument better than 'teddyh's. But really, I think it's ultimately meaningless. That's because the figure of merit for DNSSEC adoption isn't arbitrary signed zones but rather popular signed zones. And that in turn is because the distribution of DNS queries is overwhelmingly biased to popular zones --- if you can sample a random DNS query occurring somewhere in the US right now, it's much more likely to be for "googlevideo.com" than for "aelcargo.site" (a name I just pulled off the certificate transparency firehose).
The Verisign graph 'teddyh keeps posting is almost entirely "aelcargo.site"-like names†. The link I posted upthread substantiates that.
† And that in turn is because DNS providers push users into enabling managed DNSSEC features, because disabling DNSSEC is terrifying and so DNSSEC is an extremely effective lock-in vector --- that's not me making it up, it's what the security team at one of the few large tech companies that actually have it enabled told me when I asked why the hell they had it enabled.
Then why did you use the graph — or at least the information it displays – as the finishing slam dunk point of your post?
> The Verisign graph 'teddyh keeps posting
I “keep posting” it because it’s a good solid counterargument, and it’s also very funny; I originally got the link from you, but as time goes by, the graph keeps proving you wrong.
> why the hell they had it enabled.
Yes, why does a security team have a security feature enabled? It is truly a mystery.
But wait, your main argument, in this post, is that nobody “popular” uses DNSSEC, but do you mean that you actually personally pressure all the popular ones who do use it, to stop? Does not that severely skew your data into irrelevance?