Category: DNSSEC

Jun 23

Reminder – “DNSSEC For Everybody” Streamed Live From ICANN 50 Today

ICANN 50 logoJust a quick reminder that, as we mentioned last week, the DNSSEC For Everybody: A Beginner’s Guide session today at ICANN 50 in London will be streamed live via audio or via Adobe Connect (combined audio, slides and video).  This is a fun session where we step back to caveman days to try to explain DNSSEC in the simplest of terms… and also add some skits into the mix as well (yes, DNSSEC engineers doing a skit!).  It is happening from 17:00 to 18:30 British Summer Time (local time in London). More info can be found at:

http://london50.icann.org/en/schedule/mon-dnssec-everybody

The links for remote listening can be found there, as can the slides and handout for download.  The session will be recorded for later viewing if you can’t see it live.

If you want an even deeper dive into DNSSEC, plan to attend (remotely or here at ICANN 50) the DNSSEC Workshop happening most of the day on this coming Wednesday, June 25, where we’ll be starting at 8:30am and covering a wide range of topics related to DNSSEC.

To learn more about DNSSEC, please visit our “Start Here” page to find resources tailored to your type of organization.

Jun 18

3 DNSSEC Sessions At ICANN 50 In London Next Week

ICANN 50 logoNext week (June 23-26, 2014), we’ll be at ICANN 50 in London for the usual excellent DNSSEC sessions, two of which will be streamed live for remote participants.

The three activities are…

DNSSEC For Everybody: A Beginner’s Guide

First up on Monday, June 23, 2014, in the late afternoon from 17:00 – 18:30 BST (London time) will be the DNSSEC For Everybody: A Beginner’s Guide session where we start at the very basic level of why should anyone care about DNSSEC and get into what kind of problem we are trying to solve.  This session includes a skit (seriously!) where we act out DNS and DNSSEC transactions and talk about blue smoke (seriously!).  It’s a good bit of fun and people tell us that it definitely helps them understand DNS and DNSSEC – or maybe they just like watching a bunch of DNS geeks act out in a skit. :-)

You can listen remotely via an audio stream or listen and view the slides via a a virtual meeting room.  Details are on the program page.

DNSSEC Implementers Gathering

Next, on Monday evening from 19:30-21:30 (or later) some of us will join in an “informal gathering of DNSSEC implementers” at a nearby restaurant/bar. This is a time to share experiences, exchange information and just generally interact with other people involved with deploying DNSSEC.  As ICANN’s Julie Hedlund wrote in a note to various email lists:

DNSSEC Implementers are invited to attend an informal gathering to discuss and exchange information on their DNSSEC implementation experiences during the ICANN meeting in London, sponsored by Nominet UK. This is a unique opportunity to meet with and talk to key implementers, such as Nominet UK, CNNIC, JPRS, NZNIC, CIRA, CZNIC, SIDN, and others. We do ask that in order to participate you should come prepared to say a few words about your experiences. This is a peer-to-peer event for implementers.

It’s been a fun time at past events and generated both good conversations and connections for future work activities after the meetings are over.

It should perhaps be obvious but this event will NOT be available for remote participation.  If you will be in London, though, and are interested in interacting with others who are deploying DNSSEC, you are welcome to join us.  As Julie requests, RSVP by close of business on this Thursday, June 19, 2014.

DNSSEC Workshop

The BIG event of the week is the DNSSEC Workshop on Wednesday, June 25, where we meet from 8:30 – 14:45 London time for this detailed session diving into many different aspects of DNSSEC.  I’m on the Program Committee for the workshop and I can tell you that there will be some excellent presentations at this session.  The slides and full agenda will be available soon, but the major areas of discussion will include:

  • Introduction and DNSSEC Deployment Around the World
  • DNSSEC Activities in the European region
  • The Operational Realities of Running DNSSEC
  • DANE and DNSSEC Applications
  • DNSSEC Automation
  • Panel Discussion/Demonstrations on Hardware Security Modules (HSMs)

The workshop continues to attract some of the best technical people involved with DNSSEC and the conversations and discussions that happen there provide outstanding value to those interested in these topics.  If you’re interested in DNSSEC and how it can make the Internet more secure, I highly recommend you tuning in!

You can listen remotely via an audio stream or listen and view the slides via a a virtual meeting room.  Details are on the program page.

Rough Guide To ICANN 50

These DNSSEC events are just a part of all the many activities happening at ICANN 50 that we at the Internet Society are interested in.  To understand all of what is happening at ICANN 50 that lines up with our organization’s priorities, please see the Internet Society Rough Guide to ICANN 50.

Say Hello!

I (Dan York) will be there in London.  Please do say hello – you can find me at any of these events and also around other areas of ICANN. You can also email me at deploy360@isoc.org if you’d like to meet with me.  You can also contact us via Twitter, Facebook or Google+.

Jun 12

CIRA Makes DNSSEC Available For .CA Through Registrars

CIRA logoGreat news today for our friends up north in Canada – they can now sign their .CA domains with DNSSEC! As the Canadian Internet Registration Authority (CIRA) said in a news release yesterday, they are making the Internet safer for all Canadians and noted:

DNSSEC builds a “chain of trust” between users and the websites they wish to visit. It helps counter malicious online activities such as DNS spoofing and man-in-the-middle (MITM) attacks. These fraudulent activities are usually intended to capture personal information, such as bank account logins.

Perhaps even more importantly, DNSSEC will now let people with .CA domains use innovative new protocols like DANE to add a layer of trust to TLS/SSL certificates used for ecommerce and secure access to websites.

CIRA also rolled out an updated FAQ page on DNSSEC (thanks, CIRA, for the link to our work here!) and already has three registrars/DNS hosting providers who will offer DNSSEC-secured .CA domain names.

You may recall that CIRA first made DNSSEC available for .CA domains back in early 2013. However, it was still a manual process to get your signed .CA domain linked in to the global “chain of trust” for DNSSEC.  With this announcement yesterday CIRA has now removed that manual process and made it easy for registrars to upload the necessary DS records. Now they just need more of the .CA registrars to support DNSSEC. (See our page about DNSSEC and registrars for an overview of the process.)

Congrats to the team at CIRA for making this happen!

P.S. If you want to get started with making our domain more secure, visit our “Start Here” pages to learn more about DNSSEC.

Jun 09

Speaking At SIPNOC 2014 On June 10 About TLS For SIP/VoIP/UC

SIPNOC 2014 logoWhat advantages does Transport Layer Security (TLS, what we used to call “SSL”) bring to voice-over-IP (VoIP) that uses the Session Initiation Protocol (SIP)? What is the state of TLS usage within SIP and VoIP? Why isn’t it being used more?

Tomorrow, June 10, 2014, I’ll be speaking at the SIP Network Operators Conference (SIPNOC) 2014 event down in Herndon, Virginia, on the topic of “Is It Time For TLS For SIP?“. I’ll be discussing why we need more TLS usage in SIP-based communication, including what we think of as “VoIP” and also “Unified Communications (UC)”. The abstract for my talk is:

With concerns about large-scale pervasive monitoring on the Internet, many groups are encouraging the increased use of Transport Layer Security (TLS, what we used to call “SSL”). While SIP has had TLS support for quite some time, it is often not used. This session will look at concerns of using TLS with SIP and discuss opportunities for providing higher security for SIP-based communication. The session will also outline some newer innovations such as the DANE protocol that when coupled with DNSSEC can provide a higher level of trust for TLS encryption.

As you can tell, my focus will be around the “TLS for Applications” topic area we have here on Deploy360, as well as some discussion around DANE and what it can bring in terms of increased security.

I’ve spoken at SIPNOC events for the past two years (and before that) but my topic has always included IPv6.  This time I won’t be doing that… but to my delight one of the talks before mine tomorrow will be Carl Klatsky from Comcast providing a case study of their work their voice services to IPv6.  Here is his abstract:

Comcast Voice IPv6 Deployment Lessons Learned. Presented by Carl Klatsky, Comcast.

This presentation will review the successes, challenges, and lessons learned in deploying IPv6 support into Comcast’s IMS based SIP voice network, in support of an upcoming IPv6 technical trial. The presentation will review the overall target architecture covering both access and network side elements, and share the lessons learned with the SIP community.

I’m very much looking forward to hearing what Carl has to say!

There are many other great sessions on the SIPNOC 2014 agenda.  Unfortunately I can only be at the event tomorrow and will be missing out on the great content on Wednesday and Thursday.  You can, of course, expect to find me in any of the security-related sessions on Tuesday!

If any of you reading this are at SIPNOC 2014 tomorrow please do feel free to say hello!

P.S. And before anyone asks in the comments, no, there is not a live stream (or recordings) of the SIPNOC sessions.  They try to keep it an informal atmosphere where information can be shared with the conference sessions without that information being immediately public.

 

May 20

Video: Geoff Huston on Measuring DNSSEC from the User’s Perspective (RIPE 68)

How do you best measure DNS-related metrics from the perspective of an end user?  How many users are actually using DNSSEC validation?  What countries have the highest level of DNSSEC validation?  What role does Google’s Public DNS play in helping with this?

These are all questions that APNIC’s Geoff Huston addressed in his talk “Measuring DNS from the User’s perspective” at the recent RIPE68 meeting in Warsaw.  His slides are now online with some very interesting charts around DNSSEC validation.  I enjoy listening to Geoff and think you’ll find this quite an interesting talk:

geoff-huston-ripe68

And then… can you set up DNSSEC validation on your own network?  That will help you get the benefit of the added security of DNSSEC in your own usage of the Internet.

May 16

Congrats on 25 Years of RIPE Meetings – And We’ll Be Promoting Videos From RIPE68

ripe-25-anniversaryAs the RIPE 68 meeting has drawn to a close in Warsaw, Poland, we would just like to take a moment to join with our CEO and many others in congratulating the RIPE community on their 25th anniversary.  Over these past 25 years the RIPE community has done an amazing amount of work together to create a stronger and better Internet.  On a global level, we are all collectively so much better off because of all the work that has happened within the RIPE community. Do check out their “25 Years of RIPE Timeline” to learn more.

We heard from Chris Grundemann and Jan Žorž that the 25th anniversary celebration on Tuesday evening was a great event – and both of them have raved about what an excellent – and exhausting – week this has been for them. As we wrote about last week, they’ve had an extremely busy week with a great amount of activity on IPv6, DNSSEC, securing BGP and our BCOP and  Operators and the IETF projects. Outside of that, Jan is also a member of the RIPE Program Committee (and was chosen again for that role) and so he was super-busy with helping with general organizational issues.  Our colleague Andrei Robachevsky was also there being very active on issues around routing resiliency and some of the great work happening there.

One of the great things about the RIPE meetings is how quickly they make the videos and presentations available for viewing.  There were some outstanding presentations at this RIPE 68 meeting in Warsaw, and so we’ll be highlighting and promoting some of the sessions that we found most valuable and interesting.  We’ve already started this yesterday with a post about Chris’ presentation about operators and the IETF, but we’ll be doing more of that over the next few weeks.

Congrats again to the RIPE community on their 25th anniversary - and we look forward to seeing all that will happen over the next 25 years!

May 15

Andorra (.AD) Becomes The Latest ccTLD Signed With DNSSEC

Andorra flagYesterday the small Principality of Andorra became the latest country-code top-level domain (ccTLD) to be signed with DNSSEC.  From this point forward any domains registered under .AD will be able to receive the higher level of protection provided by DNSSEC and start being able to use innovative new tools like the DANE protocol… well, to be clear, all of that added protection can come as soon as the registry operating the .AD ccTLD starts accepting DS records from domain name registrars.  What we know today (from sites like this one) is that there is now a DS record for .AD in the root zone of DNS.

I will admit that when I heard the news I wasn’t quite sure where Andorra was other than recalling vaguely it was a very small European state.  The Internet filled in that knowledge gap, of course, with long entries in both Wikipedia and the World Fact Book informing me that Andorra is a “micro-state” sandwiched in between France and Spain whose population is around 85,000 people and whose official language is Catalan.  It seems to have a fascinating political structure as it is a monarchy with two co-princes, one of whom is the President of France and the other is the Spanish/Roman Catholic Bishop of Urgell.  (Yes, I got a bit distracted this morning by my curiosity about Andorra…)

Anyway, congratulations to Andorra for the DNSSEC-signing of .AD.  It will now be added to the database for the weekly DNSSEC Deployment Maps that will come out on Monday. It’s great to see the continued increase in the number of signed TLDs!

May 05

DNSSEC-name-and-shame Spotlights Top Web Sites Without DNSSEC

DNSSEC Name and ShameWhich of the Top Alexa-ranked sites support DNSSEC? How can you quickly find out if a web site supports DNSSEC?  Last week we learned of a fun new site that came out of a recent hackathon at TheNextWeb 2014 conference in Amsterdam that aims to answer these questions.  Called “DNSSEC name and shame!” the site can be found at the simple URL of:

http://dnssec-name-and-shame.com/

At the top you can just enter any domain name and the site will check whether that domain is signed with DNSSEC.  But what is perhaps more interesting is to go a bit further down the page and look at the list of the Alexa Top 25 sites and the list of the event sponsors and “known good” examples.  You can click on any link and it will tell you the result.

I won’t spoil the surprise of what you’ll find when you click those links… but suffice it to say that many of the sites need to read our information for content providers / website owners about how to sign their domains with DNSSEC!  :-)

This DNSSEC-name-and-shame site is a cool example of the type of site / service that can be easily created using some of the new APIs available for DNS and DNSSEC.  Several of the other hackathon projects were definitely cool and we’ll be spotlighting some of them in the weeks ahead.

Congrats to the developers of the site, Joel Purra and Tom Cuddy, too, for winning PayPal’s TNW Hack Battle prize.  Great to see PayPal recognizing this work… and of course paypal.com has been signed with DNSSEC for quite some time now.

Do check the site out… test out domains that you work with… and if they are not signed, why not start today on getting them signed and making the Internet more secure?

P.S. We also enjoyed that Anne-Marie Eklund Löwinder of .SE lent her shaking-fist image to the site.  She’s one of the early pioneers in the world of DNSSEC and it’s fun to see her here!

May 02

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 127.0.0.1:53. 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!

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:

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:

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.