DNS Security

The Christmas Goat and IPv6 (Year 4)

This year, 2013, I got 24 days of IPv6 and DNSSEC measurements. All in all it created 15GB logs with more than 62 million rows. On the 21st of December, early in the morning, the goat was "traditionally" burnt down, however this year with one exception. Via the Swedish newspaper Expressen the arsonists anonymously took the blame and also filmed their own act.

LAC, the DNS, and the Importance of Comunidad

The 1st Latin American & Caribbean DNS Forum was held on 15 November 2013, before the start of the ICANN Buenos Aires meeting. Coordinated by many of the region's leading technological development and capacity building organizations, the day long event explored the opportunities and challenges for Latin America brought on by changes in the Internet landscape, including the introduction of new gTLDs such as .LAT, .NGO and others.

DNS Tunneling: Is It a Security Threat?

DNS tunneling -- the ability to encode the data of other programs or protocols in DNS queries and responses -- has been a concern since the late 1990s. If you don't follow DNS closely, however, DNS tunneling likely isn't an issue you would be familiar with. Originally, DNS tunneling was designed simply to bypass the captive portals of Wi-Fi providers, but as with many things on the Web it can be used for nefarious purposes. For many organizations, tunneling isn't even a known suspect and therefore a significant security risk.

DNS Amplification Attacks: Out of Sight, Out of Mind? (Part 3)

Previous posts (Part 1 and Part 2) offer background on DNS amplification attacks being observed around the world. These attacks continue to evolve. Early attacks focused on authoritative servers using "ANY" queries for domains that were well known to offer good amplification. Response Rate Limiting (RRL) was developed to respond to these early attacks. RRL, as the name suggests, is deployed on authoritative servers to rate limit responses to target names.

On the Time Value of Security Features in DNS

There are some real problems in DNS, related to the general absence of Source Address Validation (SAV) on many networks connected to the Internet. The core of the Internet is aware of destinations but blind to sources. If an attacker on ISP A wants to forge the source IP address of someone at University B when transmitting a packet toward Company C, that packet is likely be delivered complete and intact, including its forged IP source address. Many otherwise sensible people spend a lot of time and airline miles trying to improve this situation... The problems created for the Domain Name System (DNS) by the general lack of SAV are simply hellish.

DNS Amplification Attacks: Out of Sight, Out of Mind? (Part 2)

This post follows an earlier post about DNS amplification attacks being observed around the world. DNS Amplification Attacks are occurring regularly and even though they aren't generating headlines targets have to deal with floods of traffic and ISP infrastructure is needlessly stressed -- load balancers fail, network links get saturated, and servers get overloaded. And far more intense attacks can be launched at any time.

DNS Amplification Attacks: Out of Sight, Out of Mind? (Part 1)

Geoff Huston's recent post about the rise of DNS amplification attacks offers excellent perspective on the issue. Major incidents like the Spamhaus attack Geoff mentions at the beginning of his post make headlines, but even small attacks create noticeable floods of traffic. These attacks are easy to launch and effective even with relatively modest resources and we see evidence they're occurring regularly. Although DNS servers are not usually the target of these attacks the increase in traffic and larger response sizes typically stress DNS infrastructure and require attention from operation teams.

The Challenge of DNS Security

When the domain name system (DNS) was first designed, security was an afterthought. Threats simply weren't a consideration at a time when merely carrying out a function - routing Internet users to websites - was the core objective. As the weaknesses of the protocol became evident, engineers began to apply a patchwork of fixes. After several decades, it is now apparent that this reactive approach to DNS security has caused some unintended consequences and challenges.

ICANN Chairman’s Durban Roundup

Respected ICANN Chairman of the Board Steve Crocker has wrapped up his organisation's 47th International Meeting, held in Durban last week, with a message to the community. This message, reproduced here in its entirety, provides both a useful and concise summary of the Durban meeting and insights into the Chairman's view of where ICANN stands at the moment, the successes it has notched up and the challenges it faces.

DNS, DNSSEC and Google’s Public DNS Service

For some time now we've been tracking the progress of the deployment of DNSSEC in the Internet. Its been a story of an evolution of the measurement technique... In the process we've learned perhaps more than we had wanted to about the behaviour of Flash engines, Apache web servers and FreeBSD system tuning, and also learned much more than we had anticipated about the finer details of Google's online ad presentation behaviour. But one thing we did not see in all of this was any large scale jumps in the level of client use of DNSSEC validation over this period at the start of the year.