Dan Kaminsky disclosed a substantive DNS protocol vulnerability earlier this week through coordinated industry response. The vulnerability allows DNS cache poisoning at substantially higher reliability than previous techniques; specific affected DNS implementations include essentially all current resolver software; specific patches have been deployed across the major implementations through coordinated multi-vendor coordination.
This is a longer post because both the vulnerability and the disclosure pattern are structurally significant.
What the vulnerability is
The technical mechanism: DNS resolvers traditionally use small (16-bit) transaction IDs to match queries to responses. Specific attacker techniques can produce sufficient response volume that a forged response with a guessed transaction ID is accepted before the legitimate response arrives. The forged response can poison the resolver's cache, causing subsequent queries for the affected domain to be answered with the attacker's chosen IP.
Kaminsky's specific contribution combines several known techniques into a substantially more reliable attack:
- Specific query patterns that cause the resolver to make rapid queries for targets the attacker chooses.
- Specific response-flooding patterns that race the legitimate response.
- Specific manipulation of the additional-records section to poison cache entries beyond the immediately-queried record.
The cumulative effect: cache poisoning that previously took days or weeks to achieve reliably can now be completed in seconds. The cumulative practical exploitation is substantially more reliable than previous techniques.
What was disclosed coordinated
The disclosure pattern is structurally novel. Kaminsky did not publish the technical details immediately. The cumulative process:
- Kaminsky identified the vulnerability earlier in 2008.
- Specific disclosure to major DNS implementation vendors through Microsoft.
- Specific multi-vendor coordination to develop and deploy patches.
- Specific synchronised patch release on 8 July 2008.
- Specific public disclosure of the vulnerability without technical details.
- Specific full technical disclosure planned for Black Hat USA in August.
The cumulative coordination involved vendors across multiple platforms — Microsoft, ISC (BIND), Cisco, various Linux distributions, specific other DNS implementations. The cumulative effort produced patches available across most major implementations on the disclosure day.
Why the coordinated approach matters structurally
Three observations.
Internet-infrastructure-level coordination is now operationally feasible. Specific multi-vendor coordination across implementations from competing vendors produced synchronised patch availability. The cumulative coordination infrastructure has matured.
The specific vulnerability is sufficiently severe to justify coordinated approach. DNS cache poisoning at high reliability would substantially undermine internet trust assumptions; specific coordinated disclosure produced bounded exposure between disclosure and patch availability.
The 30-day patch-deployment window is the operational risk. Specific operators must apply the patches across the cumulative DNS infrastructure within the period before specific exploitation infrastructure operationalises. The cumulative urgency is real.
The cumulative pattern: coordinated disclosure for severe internet-infrastructure vulnerabilities is now structurally established. Specific subsequent disclosures of similar severity may use similar approaches.
What operators should do
For organisations running DNS resolvers:
Apply the patches immediately. Specific BIND versions, specific Microsoft DNS, specific other implementations all have patches available. The cumulative deployment urgency is real.
Verify resolver behaviour after patching. Specific patched resolvers use larger source-port-randomisation as an additional defence; specific verification confirms the patches deployed correctly.
Specific monitoring for cache-poisoning attempts. Specific patterns are detectable in resolver logs; specific subsequent monitoring informs cumulative defensive posture.
Consider specific architectural responses. Specific organisations may consider deploying DNSSEC for specific domains; specific subsequent cumulative deployment will inform structural cumulative response.
For organisations whose DNS infrastructure is operated by upstream providers:
Verify provider patching. Specific ISP-operated resolvers serve substantial cumulative traffic; specific cumulative provider patching matters.
Specific subsequent monitoring of DNS responses. Specific anomalous DNS responses are detectable; specific cumulative monitoring informs cumulative defensive posture.
For end users:
Specific cumulative discipline around HTTPS. Specific connections that depend on TLS server certificates are bounded by certificate-authority infrastructure rather than purely by DNS. The cumulative defensive value of HTTPS is operationally meaningful even with cache-poisoning exposure.
What this teaches structurally
Three observations.
The cumulative DNS infrastructure has structural fragility. Specific assumptions about DNS reliability have been bounded; specific subsequent research may identify other structural issues.
Specific cumulative defensive responses are bounded by deployment. Patches are necessary but not sufficient; specific cumulative deployment across the full DNS infrastructure determines cumulative defensive state. The cumulative deployment trajectory matters.
Specific subsequent DNSSEC deployment may accelerate. The Kaminsky vulnerability provides specific cumulative motivation for structural DNS-security improvements; specific cumulative subsequent deployment may be visible across coming years.
What I am doing
For my own infrastructure: specific patches deployed within hours of release.
For Gala Coral: specific cumulative DNS infrastructure patched within 48 hours; specific subsequent monitoring in place; specific cumulative defensive discipline continues.
For my own continued writing: continued tracking of the DNS-security trajectory. The cumulative archive informs structural understanding.
What I am paying attention to
Three things over the next several months.
Specific cumulative deployment of the patches. Specific tracking metric. The cumulative patching trajectory will inform structural assessment.
Specific exploitation in the wild. 85% probability of meaningful exploitation. Specific operators will face exploitation; specific cumulative impact on unpatched resolvers will be substantial.
Specific subsequent DNSSEC deployment acceleration. 60% probability of meaningful acceleration. The cumulative trajectory may shift; specific subsequent observation will inform.
For my own continued operation: the discipline continues. The cumulative archive grows.
More in time.