Category: DNSSEC

Oct 19

Walking Through Setting Up A TLSA Record for DNSSEC/DANE

In a post titled “DNSSEC and Certificates” today, Shumon Huque provides a nice walk-through of the steps needed to get set up with a TLSA record in DNS to tie a SSL/TLS certificate into the global chain-of-trust created by DNSSEC. First, though, he explains very succinctly why we should care about security issues related to current certificate authorities (CAs) and how the new DANE protocol helps address this.

He then steps through what he had to do with openssl to create the appropriate TLSA record for his existing SSL certificate (and points out the availability of Paul Wouters hash-slinger tool to make this even easier).

It’s good to see posts like this explaining the process and we’ll be looking to add tutorials like this to our site as we continue to expand our DANE coverage in the weeks and months ahead.

By the way, Shumon will be one of the speakers at our ION San Diego conference on December 11th.  If you want to learn about DNSSEC and IPv6 topics and can get to San Diego, we’d definitely suggest you consider attending!

P.S. We’ve added Shumon’s site to the list of DANE test sites that developers can use to test out new DANE applications.

Oct 18

Code Examples: Checking the DNSSEC Status Of A Large Number of Domains

SIDN LabsDo you want to check the DNSSEC status of a large number of domains?  To know whether they are signed or unsigned? Or perhaps if any of the domains are failing validation?

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!

Oct 17

ICANN45 DNSSEC Deployment Workshop Streaming Live NOW From Toronto

ICANN TorontoWant to hear case studies about DNSSEC deployment all around North America? To hear about new DNSSEC tools?  To learn about what has and has not worked for encouraging DNSSEC deployment?

If so, you can listen live right now to the DNSSEC Deployment Workshop happening at the ICANN 45 meeting in Toronto.  More info at:

http://toronto45.icann.org/node/34375

You can either listen to an audio stream or use Adobe Connect to listen and see the slides.

That link also includes the agenda for the full session as well as all the slides.  The titles include:

  • Introduction and Presentation: DNSSEC Deployment Around the World
  • Panel Discussion: DNSSEC Activities in North America
  • Panel Discussion: DNSSEC in the Wild
  • The Great DNSSEC Quiz (Version 2)
  • Panel Discussion: Encouraging DNSSEC Adoption, What Has Worked and What Hasn’t
  • Panel Discussion: Solutions to Help People Implement DNSSEC
  • Presentation: Next Steps in Accelerating DNSSEC Deployment(my presentation)
  • Panel Discussion: DNSSEC and the New gTLD Program

I’ll be speaking at 2:00pm US Eastern on “Next Steps in Accelerating DNSSEC Deployment” where I’ll be outlining some of what we’ve learned in building out the DNSSEC part of Deploy360 and where we think the industry should be heading.

There are some great case studies and information being presented here.  If you can’t listen live it will also be available as a recording.

Oct 10

21 Sites You Can Use To Test DANE Support (DNSSEC + SSL/TLS)

Have you been working on an application that uses the new DANE protocol to combine the encryption of SSL/TLS with the strong integrity protection of DNSSEC? Have you been looking for a way to test your application with a variety of different test cases? If so, we’ve started compiling a list of sites that are currently publishing the TLSA records used by DANE. You can find the list at:

http://www.internetsociety.org/deploy360/resources/dane-test-sites/

As you’ll see on that page, we currently have sites listed for the following protocols and situations:

  • HTTP – Valid TLSA Record With Valid CA-signed TLS Certificate
  • HTTP – Valid TLSA Record With Valid Self-signed TLS Certificate
  • HTTP – Valid TLSA Record With Invalid CA-signed TLS Certificate
  • HTTP – Invalid TLSA Record
  • HTTP – Valid TLSA Record With Invalid DNSSEC Signature
  • SMTP
  • XMPP/Jabber

If you are currently publishing TLSA records, please do let us know and we’ll be glad to add your site to the list. In these early days we’d like to make it as easy as possible for developers to find sites with which they can test their apps.

Thanks – and we’re looking forward to seeing the wide deployment of DANE enabling a much more secure Internet!

 

Oct 05

Video: The DANE Protocol – What It Is And How It Helps Make The Internet More Secure (via DNSSEC and TLS/SSL)

What is the DANE protocol all about?  How does it help make the Internet more secure?  How does it work with DNSSEC and TLS/SSL certificates?  What added security does DANE provide?

In this interview at IETF 84 in Vancouver this summer, I spoke with Warren Kumari, co-chair of the DANE Working Group within the IETF, about all these questions and also what the future holds for DANE:

To learn more about DANE and how to get involved, you can:

We will also be updating our page about the DANE protocol with additional resources, tutorials, tools, test sites and more information in the weeks ahead. There are some great tools under development, including plugins for browsers and tools to generate TLSA records.

Oct 04

DANE Test Sites

The following sites support the DANE protocol by publishing TLSA records. If you are developing software that supports the DANE protocol, you can visit these sites to test your DANE support.  Note that we use the term “TLS certificate” here for what is commonly referred to as a “SSL certificate”.

 HTTP – Valid TLSA Record With Valid CA-signed TLS Certificate

The following sites use a valid CA-signed TLS certificate, but the CA is CAcert, a free CA that is not commonly configured in web browsers:

The following site has a valid TLSA record and a valid CA-signed TLS certificate, but the domain is not tied into the global DNSSEC chain-of-trust, i.e. there is no DS record for huque.com in the .COM TLD:

HTTP – Valid TLSA Record With Valid Self-signed TLS Certificate

HTTP – Valid TLSA Record With Invalid CA-signed TLS Certificate

HTTP – Invalid (Broken) TLSA Record

HTTP – Valid TLSA Record With Invalid DNSSEC Signature

SMTP

The following sites support using DANE for email by publishing TLSA records associated with MX records:

  • jhcloos.com
  • nlnetlabs.nl (for ports 25, 465, 587)
  • nlnet.nl (for ports 25, 465, 587)

XMPP / Jabber

The following sites support using DANE for TLS connections to their XMPP/Jabber server:

  • jabber.nlnetlabs.nl

Adding More Sites

If you support DANE with your site and would like to add it to this list, please contact us. Eventually, of course, we would like to hope that DANE is so widely deployed that this list of test sites will no longer be needed.

Oct 04

RFC 6698 – The DNS-Based Authentication of Named Entities

For anyone interested in how to better secure the Internet, the DANE protocol (“DNS-Based Authentication of Named Entities“) provides a mechanism for using DNSSEC to specify precisely which SSL/TLS certificate you want people to use to connect to your web server or other Internet service.  This provides a mechanism for ensuring that you are in fact using the correct certificate and your connection is not being intercepted by anyone in your network path.  DANE is defined in RFC 6698 at:

The abstract is:

Encrypted communication on the Internet often uses Transport Layer Security (TLS), which depends on third parties to certify the keys used. This document improves on that situation by enabling the administrators of domain names to specify the keys used in that domain’s TLS servers. This requires matching improvements in TLS client software, but no change in TLS server software.

Please view our page on the DANE protocol for more information about how the protocol can be used and how it helps make the Internet more secure.

Oct 04

The DANE Protocol – DNS-Based Authentication of Named Entities

If you connect to a website using a “secure” connection over TLS/SSL, how do you know you are using the correct TLS/SSL certificate?

You may see the “lock” icon in your web browser, but are you sure that you are connecting all the way to the website using the correct TLS certificate?  It is in fact quite possible – and quite common – for a firewall or other device in your network path to terminate your TLS connection with a website and then re-create a TLS connection from the device to your browser.  You think you have a secure, encrypted connection to your bank, for instance, but in fact your connection has been intercepted and the firewall or other device is able to see, and potentially record, all your interaction with the web site.

With DNSSEC now being deployed, a new protocol has emerged called “DANE” (“DNS-Based Authentication of Named Entities“) that allows you to securely specify exactly which TLS/SSL certificate a browser should use to connect to your site.  If a web browser supporting DANE detects that it is NOT using the specified certificate, it can warn you that your connection is insecure… even though you see a “lock” icon.

DANE is defined in RFC 6698 and over the next few months we will be adding more tutorials and document to this site to help you understand both how DANE helps make the Internet more secure and also how you can get started either publishing TLSA records for your domain – or using DANE within your application.  Note that DANE is not just for websites. People are already looking at how DANE can be used to secure email, VoIP and other web services.

For an explanation of the DANE protocol, watch this interview with Warren Kumari, co-chair of the DANE Working Group within the IETF:

[Additional screencast to be inserted here explaining how DANE works.]

Another good introduction to DANE is an IETF Journal article published in October 2011 titled “DANE: Taking TLS Authentication to the Next Level Using DNSSEC“. In the article, Richard Barnes explains why DANE is needed, outlines how it works, digs into some of the challenges with DANE implementation and provides a good number of links for more information.

Content Providers

[This section will explain to website owners/operators and providers of other services how they can publish TLSA records to make their sites more secure.]

Application Developers

The following libraries are in the process of adding support for the DANE protocol:

  • dnspython – the development version of dnspython found on Github has had support for TLSA records added to the code base. This is not yet available in a formal release.
  • ldns – an upcoming release of ldns will provide support for DANE (this page will be updated when the release occurs).

Other resources for developers:

  • DANE Test Sites – If you are adding DANE support to your application and wish to test out how well it works, the sites on this page are early supporters of the protocol and can be used in your testing.

Getting More Involved

If you would like to get more involved in the development of the DANE protocol and supporting documentation, you can:

Oct 02

How Do We Measure DNSSEC Deployment?

Map of DNSSEC-validating usersHow do we measure the actual deployment of DNSSEC?  How can we know how many domain name holders have signed their zones with DNSSEC? How can we find out how many ISPs have deployed DNSSEC-validating resolvers? How do we count how many applications or operating systems have built-in support for DNSSEC validation?

At first glance, some of these would appear to be simple questions to answer – “well, can’t you just count up the number of DS records in a top-level domain?” But the reality is that it’s not quite that simple.  There are sites providing DNSSEC deployment statistics and some TLDs are making DNSSEC usage available… but that’s not true across the board.  And the validation question is quite difficult due to the distributed and decentralized nature of the Internet.  We recently wrote about some work Verisign Labs is undertaking to measure validation, but that work is just beginning.

The APNIC Experiment

So we were delighted to see the post, “Counting DNSSEC” and accompanying presentation from Geoff Huston and George Michaelson at APNIC Labs where they dug into this DNSSEC measurement issue in a unique way.  As Geoff writes, they set out to look at these questions:

  • How many zones are DNSSEC signed?
  • How many DNS queries are DNSSEC-validated?
  • How many DNS resolvers are DNSSEC-capable?
  • How many users are using DNSSEC-aware DNS resolvers?

But rapidly concluded that these precise questions were difficult to answer – and so they decided to look a bit more broadly at these questions:

  • What proportion of DNS resolvers are DNSSEC-capable?
  • What proportion of users are using DNSSEC-validating DNS resolvers?
  • Where are these users?

Their measurement technique was to use advertisements in web browsers displayed through an advertising network.  They used a flash-based ad that made multiple DNS requests without user intervention, i.e. the user didn’t have to click on the ad – just the action of displaying the ad triggered the measurements.

They ran the test from September 10-17, 2012, and observed 57,268 unique IP addresses requesting the DNS records. Some of the conclusions were interesting:

  • 4% of DNS resolvers performed DNSSEC validation
  • 9% of end-client systems were using a DNSSEC-validating resolver

Their post goes through all this in great detail and provides a much more thorough explanation than I can do here.

They then went on to look at where the users were coming from and provide charts segmenting their data in multiple different ways.   They summarized all of this in a presentation to the recent RIPE 65 event complete with charts showing the validation by country.  I’d highly recommend you take a look at that presentation as it provides an excellent view into all this data.

As with any survey like this, you can always wonder about the distribution of people seeing the displayed ad. My first thought was that as I browse with Flash disabled by default I would never have triggered their measurement had it been displayed on my screen.  Similarly many mobile devices might not execute Flash, notably Apple devices, and so it would miss those users.

But even with those caveats, this is an excellent piece of work as an attempt to perform some basic measurements.  Geoff notes at the end of the post that they’ll perform another look at DNSSEC deployment in a few months time, and we’re very much looking forward to seeing what difference they’ll measure in that next look.

What Else Can Be Done?

Beyond this work, we are still thinking a great bit about what else can be measured.  For instance, can we as an industry develop:

  • a count of registrars supporting DNSSEC by allowing upload of DS records?
  • a count (or %) of DNS hosting providers providing automated DNSSEC signing?
  • a % of ISPs providing validating name servers?
  • a % of signed second-level domains?

On this last point, there are great examples already out there including the PowerDNS stats for .NL and other domains, the Verisign Labs scoreboard for .COM/.NET/.EDU and the NIST statistics for the US Gov’t and industry, but it would be even better if we could aggregate this information and also obtain that information for other TLDs.

How can we best measure the deployment of DNSSEC?  It’s an interesting question… do you have any thoughts about other methods and mechanisms?

 

Sep 11

Can You Add 1 Line of HTML To Your Site To Help Measure DNSSEC Usage?

DNSSEC validator search resultsCan you please help out with efforts to measure the number of DNSSEC-validating DNS resolvers out there?

The folks at Verisign Labs are conducting some research into trying to understand what level of DNSSEC-validating resolvers are out on the open Internet. This is critical to understand as the availability of DNSSEC-validating resolvers is a key piece of getting DNSSEC deployed.

They are asking for your help.

If you operate a website, they are asking if you can please add one line of HTML to your site, preferably in a page header, footer, sidebar or other component that gets frequently loaded:

<a href=”http://prefetch.validatorsearch.verisignlabs.com”></a>

That’s it!  As they say on their page:

This HTML snippet should have no visible impact on a rendered page. Since nearly all web browsers now implement DNS prefetching, the code above results in a DNS query for the name shown and allows us to characterize the recursive name server that the query goes through.

They also mention that you can alternatively modify the HEAD element of your page to include this one line of code:

<link rel=”prefetch” href=”http://prefetch.validatorsearch.verisignlabs.com” />

I’ve chosen this latter approach here at Deploy360 and as a result visitors to our site will be helping with this important research.  If we can get more sites adding this code, Verisign Labs can get that many more data points feeding in and helping them characterize the level of DNSSEC validating resolvers out there.

Here at Deploy360, we are in favor of research like this because we’d like to get a baseline now and then see trends over time.  Encouraging the wider deployment of DNSSEC-validating resolvers by ISPs and other network operators is one of the key activities we are planning to work on over the next 12 months – and this research will help us and many others understand how successful we are collectively in encouraging that deployment.

Can you please help you by adding a line of code to your site?  (Thanks!)

P.S. For those curious to learn more about “DNS prefetching” (also called “pre-resolving” by some) and how this research works, here are some articles you may find of interest: