They have now also updated their FAQ about DNSSEC support in Google Public DNS and most importantly updated these two questions (my emphasis added):

Does Google Public DNS support the DNSSEC protocol?
Yes. Google Public DNS is a validating, security-aware resolver. Currently this is an opt-in feature: for queries coming from clients requesting validation (the AD and/or DO flag is set), Google Public DNS verifies that response records are correctly authenticated. Validation by default (i.e. for all queries) will be enabled soon.

Which client resolvers currently enable DNSSEC?
Unfortunately, most standard client stub resolvers do not enable full DNSSEC checking and cannot be easily reconfigured to do so. We have decided to make our initial launch only cover resolvers that explicitly ask for DNSSEC checking so that we become aware of any problems before exposing our users to possible large-scale DNS failures due to DNSSEC misconfigurations or outages. Once we are happy that we can safely enable DNSSEC for all users except those who explicitly opt out, we will do so.

It’s great to see Google responding to questions and adding these clarifications – and from the point of view of advocacy for DNSSEC deployment, it is great to have Google out there endorsing and promoting DNSSEC as a way to increase Internet security.

(And you can easily get started with DNSSEC if you haven’t already.)

For those of you who enjoy listening to audio, I recorded some audio commentary on our SoundCloud channel about why I view this news from Google as incredibly important:

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:

• How To Add DNSSEC Support To Google Chrome
• How To Add DNSSEC Support To 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:

• Overview of Google Public DNS
• Using Google Public DNS
• DNSSEC section of the Google Public DNS FAQ
• Security Benefits (which includes mention of DNSSEC)

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.

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:

• How To Add DNSSEC Support To Google Chrome
• How To Add DNSSEC Support To 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:

• Overview of Google Public DNS
• Using Google Public DNS
• DNSSEC section of the Google Public DNS FAQ
• Security Benefits (which includes mention of DNSSEC)

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!

PowerDNS

In speaking with Bert last week, he said the team there views DNSSEC as basically “done” now for the authoritative server end and is now moving to focus on what they can do to make DNSSEC easier for deployment in DNS resolvers.  We’re looking forward to seeing what the team does there.

Meanwhile, if you are a PowerDNS user, the new release will give you even more DNSSEC power… time to upgrade!

If so, here are some quick instructions about how to install the Unbound DNS resolver that supports DNSSEC validation into OpenWRT.  What this will do is change the DNS resolver in your access point to start performing DNSSEC validation… so as more domains get signed you’ll be able to know that you are, in fact, getting to the correct domain. Plus, with DNSSEC validation available you’ll be able to start playing around with very cool new technologies like the DANE protocol… who knows what you’ll be able to do with it!

The great thing is that it turns out to be a trivial process, which is great to see!

P.S. While you’re hacking on your devices, check out some of the other DNSSEC tools we are listing…

As we outlined before, there are a number of different tools you can use.  One that is perhaps the simplest, though, is a package for Linux from Paul Wouters called “hash-slinger” that is available at:

http://people.redhat.com/pwouters/hash-slinger/

One of the tools provided in the package is a command “tlsa” which does exactly what you might think – generate the TLSA record!  Paul showed how easy it is:

$ tlsa --create ietf.org
No certificate specified on the commandline, attempting to retrieve it from the server ietf.org.
Attempting to get certificate from 64.170.98.30
Got a certificate with Subject: /O=*.ietf.org/OU=Domain Control Validated/CN=*.ietf.org
_443._tcp.ietf.org. IN TLSA 3 0 1 54f3fd877632a41c65b0ff4e50e254dd7d1873486231dc6cd5e9c1c1963d1e4e

That’s it!  Now you can copy that record to your DNS zone file and you will be in the business of publishing a TLSA record!

Well, okay, it might not be that simple.  If your nameserver or DNSSEC-signing tool doesn’t yet support the TLSA record (outlined in RFC 6698), you might need to add a “-o generic” flag onto the command line to get the appropriate record. And you might want to add on more options, as Shumon Huque did in his walk-through of setting up a TLSA record.

The key is that this tool is out there and can help all of us interested in getting the DANE protocol more widely deployed to start getting TLSA records more visible. Kudos to Paul for developing the tool and making it available.

If you use SSL/TLS on your sites, and you have your domain signed with DNSSEC, why not go the extra step and get a TLSA record out there?

The package is available for Linux at:

http://people.redhat.com/pwouters/hash-slinger/

One of the tools provided in the package is a command “tlsa” that generates TLSA records (outlined in RFC 6698). Paul Wouters showed how easy it is:

$ tlsa --create ietf.org
No certificate specified on the commandline, attempting to retrieve it from the server ietf.org.
Attempting to get certificate from 64.170.98.30
Got a certificate with Subject: /O=*.ietf.org/OU=Domain Control Validated/CN=*.ietf.org
_443._tcp.ietf.org. IN TLSA 3 0 1 54f3fd877632a41c65b0ff4e50e254dd7d1873486231dc6cd5e9c1c1963d1e4e

You can now copy that record to your DNS zone file and be in the business of publishing a TLSA record.

If your nameserver or DNSSEC-signing software does not yet support the TLSA RRtype defined in RFC 6698, you can create a “generic” record type:

$ tlsa --create -o generic ietf.org
No certificate specified on the commandline, attempting to retrieve it from the server ietf.org.
Attempting to get certificate from 64.170.98.30
Got a certificate with Subject: /O=*.ietf.org/OU=Domain Control Validated/CN=*.ietf.org
_443._tcp.ietf.org. IN TYPE52 \# 35 03000154f3fd877632a41c65b0ff4e50e254dd7d1873486231dc6cd5e9c1c1963d1e4e

The “tlsa” command also has other options for generating other types of TLSA records.

At the recent ICANN45 DNSSEC Deployment Workshop, Paul Wouters from Red Hat spoke about integrating DNSSEC into Linux. Paul’s slides are available for download and a video of the entire workshop is available from the main page.

In the presentation, Paul talks about the difference between Fedora and Red Hat Linux and then dives into what needed to be modified to support DNSSEC. He provides some insight into their experiences using DNSSEC in different configurations and with different tools.

Paul also spoke about support for the DANE protocol to use DNSSEC to validate SSL/TLS certificates and in particular his TLSA Validator add-on for the Firefox browser and his “hash-slinger” tool that generates TLSA records.  Both tools are available at his site at:

http://people.redhat.com/pwouters/

It was a great presentation to hear, and Paul is very active within the DNSSEC community working on tools such as these to help get DNSSEC further deployed. It is well worth some time checking out his tools.

http://www.dnssec-tools.org/download/

Some of the changes include:

• dnssec-nodes – many new features and graphing capabilities
• libval – support for the TLSA recorded needed for the DANE protocol
• dnssec-check – increased stability

As an advocate for the powerful capabilities of DANE, I’m particularly pleased to see that support added for TLSA records.

You can find out more information on the main dnssec-tools.org web page.

I know from speaking with Sparta’s Russ Mundy at the ICANN 45 workshop that he and the others involved with the DNSSEC-Tools project are definitely looking for user feedback – and also looking to understand what other DNSSEC-related tools people might find useful.  Please do give this new release a try and let the team there know how it works for you.

Yesterday at the DNSSEC Deployment Workshop at ICANN 45 in Toronto I learned that the good folks at SIDN Labs in the Netherlands have created a service that allows you to do just that… and they are offering it for free public usage.

They provide two ways to use the service: 1) a web interface where you upload a file; or 2) a RESTful API you can query.  The web interface is in Dutch, but for non-Dutch-speakers it’s not hard to figure out (or translate via browsers):

http://check.sidnlabs.nl:8080/form

You just upload a file and the service will give you back the results of whether the domains are secure, insecure or failing validation (‘bogus’).

What was more interesting to me, though, was the RESTful API allowing you to query the status of a domain by simply connecting to:

http://check.sidnlabs.nl:8080/check/domainname

as in:

http://check.sidnlabs.nl:8080/check/internetsociety.org

The comma-separated results that come back are:

internetsociety.org,"",secure,""

with the third field being either “secure”, “insecure” or “bogus”.

My immediate thought was how I could use this to create a simple little program to help me remember which of my domains I have signed and which ones I still need to sign.  After playing around with it for a few minutes in python, I decided that others might find my experiments useful or interesting, so I uploaded them to a Github repository at:

https://github.com/Deploy360/dnssec-portfolio-checker-examples

I included one very simple example that does no error checking and simply issues queries based on a list in the program.  I then added a second example that you could use from a command line to query for one or more domains:

python dnssec-check.py internetsociety.org ietf.org dnssec-failed.org

(Omitting the ‘python’, of course, if you change ‘dnssec-check.py’ to be executable.)  An obvious extension would be to make the program accept the name of a file containing domain names.  You could also change it so that “bogus” entries come out on top or have big “Danger! Danger!” warnings of some type. I may make a web page that when I go to it shows me visually which of my domains are signed and which aren’t.  There’s a hundred other things you could do with it.  My purpose was just to try it out and see how the API worked.

Feel free to use those examples in whatever way you want… and thanks to SIDN Labs for making this service available for any of us to use!