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.
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.
The DNSSEC Deployment Initiative, in cooperation with the ICANN Security and Stability Advisory Committee (SSAC), is planning a DNSSEC Workshop at the ICANN meeting in Toronto, Canada on 17 October 2012. The DNSSEC Workshop has been a part of ICANN meetings for several years and has provided a forum for both experienced and new people to meet, present and discuss current and future DNSSEC deployments. For reference, the most recent session was held at the ICANN Prague meeting on 27 June 2012. The presentations and transcripts are available at http://prague44.icann.org/node/31749.
We are seeking presentations on the following topics:
1. DNSSEC Activities in North America
This is a key panel and we are seeking participation from those who have been involved in DNSSEC deployment in North America as well as those who have a keen interest in the challenges and benefits of deployment. Key questions are to consider include: what would help to promote DNSSEC deployment? What are the challenges you have faced when you deployed DNSSEC? Can DNSSEC make the information users receive more reliable?
2. ISPs and Validation
ISPs are beginning to take the first step to full DNSSEC implementation that will allow web users, with software applications like browsers, to validate that the destination they are trying to reach is authentic and not a spoofed website. We are seeking ISPs to participate in a panel discussion or provide presentations on their DNSSEC deployment plans, challenges, and benefits for users.
3. The Realities of Running DNSSEC
Now that DNSSEC has become an operational norm for many registries and registrars, what have we learned about how we manage DNSSEC? What’s best practice around key rollovers? How often do you review your disaster recovery procedures? Is there operational familiarity within your customer support teams? Has DNSSEC made DNS more ‘brittle’ or is it just a run-of-the-mill operational practice?
4. DNSSEC and Enterprise Activities
DNSSEC has always been seen as a huge benefit to organizations looking to protect their identity and security on the Web. Large enterprises are an obvious target for DNS hackers and DNSSEC provides an ideal solution to this challenge. This session aims to look at the benefits and challenges of deploying DNSSEC for major enterprises. Topics for discussion:
What is the current status of DNSSEC deployment among enterprises?
What plans do the major enterprises have for their DNSSEC roadmaps?
What are the challenges to deployment for these organizations? Do they foresee raising awareness of DNSSEC with their customers?
5. When Unexpected DNSSEC Events Occur
What have we learned from some of the operational outages that we have seen over the past 18 months? Are there lessons that we can pass on to those just about to implement DNSSEC? How do you manage dissemination of information about the outage? What have you learned about communications planning? Do you have a route to ISPs and registrars? How do you liaise with your CERT community?
6. DNSSEC in the Wild
What operational statistics have we gathered about DNSSEC? Is it changing DNS patterns? How are our nameservers handling DNSSEC traffic? Is the volume as expected? Have we seen anything unusual? Are there experiences being documented in the form of best practices, or something similar, for transfer of signed zones?
7. DANE and other DNSSEC applications
Using DNSSEC as a means of authentication for http transactions is an exciting development of DNSSEC. What is the progress of the DNS-Based Authentication of Named Entities (DANE) initiative? (See http://datatracker.ietf.org/wg/dane/.) How soon could DANE become a deployable reality and what will be the impact of such a deployment, e.g. impact on traditional certification authorities (CAs)?
8. The Great DNSSEC Panel Quiz
Ever fancied pitting your wits against your colleagues? Demonstrate your knowledge and expertise in DNSSEC in our Great DNSSEC Panel Quiz.
In addition, we welcome suggestions for additional topics.
If you are interested in participating, please send a brief (1-2 sentence) description of your proposed presentation to email@example.com by **Monday, 23 July 2012.**
We hope that you can join us.
On behalf of the DNSSEC Workshop Program Committee:
Steve Crocker, Shinkuro
Jacques Latour, .CA
Simon McCalla, Nominet UK
Russ Mundy, Sparta/Parsons
Ondřej Surý, CZ.NIC
Lance Wolak, .ORG, The Public Interest Registry
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.
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.
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.
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.
Note: This is the second post in a series about the revision of NIST Special Publication (SP) 800-81: Secure Domain Name System (DNS) Deployment Guide.
In revising NIST SP 800-81, I am going through it section by section and seeing what parts need to be revised. This is in addition to an entirely new section with recommendations on recursive servers and validators.
Looking at Sections 1-5, there seems to be relatively little that needs changing, but let’s break it down by section:
Section 1 Introduction: Besides minor updates, bring it into conformance with the newly added section(s), not much to do here.
Section 2 Securing Domain Name System: Most of this section provides background on the DNS and breaks down the various components. Again, since there haven’t been any radical changes to the DNS protocol itself, there aren’t any significant changes. Maybe some additional text in this section about new gTLDs? Other than more information, it will not add anything significant.
Section 3 DNS Data and DNS Software: This section describes the basic roles (authoritative and caching severs). Should a subsection on validators be included? Are validators different enough to include it as a separate subsection or just include some discussion in the subsection covering resolvers?
Section 4 DNS Transactions: and message types (query, dynamic update, NOTIFY, etc.). This section describes the basic transactions in DNS (i.e., query/response, etc.). Since there hasn’t been a new DNS transaction type defined since the first version of this publication, no apparent edits are needed here.
Section 5 DNS Hosting Environment – Threats, Security Objectives and Protection Approaches: This section details some threats to the host systems used in DNS (i.e., servers, resolvers). Most of the section is still relevant, but might need some updating to the sub-section on resolvers to address validation. The discussion is high-level, so trends like virtualization do not need to be discussed, but may be included if there are valid concerns.
As before, comments and/or opinions on the questions above, post them below. They will be considered as the SP 800-81 revision process continues.
The views presented here are those of the author and do not necessarily represent the views or policies of NIST.