DNSSEC in ccTLDs, Past, Present, and Future
Posted by Mark Feldman in Uncategorized on February 1, 2013
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.
DNS Cache Poisoning Attack in Romania – Popular Sites Redirected.
Posted by Scott Rose in DNSSEC, News on December 3, 2012
Arstechnica reports that a possible DNS cache poisoning attack was used against the Romanian (.ro) versions of popular sites like Google, PayPal and Microsoft. While the exact cause is unknown, cache poisoning is suspected since it involved multiple domain names, but not the whole of the .ro domain:
For a span of one to several hours on Wednesday morning, people typing Google.ro, Yahoo.ro, and Romanian-specific addresses for other sites connected to a website that was purportedly run by an Algerian hacker, according to numerous security blog posts, including this one from Kaspersky Lab. Researchers said the most likely explanation for the redirection is a technique known as DNS poisoning, in which domain name system routing tables are tampered with, causing domain names to resolve to incorrect IP addresses.
More information from Kaspersky Lab.
Is my web site being used via a DNSSEC-validator?
Posted by Mark Feldman in Uncategorized on July 30, 2012
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
Posted by Mark Feldman in Uncategorized 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 Uncategorized 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 dnssec-toronto@shinkuro.com 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 Uncategorized 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 Uncategorized 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 Uncategorized 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 Uncategorized 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 Uncategorized 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.
Recent Comments