The Collateral Damage of Internet Censorship by DNS Injection
Posted by Mark Feldman in DNSSEC, News on July 25, 2012
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.
Call for Participation — ICANN DNSSEC Workshop 17 October 2012
Posted by Mark Feldman in ICANN DNSSEC Workshops, Meetings and Workshops on July 16, 2012
As seen in the DNSSEC Deployment Working Group mailing list (subscribe):
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 protected] by **Monday, 23 July 2012.**
We hope that you can join us.
Thank you,
Julie Hedlund
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
DNSSEC Secure transfers: It can be done
Posted by Mark Feldman in News on July 3, 2012
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).
NANOGs 55 & 56
Posted by Mark Feldman in Meetings and Workshops on July 3, 2012
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.
EURid debuts YADIFA name server
Posted by Mark Feldman in News, Tools on July 2, 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”.
DNSSEC in ccTLDs, Past, Present, and Future
Posted by Mark Feldman in DNSSEC Deployment Maps on July 2, 2012
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.
Authenticated Denial of Existence
Posted by Mark Feldman in News, Tools on June 28, 2012
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.
.nl passeert .com met DNSSEC
Posted by Mark Feldman in News on June 27, 2012
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.
Current counts of domain registrations and DNSSEC use for .NL are in the right-hand sidebar of SIDN’s web site (and English translation).
NIST Special Publication 800-81 Revision: Sections 1-5
Posted by Scott Rose in Technical guides on June 21, 2012
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.
What’s *not* Changed in a Year
Posted by Ed Lewis in Uncategorized on June 20, 2012
A minor (personal) milestone — I’ve collected DNSSEC data for the root and TLDs for 366 days (1 year because of the leap day). During the collection I’ve done periodic analysis to see how DNSSEC is being driven by experts and have given a number of presentations on what’s been happening. How DNSSEC is being run? How do the operations differ from what the protocol engineers and RFC writers forecasted? There are presentations in the archives for APRICOT, ICANN, IEPG, RIPE and CENTR meetings that have been held this past winter and spring that cover these questions from different angles.
Now, at the one year mark, for fun, a look at what’s not changed.
Not so noteworthy, because KSK’s are expected to be used on the order of years, these records have been a constant:
- 70 DNSKEY records holding SEP/KSK’s
- 44 DNSKEY RRSIG records, usually signed by SEP/KSK’s
- 46 DS records in the root
But these fairly noteworthy:
- 6 RRSIG records for NSEC/NSEC3PARAM and SOA
- 9 DNSKEY records holding ZSK’s (not alarming, but…)
- 40 NSEC3PARAM – specifically 40 unchanged salts
First an explanation is needed (as usual when analyzing any set of data) – when I write that an RRSIG is unchanged, that refers to the signed-by fields and not the signature payload itself. The TLDs are refreshing signatures as needed, but when the key isn’t changed (as well as some other parameters) my analysis considers the RRSIG to be the same.
What this analysis says is that there are 6 TLDs that have used a ZSK for a full year to generate signatures. Each of the 6 keys is RSA-SHA1 and 1024 bits long. So some are challenging the (“CW”) notion that long lived keys will break. Publishing a ZSK for a year (per se) is not risky, but it shows that at least 9 ZSK’s have a longer lifetime that expected.
Besides the 6 ZSK keys that signed every day, the other three, two never generated signatures and one did so over about a 9 month period.
The 40 unchanged NSEC3PARAM records indicate that 40 TLDs have run NSEC3 for a year (plus) and have not changed the salt (as opposed to the 4 TLDs that change the salt daily or nearly daily). The RFC recommends “with every signing” but few do “batch” signing anymore.
Final note – these counts do not cover the TLDs that have begun operations within the past 366 days.
Ed Lewis
Director, Member of Technical Staff at Neustar
Sponsored By
Recent Comments