Posts Tagged SIDN
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.
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.
Webwereld’s story about DNSSEC adoption in .NL describes how, with under five million domains, .NL has almost 12,000 using DNSSEC — more than the number of DNSSEC-enabled domains in .COM.