May 2, 2014 archive

Reminder – Live Call In Two Hours About TLS / SSL And The Need For More Crypto Everywhere

VUC logoReminder – in two hours you can join a live discussion we mentioned earlier this week about the need for more TLS / SSL everywhere and what we can do as a technical community to make that happen.  As I noted earlier the main guests will be Olle Johansson and Kristian Kielhofner with others joining in as well.  Host Randy Resnick usually creates an enjoyable and informative session where much can be learned.

To join the call, you can either connect in to the Google+ Hangout at 12:00 noon US Eastern – or alternatively call in via the SIP, Skype or regular old phone numbers listed on the top of the VUC page for the episode. There is also an IRC backchannel where text chat occurs during the episodes.  The session will be recorded if you cannot attend live.

For us, we’re interested in discussions like this one today because we want to build out our TLS for Applications area to have the best resources possible to help developers add TLS into their applications and in so doing make the Internet stronger and more secure for us all. (And on that note, if you would be interested in helping us create the info on our content roadmap for TLS – or know where we can find existing documents that fulfill those items – please contact us!)

Fedora 21 To Have DNSSEC Validation Enabled By Default

Fedora logoBy way of a recent tweet from Red Hat’s Paul Wouters we learned the great news that the next release (21) of the Fedora operating system will include a DNSSEC-validating DNS resolver enabled by default.  According the Fedora 21 release schedule, if all goes according to plan Fedora 21 should be generally available in October 2014.  This will mark the first of the major Linux distributions that I am aware of that will offer the added security of DNSSEC validation by default.  With Linux, you can of course always add a DNSSEC-validating DNS name server such as DNSSEC-Trigger, Unbound, dnsmasq or another DNSSEC-validating DNS server, but this move by the Fedora project will have the validation occurring by default.

From the Fedora 21 Proposed System Wide Change message:

There are growing instances of discussions and debates about the need for a  trusted DNSSEC validating local resolver running on There are multiple reasons for having such a resolver, importantly security & usability. Security & protection of user’s privacy becomes paramount with the backdrop of the increasingly snooping governments and service providers world wide.

People use Fedora on portable/mobile devices which are connected to diverse networks as and when required. The automatic DNS configurations provided by these networks are never trustworthy for DNSSEC validation. As currently there is no way to establish such trust.

Apart from trust, these name servers are often known to be flaky and unreliable. Which only adds to the overall bad and at times even frustrating user experience. In such a situation, having a trusted local DNS resolver not only makes sense but is in fact badly needed. It has become a need of the hour. 

Going forward, as DNSSEC and IPv6 networks become more and more ubiquitous, having a trusted local DNS resolver will not only be imperative but be unavoidable. Because it will perform the most important operation of establishing trust between two parties.

All DNS literature strongly recommends it. And amongst all discussions and debates about issues involved in establishing such trust, it is unanimously agreed upon and accepted that having a trusted local DNS resolver is the best solution possible. It’ll simplify and facilitate lot of other design decisions and application development in future.

This is great news for those of us who want to see the security of the Internet strengthened through DNSSEC – and definitely in keeping with part of the plan for where we need to see DNSSEC validation.

Kudos to the team at Fedora who are making this happen and we look forward to seeing it come out in Fedora 21 later this year!

Plan – Where We Need To Get DNSSEC Validation Happening

For DNSSEC to succeed, we need to get DNSSEC validation happening within DNS resolvers at many different levels within the Internet ecosystem.  Ideally, the DNSSEC validation will occur as close as possible to the end user (either a person or a device) so that the attack surface where an attacker could inject bogus DNS packets is minimized.  For instance, if the DNSSEC validation occurs within an application on the end device, there is very little an attacker can do to inject bogus DNS packets.  On the other hand, if the DNSSEC validation occurs out at a public DNS server somewhere out on the Internet, the attacker can inject packets anywhere between that public DNS server and the end device.  The reality is that we would like to see DNSSEC validation happening at many different levels.

This page exists to track the progress of where we are with getting DNSSEC validation happening across the Internet.  It is organized from the farthest point away from the end device down to the closest.  

[At the moment, this page is a work-in-progress as we are still updating it with the current status of information (and feedback is welcome). ]

Public DNS Services

While the attack surface is quite large, it is still useful to have DNSSEC validation occurring in public DNS services available to all across the open Internet.  The list of services known to perform DNSSEC validation by default includes:

Internet Service Providers / Network Operators

Internet Service Providers (ISPs) and other network operators are an excellent  location for DNSSEC validation to occur as the ISPs DNS servers are typically provided to all customers as the “default” DNS resolvers for the customers to use.  Attacks are still possible if an attacker can get onto the ISPs network but the area of the attack is significantly less than the entire Internet.  Major ISPs known to support DNSSEC by default include:

  • Comcast (North America)
  • (list of ISPs in Sweden, Czech Republic, Netherlands, Brazil)

If you are an ISP or network operator and want to support DNSSEC validation, please see our page about DNSSEC for network operators.

Enterprise Networks

Enterprise networks are a critical place to perform DNSSEC validation as they can do so on behalf of a secured corporate network.

Suggestions for how to deploy DNSSEC validation can be found on our DNSSEC for enterprise customers page.

Home Networks and Consumer Electronic Devices (ex. home routers)

(include a list of consumer devices supporting DNSSEC validation – also include mention of dnsmasq)

Operating Systems

Having DNSSEC validation occur within the operating system of a device is one of the best places for validation to occur.  The following operating systems are known to have DNSSEC validation enabled by default:

It is certainly possible for an individual to configure DNSSEC validation on an individual system using tools such as:

There are also guides out there that explain the easy steps to enable validation on existing systems:


Ideally applications themselves may perform DNSSEC validation.

(include a list of applications known to include DNSSEC validation)

Resources available to developers include:

  • List of developer libraries supporting DNSSEC
  • getDNS API

More information can be found on the DNSSEC for developers page.