Category: DNSSEC

Microsoft Security TechCenter: DNSSEC and DNS Amplification Attacks

Security Tech Center LogoWhat are the security risks related to using DNSSEC with regard to “DNS amplification attacks”? In a recent article at Microsoft’s Security Tech Center, Greg Lindsay dives into exactly that question.

First, though, he explains how a DNS amplification attack is a form of a Distributed Denial of Service (DDoS) attack that uses DNS queries combined with source address spoofing to send a large volume of traffic at a target system. He provides some examples of exactly how such an attack could be carried out.

Nicely, we get to see some examples of how DNSSEC will be implemented in the forthcoming Windows 8, both at the command line and in the GUI.  (I will be curious as Windows 8 rolls out to learn more about the “DNSSEC zone signing wizard” apparently available in the DNS Manager.)

He ends with a note that:

Signing a DNS zone and adding DNSSEC records to a DNS response increases the total size of a response, but does not increase the risk for DNS amplification past the existing limit placed on the server for UDP response size. 

Since the TCP conversation cannot be easily spoofed, these additional records do not inherently increase the severity of DNS amplification attacks.

and concludes with useful advice about how to help prevent DNSSEC amplification attacks.

I found it a very useful article regardless of whether you use Microsoft DNS servers or not.  Good to get this kind of information out there so that IT security teams can understand how to address and mitigate potential risks.

 

When Will We Hit 100 DNSSEC-Signed TLDs?

In looking at ICANN’s TLD DNSSEC Report for today, I noticed that the number of top-level domains (TLDs) signed with DNSSEC is creeping very close to 100:

  • 313 TLDs in the root zone in total
  • 94 TLDs are signed;
  • 86 TLDs have trust anchors published as DS records in the root zone

Who will be the next 6 TLDs to be signed?

That will put us that much closer to one-third (104) signed… and then of course the next step is getting all the DS records in the root zone.

Excellent to see the growth in signed TLDs.  Looking forward to seeing the percentage growing even higher!

Want to understand DNSSEC? Watch this excellent 1-hour elearning video.

Want to understand DNSSEC and how it can help secure the Internet?  The folks at SIDN, the registry behind the .NL country code top-level domain (ccTLD), have put together a truly excellent 1-hour video e-learning session available in either English or Dutch at:

http://www.dnsseccourse.nl/

The course touches on the basics of DNS then explains the role of DNSSEC, how it works and the steps that need to be done.  It also has some solid points about things you need to think about and also business impacts of DNSSEC.  Perhaps most usefully, the course includes a number of animations that really illustrate how DNSSEC works, as well as a few examples of what DNS zone files really look like with DNSSEC involved.

The video’s target audience is really for domain name registrars who would enable DNSSEC for their customers (domain name registrants). However, SIDN created the video in such a way that it’s quite a useful introduction to DNSSEC for anyone interested in the topic.

I found the elearning user interface quite nice in that you could skip around between sections, return to past sections, stop/start the sections and skip ahead as well.  The “Notes” tab also includes the text of what was said in each section, which I could see being quite valuable particularly for those for whom English or Dutch is not a native language.  It was also nice to have the video introductions from Bert Hubert interspersed with the slides and animations.

DNSSEC course

My one issue with the user interface was that when a section was done you have to press the “Next” button to move on to the next section.  Given that there are 74 sections, I soon found myself wishing there was an “auto-advance” that would just keep on playing the video.  A minor quibble, perhaps. Otherwise I was quite pleased.

On a technical level, my only issue was that the course oversimplified one aspect of the DNSSEC infrastructure. It states that a copy of the public key for your zone (the DNSKEY record) is stored in the parent zone as the DS record.

In fact, the DS record is a digest of the DNSKEY, as defined in section 5 of RFC 4034 and shown as an example in section 5.4.

I realize that the video couldn’t go into every detail and had to simplify some aspects in order to keep it within the presentation timeframe.  I also realize that the idea is quite similar. However, if someone left this video thinking that the DS record in the parent zone was simply the DNSKEY record from the child zone, they would be extremely surprised when the do a “dig” on the records for a DNSSEC-signed domain and see that they are quite different.

Regardless, I still see this as an outstanding introduction to DNSSEC and commend the folks at SIDN for creating this elearning video.  If you want a quick way to understand DNSSEC, definitely do check it out!

 

Excellent Interactive Map of DNSSEC Support by Swedish Municipalities

This morning we learned via a tweet about this very cool interactive map of the status of DNSSEC support by Swedish municipalities. Sweden has by far been one of the leaders world-wide in implementing DNSSEC and the fact that such a map like this can even be constructed is a great testimony to all the excellent work happening there.

Kudos, too, to whomever created this map and site. Other than seeing it was funded by the great folks at .SE it’s not clear from the site who created it.  We love seeing visualizations like this and look forward to seeing more such maps for other parts of the world.

Jitsi Is The First VoIP Softphone To Support DNSSEC

JitsiWith it’s 1.0 release last week, the Jitsi soft phone became the first VoIP client I know of to support DNSSEC. Jitsi, formerly known as the “SIP Communicator”, is available for Windows, Mac OS X or Linux from:

jitsi.org

Jitsi has a great range of features including support for voice and video calls, chat/IM, desktop sharing, conference calls, wideband audio and much more. It works with the SIP (Session Initiation Protocol) and XMPP (Jabber) protocols and connects to common services like GoogleTalk, AIM, Yahoo!Messenger, Facebook chat, etc.  It’s also free and the source code is all available.

Jitsi has supported SIP and XMPP over IPv6 for quite some time now, but with this new release adds support of DNSSEC courtesy, I learned, of some funding from the NLnet Foundation and the University of Applied Sciences and Arts Northwestern Switzerland (FHNW). The DNSSEC code itself was implemented by Ingo Bauersachs from this university.

Essentially what Jitsi now does if you enable DNSSEC is to validate the signing of the SRV records in DNS that provide the address information for the remote end of the SIP or XMPP connection.

To step back and explain a bit further, if Alice wants to call Bob (to be cliche), and she knows his SIP address is “sip:bob@example.com”, her SIP client, IP-PBX or other SIP server (depending upon configuration) is going to perform a DNS lookup on “example.com” to retrieve the relevant SRV records. These records will provide the IP address(es) of the SIP server on Bob’s side. Alice’s SIP software will then connect to those IP addresses to send the appropriate SIP INVITE to start a conversation with Bob.

But how does Alice’s software know that the SRV records retrieved from DNS are correct? How can it know that they were not tampered with?

What if she is trying to call her bank and an attacker is redirecting her to another SIP server where there is a similar call center or IVR? (Okay, leaving aside the fact that at this moment you may not be able to make SIP connections to many banks… but that is changing slowly.)

Enter DNSSEC.

If the “example.com” domain is signed via DNSSEC, including all the SRV records, then the VoIP client can validate that the SRV records are in fact correct and the connection can be made knowing that it is to the intended recipient based on the SIP address.

From a configuration point of view, there has been one more screen added to Jitsi’s preferences:

Jitsi dnssec

At this moment there is no documentation on the Jitsi site about the DNSSEC features (they are working on it… and open to any offers of assistance! ;-) , but I asked Ingo Bauersachs about the configuration of the resolver. His reply was this:

Libunbound, the library Jitsi is using, is validating the DNSSEC chain, but it’s not a full resolver. Queries for DNSKEY, DS, etc. are sent to the OS’s resolver, or if configured, to the “Custom name servers”.

The option to override the OS’s default resolver is there because during development, the only servers supporting all relevant record types were from DNS-OARC and Verisign.

The choice not to use libunbound as a fully recursive resolver was performance and that it’s for one simply not the job of an application to perform recursive DNS queries.

In my own case, I’m running a local instance of DNSSEC-Trigger and that is my operating systems default resolver. I’ll be able to perform the DNSSEC resolution without any issues. Ingo also indicated that the table at the bottom of the Preferences panel will fill up with domains as you start to connect to sites (any sites – DNSSEC-signed or not). You can then specify what the DNSSEC-related behavior is for individual domains.

That’s how this all works, of course, when you have both publicly accessible SIP servers with SRV records – and DNSSEC signatures on those records. There may not be a whole lot of those sites out there quite yet, but having apps like Jitsi available will only help.

If you have a SIP- or XMPP-based VoIP or IM system (or “Unified Communications” system to use the appropriate marketing buzzwords) where you can sign your domain with DNSSEC, definitely check out Jitsi and see how it works. And as you have it working, I’d certainly love to hear from you and perhaps feature some examples in future blog posts.

The Jitsi team is also very interested in feedback and indicated that sending messages to the “dev” mailing list (and joining that list if you want) would be the best way to proceed.

I’m also personally interested in trying this out in a test environment… if you’ve got a SIP server with a domain that is DNSSEC-signed, please drop me a note as I’d like to try calling you. :-)

Kudos to the NLnet Foundation for funding this work and to Ingo Bauersachs and the Jitsi team for implementing it all. I’m looking forward to seeing where this goes!

P.S. Wikipedia has a decent page on SRV records if you want to know more about these record types.

Have You Signed Your Domain With DNSSEC Yet? (Here are instructions…)

Have you signed your domain name with DNSSEC yet?  If not, how about doing that today?  Or as a weekend project?

This one little step can go a long way in both helping make your own Internet presence that much more secure and also in helping move the overall DNSSEC effort forward industry-wide.

To help you out, we’ve put together a few “how to sign your domain name using DNSSEC” tutorials for some of the leading registrars supporting DNSSEC:

http://www.internetsociety.org/deploy360/resources/dnssec-registrars/

If your registrar is not listed on that page, you can also check ICANN’s list of registrars supporting DNSSEC to see if your registrar is listed.

If your registrar is not listed on either site, you may want to look at your registrar’s website to see if they have any mention of DNSSEC. Note that I’ve found a couple of registrars out there who mention “Premium DNS” and on closer inspection turn out to essentially be GoDaddy resellers – in which case the GoDaddy DNSSEC tutorial applies. (And if you do find that they support DNSSEC, could you please send us a note so that we can add them to our list? Thanks!)

And if you still can’t find any information, why not drop an email to your registrar’s support address asking when they will have DNSSEC support?  Either that… or consider moving your domain to a registrar that does support DNSSEC already!  (Yes, I know, moving registrars can be a headache… )

If we can each take a moment to go out and sign some more domains (or to encourage more registrars to support DNSSEC), we’ll move that much closer to having a more secure Internet!

FCC Publishes DNSSEC Recommendations for ISPs

FCC CSRIC logoAre you are network operator or Internet service provider (ISP) seeking to understand what you need to do to implement DNSSEC within your network? Are you looking for guidance to help you understand how to proceed?

If so, the U.S. Federal Communications Commission (FCC) just published a set of “DNSSEC Implementation Practices for ISPs” through one of the working groups of its Communications Security, Reliability and Interoperability Council (CSRIC).  The 29-page PDF is available at:

http://transition.fcc.gov/bureaus/pshs/advisory/csric3/CSRIC-III-WG5-Final-Report.pdf

The document provides:

  • A brief overview of DNS and DNSSEC
  • A view of the current state of DNSSEC deployment
  • How Internet Service Providers (ISPs) can use DNSSEC
  • An analysis of the key drivers and challenges for implementing DNSSEC
  • Specific best practice recommendations to ISPs for deploying DNSSEC

The key recommendations of the working group include:

  1. ISPs implement their DNS recursive nameservers so that they are at a minimum DNSSEC-aware, as soon as possible.
  2. Key industry segments, such as banking, credit cards, e-commerce, healthcare and other businesses, sign their respective domain names. The FCC ask industry-leading companies in key sectors commit to doing so, in order to create competitive pressure for others to follow. These industries may be prioritized based on the prevalence of threats to each one, which would mean focusing on financially related sites first, followed by other sites that hold private user data.
  3. Software developers such as web-browser developers study how and when to incorporate DNSSEC validation functions into their software. For example, a browser developer might create a visual indicator for whether or not DNSSEC is in use, or perhaps only a visual warning if DNSSEC validation fails.

We’re very pleased to see these recommendations as they are very much in line with what we’ve been promoting here on the site about DNSSEC – and are very much in line with our recent analysis of DNSSEC challenges and opportunities.

If you are an ISP or network operator, these recommendations from the FCC are definitely ones to consider and act on.  Kudos to the CSRIC Working Group and the FCC for publishing this document.

Thanks to the DNSSEC Deployment Initiative for pointing out that these recommendations were published.

FCC DNSSEC Implementation Guidlines for ISPs

In March 2012, the United States Federal Communications Commission (FCC) published a set of “DNSSEC Implementation Practices for ISPs” through one of the working groups of the FCC’s Communications Security, Reliability and Interoperability Council (CSRIC).  The full report can be downloaded in PDF at:

http://transition.fcc.gov/bureaus/pshs/advisory/csric3/CSRIC-III-WG5-Final-Report.pdf

The 29-page document provides the following:

  • A brief overview of DNS and DNSSEC
  • A view of the current state of DNSSEC deployment
  • How Internet Service Providers (ISPs) can use DNSSEC
  • An analysis of the key drivers and challenges for implementing DNSSEC
  • Specific best practice recommendations to ISPs for deploying DNSSEC

If you are a network operator or Internet service provider seeking to understand the steps you need to undertake to support DNSSEC, this document is highly recommended.

Ram Mohan on DNSSEC and ICANN’s Costa Rica Meeting

Given that I was one of the presenters at the recent DNSSEC workshop at ICANN 43 in Costa Rica, I was very pleased to see the Circle ID article on Friday, “Slowly Cracking the DNSSEC Code at ICANN 43” from Ram Mohan at Afilias. As he notes:

The half-day session held at ICANN 43 in Costa Rica last month was particularly interesting. What became clear is that the industry is quickly moving into the end-user adoption phase of global DNSSEC deployment.

That was certainly clear to me as well.  As Ram Mohan notes in his article, many of the participants in the event brought real case studies of where DNSSEC is being actually deployed and used in real situations.   It was a great event and I’m looking forward to pointing to more of the case studies and other information as they become available.

CZ.NIC Labs Launchs DNSSEC Validator Extension for Internet Explorer

C Z dot NIC Labs logoThe news out today is that the great folks at CZ.NIC Labs have launched a DNSSEC validation extension for Internet Explorer similar to the Google Chrome DNSSEC extension and Mozilla Firefox DNSSEC Add-on they have previously released.  Details can be found at:

https://labs.nic.cz/page/1031/rozsireni-dnssec-validator-pro-internet-explorer/

(NOTE: To view the page in English you need to click on the “English” link up near the top center of the page.)

The CZ.NIC Labs team labels this a “technical preview” with a version number of “0.1″.  Judging from the warnings they provide the extension is still very early in the development cycle.

Still, for those interested in experimenting with a way to view the DNSSEC validation status of sites you are visiting, this new extension and toolbar provide a way to see this information directly inside of IE.