DNS Attack Surface

By: Danny McPherson -

In early February I had an opportunity to attend The Global DNS Security, Stability and Resiliency Symposium at Georgia Tech Information Security Center in Atlanta.  The symposium was composed of three primary ‘breakout’ tracks, interspersed with multiple plenary sessions aimed at compiling and discussing breakout track information and multi-track intersections.  The breakout sessions, all focused on the DNS,  were:

  • Resource Constrained Environments
  • Enterprise Use
  • Combating Malicious Use of the DNS

I chaired the Combating Malicious Use of the DNS session, which was quite lively and well attended.  My job as session chair was very much akin to herding cats, and with such a wide spectrum of stakeholders in the room, it was interesting, to say the least.  The Final Report from the symposium was released today.  While I’m certainly not in a position to provide any authoritative report from the sessions — that’s what the report linked above is for, I will provide a couple of takeaways I had as a participant.

In an attempt to guide discussions in the malicious use session I created five buckets that aimed to capture today’s operational Internet DNS framework.  The following diagram illustrates this framework (or attack surface – depending on perspective).

DNS Attack Surface

DNS Attack Surface

The various vulnerabilities that exist within each ‘bubble’ in the system were discussed by the group, some new (e.g., DNS SEC, IPv6, IDNs, gTLDs, conficker and similar responses), some quite old (cache poisoning, DDoS on TLDs, domain hijacking via registrant credential compromise, etc..).

Perhaps one of the most interesting things to me was the discussion regarding incident response and strategic planning.  The room was clearly split – half the folks thought ICANN should take a leadership role in coordinating risk assessment, strategic planning, and incident response, the other half vehemently asserted that they had no right to do so.  I found this discussion particularly surprising, and believe that if ICANN doesn’t take the reins here it’s unclear who would.

The absence of leadership in this area has left an obvious void – the tip-toeing that ICANN had to do just to facilitate organization of the Symposium, and their [seemingly senseless] attempt to take an obvious backseat to other Symposium collaborators in order to avoid political backlash for trying to do the right thing, is in my opinion unfortunate at best.  I applaud ICANN and the other organizers here for bringing this group together and facilitating these discussions, and recommend that you give the report a review if you get an opportunity.

Comments