Category: DNSSEC

Mar 20

“Introduction To DNSSEC” Animated Videos Uploaded To YouTube

With the buzz over Google’s news about DNSSEC yesterday, we’ve seen a large surge of visitors to our DNSSEC-related resources and in the midst of that someone pointed out that the excellent introduction to DNSSEC video from Shinkuro, Inc., was no longer available on YouTube. Given that we work well with the Shinkuro team, we reached out to them and found out that while they maintain a copy of the video on their site, they had not been responsible for the YouTube version.  With their permission, we have now uploaded the video to our Deploy360 YouTube channel and can make it available for embedding and viewing:

The silent animated video was created back in 2006 but continues to be an excellent illustration of how the DNSSEC process works and the threats it protects again.  Thanks again to Shinkuro for making the video available.

As we note on our resource page about the video, there is also a second version that doesn’t include the text narration on the right side that some of you may find useful if you want to show a video about DNSSEC and provide your own narration.  (In fact… it might be an interesting exercise to take this second video and create versions with voice-overs in a number of different languages – if you do that and create a version, let us know and we’ll look at linking to your video.)

 

Mar 20

Video – DNSSEC Deployment: From End-Customer To Content (ION San Diego)

What do we need to do to get DNSSEC widely deployed? How can we help accelerate the deployment? What is the benefit to network operators and content providers?  These were among the questions answered in a highly interactive panel at the ION Conference San Diego on December 11, 2012. There was a good dialogue between the panelists and many questions asked by the attendees.  As a moderator, it was one of the most fun and interesting panels I’ve done in a while as we had no slides and just engaged in a conversation among people with a deep amount of experience with DNSSEC.

You can watch the video on YouTube or embedded here:

Moderator: Dan York (Internet Society)
Panelists: Jim Galvin (Afilias); Richard Lamb (ICANN); Cricket Liu (Infoblox); Roland M. van Rijswijk — Deij (SURFnet)

To get started with DNSSEC, you may want to view our DNSSEC Basics page.

Mar 19

Google Public DNS – DNSSEC Validation

Google logoGoogle provides DNSSEC validation through the use of their “Google Public DNS” servers.  If your local DNS resolvers do not perform DNSSEC validation, you can change your operating system to point to the following DNS servers operated by Google for either (or both) IPv4 and IPv6:

8.8.8.8
8.8.4.4

2001:4860:4860::8888
2001:4860:4860::8844

Once configured, all future DNS queries will be resolved using these DNS servers and DNSSEC validation (if requested) will be performed by Google’s servers.  You will then benefit from the added protection of DNSSEC validation.

Typically this configuration is changed wherever you modify your network settings.  In Windows, this is usually in your “Control Panel” while in Mac OS X this will be in the Network part of your “System Preferences”.  For Linux and other operating systems the exact procedure will vary.

Note that there is one important caveat here - you have to request DNSSEC validation when you send the DNS query to Google’s Public DNS servers, i.e. they will only validate the DNS query if you request it.  To do that you need an application that supports DNSSEC.  For web browsers, there are add-ons and extensions for both Google Chrome and Mozilla Firefox:

If you are an application developer, there are DNS developer libraries that support DNSSEC available in a wide range of programming languages so that you can add DNSSEC support to your application.

You can test DNSSEC validation by attempting to visit one of the deliberately misconfigured sites listed on our DNSSEC Tools page.

Google provides the following information about using their Public DNS service:

The addition of DNSSEC was announced in March 2013 and noted that Google Public DNS is currently “serving more than 130 billion DNS queries on average (peaking at 150 billion) from more than 70 million unique IP addresses each day.”

Note: To get the most value out of DNSSEC, you need to use a DNSSEC-validating resolver, and also sign your domains. If you have domains registered, learn about how your can sign your domains with DNSSEC using domain name registrars.

Mar 19

Huge News For Internet Security – Google Public DNS Is Now Performing DNSSEC Validation!

Google logoIn a huge step forward for Internet security today, Google announced that Google’s “Public DNS” service is now performing DNSSEC validation. What this means is that anyone using Google’s DNS servers (and anyone can do so – see below) can now get the increased security that comes with DNSSEC.  (Learn more about the value of DNSSEC on our DNSSEC Basics page.)

It also means that if you want the added security of DNSSEC, but your Internet Service Provider and local operating system don’t validate with DNSSEC,  you can simply change your operating system to point to the following DNS servers operated by Google for either (or both) IPv4 and IPv6:

8.8.8.8
8.8.4.4

2001:4860:4860::8888
2001:4860:4860::8844

Once configured, all future DNS queries will be resolved using these DNS servers and DNSSEC validation will be performed by Google’s servers.  You will then benefit from the added protection of DNSSEC validation.  (Our resource page about Google Public DNS offers a few more pointers about configuration.)

Note that there is one important caveat here - you have to request DNSSEC validation when you send the DNS query to Google’s Public DNS servers, i.e. they will only validate the DNS query if you request it.  To do that you need an application that supports DNSSEC.  For web browsers, there are add-ons and extensions for both Google Chrome and Mozilla Firefox:

If you are an application developer, there are DNS developer libraries that support DNSSEC available in a wide range of programming languages so that you can add DNSSEC support to your application.

In the announcement, Google’s Yunhong Gu noted that Google Public DNS is currently “serving more than 130 billion DNS queries on average (peaking at 150 billion) from more than 70 million unique IP addresses each day.”  As the article further notes:

“Effective deployment of DNSSEC requires action from both DNS resolvers and authoritative name servers. Resolvers, especially those of ISPs and other public resolvers, need to start validating DNS responses. Meanwhile, domain owners have to sign their domains. Today, about 1/3 of top-level domains have been signed, but most second-level domains remain unsigned. We encourage all involved parties to push DNSSEC deployment and further protect Internet users from DNS-based network intrusions.”

To that end, if you have domains registered, we strongly encourage you to learn about how your can sign your domains with DNSSEC using domain name registrars.  You can learn more about which top-level domains support DNSSEC on our DNSSEC Statistics page.

Google provides the following information about using their Public DNS service:

This move by Google to provide this DNSSEC validation is a great addition to the support for DNSSEC validation offered by large US ISPs such as Comcast (making DNSSEC validation available to their 18 million customers) as well as ISPs in a wide range of countries including Sweden, the Czech Republic and Brazil.

We look forward to seeing more public DNS providers and more ISPs turn on DNSSEC validation in their networks.  If you want to know more about what is involved with enabling DNSSEC validation on your network, including home and enterprise networks, this SURFnet white paper provides easy instructions for common DNS servers.

And in the meantime, if you don’t want to wait for your ISP and want to start getting the value in DNSSEC validation today, you now have the option of using Google’s public DNS servers!

 

Mar 14

Deploy360@IETF86: Day 4 – IPv6, DNSSEC and Routing, Oh, My!

IETF LogoDay 4 of the 86th meeting of the Internet Engineering Task Force (IETF)  hits all of our Deploy360 topics – IPv6, DNSSEC and Routing Resiliency/Security.

General information about participating remotely can be found on the Remote Participation page as well as the IETF86 agenda – specific info for the groups we are following is included below.

0900-1130 Thursday, March 14

Homenet – Caribbean 3
This working group focuses on the evolving networking technology within and among relatively small “residential home” networks.

Interface to the Routing System (I2RS) – Caribbean 5
This is a new working group meeting for the first time that is seeking to define a publicly documented interface into the Internet’s routing system for applications to use. The best way to understand this new group would be to read draft-atlas-i2rs-problem-statement.

1300-1500 Thursday, March 14

Port Control Protocol (PCP) – Caribbean 6

The PCP working group is back again looking at how to enable communication from applications across middleboxes such as Network Address Translation (NAT) devices and firewalls for both IPv4 and IPv6.

Two other groups also may be of interest during this time block:

1510-1710 Thursday, March 14

Dynamic Host Configuration (dhc) – Caribbean 1
The DHC working group looks at DHCP and aspects of dynamically configuring IP addresses, both for IPv4 and IPv6, although the focus these days is on DHCPv6.

Operational Security  (opsec) – Caribbean 3
The OPSEC working group looks at the operational security concerns of IP networks. In this meeting there are 3 drafts focused on the security of IPv6 networks.

1730-1830 Thursday, March 14

Dynamic Host Configuration (dhc) – Caribbean 1
The DHC working group will continue to meet during this timeslot. Information is above.

DNS Operations  (DNSOP) – Caribbean 4
The DNSOP Working Group focuses on operational aspects of the Domain Name System and at this session has multiple drafts relating to DNSSEC.

1900-2100 Bits-N-Bites

This reception / networking time in Grand Sierra D should be an interesting chance to look at new technology from a number of sponsors.

2000-?  Alternative PKI Side Meeting, Boca 4

For those people interested in authentication and the public key infrastructure (PKI) aspects of the Web, there will be an “Alternative PKI Models Side Meeting” in room Boca 4, the IAB office, to talk about the requirements, goals and the design assumptions for a Web PKI.  Given our interest in DNSSEC and DANE, I (Dan) will be in this meeting to participate.

And after all of that… we’ll be trying to figure out how to get some food.  :-)

P.S. For a broader view of the Internet Society’s interest in IETF 86 beyond that of just the topics we cover here at Deploy360, please see our “Rough Guide to IETF 86′s Hot Topics“.

NEW! Listen to this post (and please follow Deploy360 on SoundCloud if you use that service):

Mar 08

DNSSEC Discussion In DNSOP Working Group At IETF86 Next Week

IETF LogoAt the 86th meeting of the Internet Engineering Task Force (IETF) next week in Orlando there is one primary working group where DNSSEC will be discussed, the DNSOP (DNS Operations) working group.  As noted in our recently-published “Rough Guide To IETF 86′s Hot Topics“, DNSOP develops guidelines for the operation of DNS software servers and the administration of DNS zone files. It also documents DNSSEC operational procedures and looks at DNS-related IPv6 transition and coexistence issues.

The meeting is on Thursday, March 14, from 17:30 – 18:30 US Eastern time. The agenda and working group charter are:

Agenda: https://datatracker.ietf.org/meeting/86/agenda/dnsop/
Charter: https://datatracker.ietf.org/doc/charter-ietf-dnsop/

There are two major DNSSEC-related documents being discussed. First is draft-livingood-negative-trust-anchors, an interesting idea about how to use a “Negative Trust Anchor” to indicate within the DNSSEC-validating resolver that you want to accept DNS records for a given domain even if the DNSSEC-validation cames back as bad.  The primary use case for this is when there is a breakage of the DNSSEC chain of trust caused by, for instance, accidentally letting a key expire for a domain.  This idea came about from the team at Comcast when they dealt with issues like the nasa.gov key expiration.  It’s intended as a temporary measure that administrators can use while we are getting more DNSSEC deployed and the tools and processes are still evolving.

The second document is draft-kumari-ogud-dnsop-cds, a new draft that proposes a method of solving the dilemma of how to communicate a new Key Signing Key (KSK) to the parent domain using DNS itself.  This issue has been an ongoing challenge that has been in need of simplification – and this approach is one such proposal.  The mechanism, though, has proven to be quite contentious with a large volume of email to the dnsop mailing list.  It should generate quite an interesting discussion in the DNSOP meeting!

There may be a few other DNSSEC-related documents floating around in other working groups, but the DNSOP group on Thursday will be the major location of DNS-related discussion at this IETF 86 meeting.  Other DNS-related working groups such as DANE and DNSEXT chose not to meet as their work has been going on through the mailing lists and did not require a face-to-face meeting this time.

Note that if you can’t participate in person, there are several ways to participate remotely via audio, Jabber chat, WebEx and MeetEcho.

P.S. 3 of the 4 DO Team members will be at IETF 86 next week – please do say hello if you are there!

Feb 26

Video – DNSSEC: What Every Sysadmin Should Be Doing To Keep Things Working (USENIX LISA)

DNSSEC session at LISA '12At the USENIX LISA ’12 conference in December 2012, Roland Van Rijswijk of SURFnet gave a great talk titled “DNSSEC: What Every Sysadmin Should be Doing to Keep Things Working” where he talks about how you are perhaps already using DNSSEC – and what you need to do to make sure it keeps working. Roland’s an enjoyable presenter and I think you’ll enjoy his session. The presentation is available in both video and audio at:

https://www.usenix.org/conference/lisa12/dnssec-what-every-sysadmin-should-be-doing-keep-things-working

His slides are also available for download.

I’d note, too, that Roland is one of the people involved with SURFnet’s excellent white paper on deploying DNSSEC validation on recursive caching name servers that is definitely worth a read for anyone looking to deploy DNSSEC validation within your network.

Feb 22

Canada Joins The DNSSEC World – Sign Your .CA, Eh?

Toy beaver from .CACongratulations to our friends up North in Canada for the DNSSEC signing of the .CA domain, joining the ever-growing list of top-level domains (TLDs) that are securing their DNS records with DNSSEC!  As Jacques Latour of the Canadian Internet Registration Authority (CIRA) outlined in a CIRA blog post they took some time to ensure their system was resilient:

We wanted to create a comprehensive DNSSEC validation process, so we took a different approach to sign .CA that takes into account several known DNSSEC-related issues that affect its operation. Our approach addresses these issues, and we believe we have developed a resilient solution that will result in high availability/no outages.

We created dual independent signing engines using Bind and OpenDNSSEC. There were a few challenges along the way. For example, Bind and OpenDNSSEC produce different, although valid signed zone files and both handle signing differently. These challenges, though, were worth overcoming. The end product will not only be an improved system for .CA, but we’re blazing a new trail here – the global Internet community will benefit from this work.

It’s great that CIRA went through this effort and we look forward to learning from them as they share more information about what they did.

Now, publishing the signed .CA zone is just the first step in enabling DNSSEC for .CA domains.  They still have some work to do before they can begin accepting DS records from registrars that support DNSSEC.  Their stated goal is to complete that work this year so that in 2014 they can begin accepting signed domains.

In the meantime, we’ve been told that people who can sign and host their .CA domains can contact CIRA at  cira-dnssec@cira.ca to find about how to manually get their DS record into the .CA zone.

This is great work and we look forward to seeing more about DNSSEC and .CA over this year.  CIRA has published a DNSSEC page with information. Over on Dark Reading, David Schwartzberg also wrote about Canada joining the DNSSEC party.

Congrats, again, to Jacques Latour and the whole team at CIRA!

P.S. And yes, I did pick up the toy beaver in the photo from a .CA booth at a conference… having lived in Canada for 5 years I enjoy that the .CA team can have some fun with some of the Canadian stereotypes. :-)

Jan 24

RFC 6841 Outlines How To Write DNSSEC Policies and Practice Statements

Back in July 2012, we wrote about “How To Write a DNSSEC Practice Statement (DPS)” and referenced an Internet-Draft that explained the process.  We’re very pleased to see that that I-D was just published this month as a formal RFC:

RFC 6841 – A Framework for DNSSEC Policies and DNSSEC Practice Statements

As the abstract says:

This document presents a framework to assist writers of DNS Security Extensions (DNSSEC) Policies and DNSSEC Practice Statements, such as domain managers and zone operators on both the top level and secondary level, who are managing and operating a DNS zone with Security Extensions implemented.

In particular, the framework provides a comprehensive list of topics that should be considered for inclusion into a DNSSEC Policy definition and Practice Statement.

It’s well worth a read not only if you are an operator of a Top-Level-Domain (TLD) or one of the newgTLDs (all of whom are mandated to support DNSSEC), but also if you are with an enterprise/company that is considering hosting all the DNSSEC-signing for your domains yourself.

If you want examples of what these DPS documents look like, we maintain a list of DNSSEC Practice Statements that includes documents from many of the major TLDs.  (And we’re always open to adding more if you have a published DPS online.  Just let us know.)

Jan 22

Slides: Early DNSSEC Deployment Observations from Ed Lewis

What have we seen in terms of DNSSEC deployment around the world? Are there general trends or themes we can understand? Can we dive a bit deeper into some of the algorithms used in DNSSEC signatures?

In an October 2012 presentation to NANOG 56, Ed Lewis of Neustar dug into all these questions and more.  The slides make for interesting reading, particularly some of the details about which crypto algorithms were used and what key lengths were used.   He also looked at the frequency of key changes, key rollover processes and included a whole section on NSEC/NSEC3 records.

All in all an interesting set of data and some good recommendations around guidance that is needed for the industry.  Well worth your time to scan through the slide deck if you are interested in statistics around DNSSEC deployment.