Just a guy in Vermont trying to connect all the dots...
Dan York
Author's posts
May 02
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:
- Fedora 21 (coming in late 2014)
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:
- SURFnet guide to enabling DNSSEC validation for BIND, Unbound and Microsoft Windows
- Microsoft Guide to DNSSEC on Windows Server 2012
Applications
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.
Apr 30
TDYR #149 – Getting Vaccinations For Upcoming Tavel To Djibouti
TDYR #149 - Getting Vaccinations For Upcoming Tavel To Djibouti by Dan York
Apr 30
Summary Report Now Posted of W3C/IAB “Strengthening The Internet (STRINT)” Workshop (Featured Blog)
Given that I've written here about the original call for papers for the W3C/IAB "Strengthening The Internet Against Pervasive Monitoring (STRINT)" Workshop and then subsequently that the STRINT submitted papers were publicly available, I feel compelled to close the loop and note that a report about the STRINT workshop has been publicly published as an Internet-draft. More...
Apr 30
Join The VUC Podcast Live On Friday, May 2, To Talk TLS/SSL And The Need For “More Crypto”
Why do we need “more crypto” everywhere? How can we get more people using TLS (SSL) in applications and services? If you are interested in this topic and want to discuss it with others, please do join the “VoIP Users Conference (VUC)” conference call this Friday, May 2, 2014, at 12 noon US Eastern time. The main guests will be Olle Johansson and Kristian Kielhofner and I will also be joining in to participate (as will typically a good number of people). Olle just recently participated in the “MeraCrypto” day-long session sponsored in part by the Internet Society Chapter in Sweden and has also been maintaining a set of slides about why we need “MoreCrypto”.
With the recent Heartbleed vulnerability in the news (here was my view on it) there is obviously a great amount of interest in the topic of getting more TLS / SSL out there. I’ll be on the call in part because we launched our “TLS for Applications” area out of our belief that we need more crypto out there being used. It should be good conversation and I’m very much looking forward to it!
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.
If you can’t listen live, the show will be recorded and you can listen to it later. If you can join live, please do… it should be great conversation on a very important topic!
Apr 29
New DNSSEC Deployment Maps for April 28, 2014, Now Available
I’ve made a couple of updates recently to our DNSSEC Deployment Maps section of the site.
First, I updated the page to display the most recent deployment maps from yesterday, April 28, 2014. The big change from previous maps is that Australia now appears in blue as the folks there have signed the .AU top-level domain on their production servers, but the DS is not yet in the root of DNS (that is scheduled for August 2014 right now).
Second, I changed the settings on the archive of the ‘dnssec-maps’ mailing list to be publicly accessible. This means that anyone can simply go to the archive to obtain the most recent set of DNSSEC deployment maps and also the comma-separated value (CSV) files that track all the domains, including generic TLDs and the “newgTLDs”. The deployment maps are generated automatically every Monday morning so with the list archive publicly available you can always get to the most recent version of the maps.
Ultimately I’d like to figure out how to have the maps automatically update on a page on our site by way of some type of WordPress plugin or other mechanism, but for the moment I’m still manually updating the images on the DNSSEC deployment maps page whenever there have been major changes or after a longer period of time has passed.
If you’d like to receive these maps automatically every Monday, you can simply subscribe to the ‘dnssec-maps’ mailing list and you’ll receive an email with the maps and CSV files each week. If you have ideas for enhancements, we’re also tracking those over on Github – feel free to raise “issues” with any ideas or feedback you have.
Apr 28
TDYR #0148 – What Do You Do On Your First Work Day After Vacation?
TDYR #0148 - What Do You Do On Your First Work Day After Vacation? by Dan York
Apr 28
FIR #753 – 4/28/14 – For Immediate Release
Interview coming with DomainSkate's Howard Greenstein and David Mitnick; Quick News: SEC guidelines for social networks during proxy fights, 3D printers print 10 houses in 24 hours, Two NFL teams post 2014 schedules on SnapChat, the LinkedIn crowd decoded; Ragan promo; News That Fits: the rise of the mobile addict, Dan York's Tech Report, speculation surges on the future of Google+, Media Monitoring Minute from CustomScoop, listener comments, branded content with good-enough writing will sink native advertising, the past week on the FIR Podcast Network, Igloo Software promo, using post-action analytics to calculate ROI; music from Among Criminals; and more.
Apr 24
TDYR #147 – It Is Hard To Podcast When You Cannot Speak
TDYR #147 - It Is Hard To Podcast When You Cannot Speak by Dan York
Apr 23
Wired: It’s Time To Encrypt The Entire Internet
Is it time to “dump the plain text Internet” and encrypt everything everywhere? That’s the main thrust of an article by Klint Finley in Wired last week: “It’s Time to Encrypt the Entire Internet“. As he writes:
The Heartbleed bug crushed our faith in the secure web, but a world without the encryption software that Heartbleed exploited would be even worse. In fact, it’s time for the web to take a good hard look at a new idea: encryption everywhere.
Most major websites use either the SSL or TLS protocol to protect your password or credit card information as it travels between your browser and their servers. Whenever you see that a site is using HTTPS, as opposed to HTTP, you know that SSL/TLS is being used. But only a few sites — like Facebook and Gmail — actually use HTTPS to protect all of their traffic as opposed to just passwords and payment details.
He goes on to discuss viewpoints from Google’s Matt Cutts and and a number of other security professionals. As he notes at the end, there are costs, both in terms of financial costs for TLS/SSL certificates and also in terms of performance, but the greater security benefits are ones that we all need.
We definitely agree with the need to encrypt connections across the Internet. That’s why we’ve opened up the “TLS For Applications” area here on Deploy360 and why we are seeking to find or write a number of documents to help developers more quickly integrate TLS into their apps.
What do you think? Should connections across the Internet be encrypted?
Apr 22
CloudFlare Enabling IPv6 For All Customers
Buried in a post last month about Martin Levy joining CloudFlare was this gem:
CloudFlare is enabling IPv6 by default for ALL of their customers!
If you are not aware of CloudFlare, the are a “content delivery network” (or “content distribution network”… either way it is “CDN”) that takes your website and makes it available through their large network. A CDN can help you accelerate the speed at which users access your content. They also can help with performance issues, protection from DDoS attacks and many other website concerns.
CDNs also, as I documented in a video a while back, can be an easy path to making your web content available over IPv6. In my own personal case, I have a couple of sites on a hosting provider that has only IPv4. Given that I don’t have the time to move them to a hosting provider that provides IPv6, I’ve set both sites up to go through a CDN that automagically makes them available over IPv6. We maintain a list of CDN providers we are aware of who support IPv6.
But back to CloudFlare… a few years ago they implemented a setting for “Automatic IPv6″. All you had to do was toggle that from “Off” to “On” and… ta da… your content would be available over IPv6. Now, as Martin Levy writes on CloudFlare’s blog:
Many customers have flipped the switch to enable IPv6. That’s good; but it’s time to make the default setting “IPv6 on.” In this day and age this is a very safe thing to do. Over the next few weeks CloudFlare is going to make the default for new customer be “IPv6 on.” No need to flip that switch to be enabled for the whole Internet (that’s IPv4 and IPv6).
In the upcoming weeks CloudFlare will enable IPv6 for existing customers in a staggered release. CloudFlare takes the delivery of each and every bit very serious and you can be assured that every person at the company is involved in making this operation is successful. Yes there will be the option to turn off IPv6; but we strongly believe that at this point there’s little need for that option to be exercised.
So IPv6 will be on by default for all new customers – and all old customers will be migrated to having that setting enabled.
The results are already being seen in some of the available IPv6 statistics sites. Eric Vyncke noticed the uptick in his chart of the % of top web sites available over IPv6 and in a posting to the IPv6 group on Facebook attributed that growth to CloudFlare:
Regardless of whether CloudFlare drove that specific growth, the fact is that have a CDN provider enable IPv6 by default for all customers is a great step forward! Now we just need all the other CDNs to do the same thing and we’ll go a long way toward having a significant amount of the Web’s content available over IPv6.
How about you? Have you enabled you web content to be available over IPv6 yet? If not, how can we help you? Please do check out our IPv6 resources and let us know what other help you need.
