This animated GIF shows announced, estimated, and actual DNSSEC adoption by ccTLDs from January 2006 through July 2015 as of 1 February 2013.  We’d like to see a more colorful, even completely green, map in the future.  We also have a high-resolution PDF map of the world with ccTLD DNSSEC adoption as of 1 February 2013 here.

The maps are a work in progress.  We’re pretty sure about the past and present.    If you manage a ccTLD and have a schedule for deployment or have updates/corrections, let us know at info @ dnssec-deployment.org.

In the past, we’ve described how the graphic at the top of the  DNSSEC Deployment web site let you know if you’re validating or not.

Now, Jan-Piet Mens has posted an article on how he implemented this for his web site and how you can replicate his work with his code.  Thanks, Jan-Piet!

The Collateral Damage of Internet Censorship by DNS Injection (594KB PDF)  by Anonymous, published in ACM SIGCOMM Computer Communication Review (Volume 42, Number 3, July 2012), looks at  how

Some ISPs and governments (most notably the Great Firewall of China) use DNS injection to block access to “unwanted” websites. The censorship tools inspect DNS queries near the ISP’s boundary routers for sensitive domain keywords and inject forged DNS responses, blocking the users from accessing censored sites, such as twitter and facebook. Unfortunately this causes collateral damage, affecting communication beyond the censored networks when outside DNS traffic traverses censored links.

They point out that the techniques used are similar to Kaminsky-style attacks that can be perpetrated on non-DNSSEC-enabled systems:

In the absence of DNSSEC validation, the resolver will generally accept the faked answer because it arrives earlier than the real one, and, as a result, the access to the sensitive site will be blocked or redirected.

While DNSSEC is not able to guarantee transport of valid queries and responses, the paper goes on to say how it prevents the collateral damage associated with such machinations.

Certain administrative and operational changes — changing registrars, changing DNS servers and, if outsourced, DNS operators — have always had the potential to cause temporary name resolution failures. With some planning, usually involving lowering TTLs on some or all records in a zone in advance of the change, it has been possible to minimize if not obviate such failures.

DNSSEC adds complexity in that signatures also have lifetimes and some administrative and operational changes require re-keying. If not done correctly, such changes can cause signed zones to fail to validate — to go dark — for longer than desired or expected.

Internally, within the DNSSEC Deployment Coordination Initiative, we’ve described the goal as being a ripple-free transfer, and have made presentations on the topic  (e.g., SATIN 2011 180KB PDF).  Done properly, there is continuous, secure resolution throughout the process — no need to have a zone go unsigned/insecure or fail to validate at any point.

Now, Antoin Verschuren from SIDN labs has published the article, DNSSEC Secure transfers: Het kan well.  We have an English translation here (315KB PDF).

The presentations from NANOG 55 are now available online.   The presentations from the DNS track, including several that cover aspects of DNSSEC, are available here.

We’ve put NANOG 56 on our calendar.   It will be in Dallas, Texas.  The Call for Presentations is open with abstracts being accepted until 6-August-2012.

The H Open reports about a new, open-source (BSD license), DNSSEC-enabled DNS server:

An open source DNS name server that supports DNSSEC and is designed to be authoritative has been released by EURid, the European Registry of Internet Domain Names. YADIFA is intended to be a lightweight alternative to more established projects; the developers say it was “built from scratch to face today’s DNS challenges, with no compromise on security, speed and stability”.

Thanks for the update, .ES!

This animated GIF shows announced, estimated, and actual DNSSEC adoption by ccTLDs from January 2006 through July 2014 as of 2 July 2012.  The map is a work in progress.  We’re pretty sure about the past and present.    If you manage a ccTLD and have a schedule for deployment or have updates/corrections, let us know at info @ dnssec-deployment.org.  We’d like to see a more colorful, even completely red, map in the future.

Effective immediately, this site will be renamed The .NL Gazette.  Well, maybe not, but the folks at SIDN, the .NL registry, just keep producing good stuff.

We’ve recently reported on their becoming DNSSEC operational  and their surpassing .COM in the number of signed zones.  A couple of months back we lauded their excellent DNSSEC tutorial.  We’ve also mentioned several of the tools they’ve NLNet Labs produced (NSD, Unbound, Dnssec-Trigger) when talking about labs and in our articles on adding DNSSEC validation to a $70 router and its performance.

[Correction 3 July 2012:  Why the strikeout above?  Olaf M. Kolkman of NLNet Labs points out that while SIDN and NLNet Labs have had a collaborative agreement since the beginning of this year, NSD, Unbound, and Dnssec-Trigger are products of NLNet Labs.   We're just happy that both SIDN and NLNet Labs are helping advance DNSSEC and don't for one second want to confuse the two just because they're both in The Netherlands!   To further make things clear, neither SIDN nor NLNet Labs produce Koetjesreep, so don't ask for a few bars.  Thanks for the correction, Olaf!]

Now it’s time to let people know about one of their more technical articles,
Authenticated Denial of Existence in the DNS  (277KB PDF).  We ran across it while trying to debug some validation software.

The article tells the story behind why negative responses must be signed and how they can state with security and certainty that a name/resource record type combination does not exist. The article augments RFCs 4033, 4034, 4035, and 5155.

It provides the kinds of additional information in narrative and graphic format that helps with understanding.  If you want to now how authenticated denial of existence works, check out the article.