Perimeter
Guest Blog // Selected Security Content Provided By Sophos
What's This?
2/4/2013
01:00 PM
Dark Reading
Dark Reading
Security Insights
Connect Directly
RSS
E-Mail
50%
50%

Canada Joins The DNSSEC Party

Implementing DNSSEC will take some effort, but it plays an important role in securing the future Internet

So what is the big deal about Canada signing its .ca ccTLD?

To Canada, it is a big deal to configure its DNS (domain name system) server to respond to DNSSEC lookups because it is the 99th country to do so. Ninety-nine is also the hockey jersey number of the immortal Wayne Gretzky. Not to mention, DNSSEC signing the .ca ccTLD adds another layer of protection from cybercriminals looking to steal data or send spam. Clearly there is a lot to be excited about and a mysterious numerological connection.

Canadian Internet Registration Authority (CIRA) manages the .ca country-code top-level domain (ccTLD) for all of Canada. On Jan. 25, @rootchanges tweeted
:

CA delegation signer keytag 58156 algorithm RSA-SHA256 digest SHA-256 added in root zone serial 2013012500

RootChanges is an automated awk script running in a cronjob that is seeking out modifications made to root domains , and then tweets its findings. As an alternative, you can do this yourself manually by checking the approximate 316 registered TLDs in the root zone currently available every hour. If that is your choice, then I don't believe you would have much free time to do anything else.

For anyone with difficulty understand the jargon used in the tweet above, I expanded it out bit, so I hope that helps. A change was detected on the .ca top-level domain with the delegation signer record (ds-rdata) using key tag 58156. The key algorithm was RSA-SHA256 with a key digest hash type of SHA-256 and added to the root zone SOA serial 2013012500.

You can see this information in a much more raw format by running a whois on the CA domain. The section relevant to DNSSEC will look like this:

ds-rdata: 58156 8 2 04a3dbaa4c6b1fcfe998dcbc633a044148fb468ceb3c41182697942197e77974

What does this mean and why should you care? Read on.

Please note: Before you begin, this article leaves out a lot of details and was written in a simplified method to reach a broader audience. For anyone curious to take a deeper dive, there are copious amounts of information on the subject of DNSSEC referenced throughout this article.

What Is DNSSEC?
DNS enables people to remember how to access a computer over the Internet Protocol (IP) without the complexity of keeping a database of IP addresses handy for their favorite locations. For example, to surf the Dark Reading website, most people will remember to type in www.darkreading.com, not the IP address.

The reality is that there is more that one IP address responding to Web page requests for www.darkreading.com. Having a DNS record(s) pointing to the IP address(es) of the Web server serving up the HTML pages makes the Internet much more user-friendly.

TLDs are the last bit of letters used at the end of a website, such as .com, .org, and .net. Countries also have TLDs, but those are called country-code TLDs (ccTLDs), such as .us (United States), .de (Germany), .cn (China), and .ca (Canada).

The text before the '.com' is called the subdomain (i.e., darkreading). The subdomain is the creative name you can purchase from a registrar for a period of time. Anything else added in front of the subdomain is either another subdomain or a host (i.e. www.). With DNS servers you manage, the hosts have resource records that point to IP addresses you want DNS client resolvers to find.

In simple terms, DNSSEC is one approach to adding security to protect the DNS client resolvers from being giving incorrect IP addresses of evil Web servers (for example). Security is achieved by validating the signature of the DNS data received is accurate, making sure the records actual exist and the data hasn't been modified.

DNS and DNSSEC aren't the sexiest aspects of Internet security, but they are absolutely important.

Why Is DNSSEC important?
When DNS was originally designed, security was not included with the specifications (RFC 882 and RFC 883). Ultimately this enabled attackers to get into the middle of the name resolution process by poisoning the DNS cache with their dirty IP address(es) and hijacking a session. Having hijacked the client's ability to resolve DNS lookups, attackers can do a few nefarious deeds -- for example, direct a victim's Web requests to their malicious websites where they can collect personal information, deliver malware, bypass anti-spam protection, or read third-party email.

As a countermeasure to session hijacking and DNS cache poisoning, the Internet Engineering Task Force (IETF) designed Domain Name System Security Extensions (DNSSEC) to be a set of extensions for DNS client resolvers to be able to verify the signature of DNS data, authenticate denial-of-existence, and maintain data integrity.

The design of DNSSEC includes the implementation of several additional DNS record types that client resolvers will request:

  • DNSKEY: (DNSSEC public key) DNS resource record holding the cryptographic keys used to sign records in a zone file

  • DS: (delegation signer)

  • NSEC: (next secure) proves that no records exist between two different points

  • NSEC3: (next secure ver 3) works like NSEC, but contains hash records of the published names

  • NSEC3PARAM: (NSEC3 parameters) used to calculate and determine which NSEC3-records to include in responses

  • RRSIG: (RRset signature) holds a DNSSEC signature for a record set

DNSSEC does not include encryption, availability, or confidentiality of data.

Ultimately, a global implementation of DNSSEC will result in reducing the attack surface for cybercriminals looking to use DNS a method for man-in-the-middle (MITM) based attacks.

How Can You Participate?
Taking time to understand DNSSEC and the overall benefits for enhanced global Internet security, rather than your organization's direct benefit, is a very good start.

Updating your DNS servers to support DNSSEC record types will give your organization a comfortable feeling that caches of your DNS records are a little safer. Sometimes that is a lot easier said than done, but don't you want to participate in making the Internet safer for everyone?

After having searched for a list of operating systems that support DNSSEC client resolvers, the results varied further and wider to include all possibilities here. My advice is to do a quick search on "how to configure DNSSEC on " -- there will be many results to choose from.

If you are someone who likes to stay on top of the changes happening at the root domain level, then you will enjoy following Root Zone Changes on Twitter.

For folks who are more visually oriented, like myself, you may enjoy this animated GIF from dnssec-deployment.org of DNSSEC in ccTLDs, Past, Present, and Future.

For lovers of wiki columns and rows, this Wikipedia page titled "List of Internet top-level domains" may give you a thrill.

During your implementation of DNSSEC, you will want to test your results prior to letting them loose in the wild. Mice and Men has a page with a list of Web services that will test the DNSEC validation of the local resolver and signed zones.

DNSSEC-deployment maintains a Web page of a whole plethora of tools. They have utilities if you are a zone administrator, troubleshooting on end systems, or are responsible for a successful deployment. Have fun!

Say you are the lucky engineer with the privilege to enable your organization with DNSSEC. You are going to need a step-by-step guide, right? DNSSEC-Tools has a handy document (PDF) that does exactly that. Want to have your PDF and Wiki too? Not a problem. You'll find one of those, too.

I wonder who will be No. 100 to DNSSEC-sign its ccTLD?

I will leave you with a Wayne Gretzky quote: "You miss 100% of the shots you don't take." So take a shot at implementing DNSSEC.

No security, no privacy. Know security, know privacy.

David Schwartzberg is a Senior Security Engineer at Sophos, where he specializes in latest trends in malware, web threats, endpoint and data protection, mobile security, cloud and network security. He is a regular speaker at security conferences and serves as a guest blogger for the award winning Naked Security blog. David talks regularly with technology executives and professionals to help protect their organizations against the latest security threats. Follow him on Twitter @DSchwartzberg

Comment  | 
Print  | 
More Insights
Register for Dark Reading Newsletters
Partner Perspectives
What's This?
In a digital world inundated with advanced security threats, Intel Security seeks to transform how we live and work to keep our information secure. Through hardware and software development, Intel Security delivers robust solutions that integrate security into every layer of every digital device. In combining the security expertise of McAfee with the innovation, performance, and trust of Intel, this vision becomes a reality.

As we rely on technology to enhance our everyday and business life, we must too consider the security of the intellectual property and confidential data that is housed on these devices. As we increase the number of devices we use, we increase the number of gateways and opportunity for security threats. Intel Security takes the “security connected” approach to ensure that every device is secure, and that all security solutions are seamlessly integrated.
Featured Writers
White Papers
Cartoon
Current Issue
Dark Reading's October Tech Digest
Fast data analysis can stymie attacks and strengthen enterprise security. Does your team have the data smarts?
Flash Poll
Title Partner’s Role in Perimeter Security
Title Partner’s Role in Perimeter Security
Considering how prevalent third-party attacks are, we need to ask hard questions about how partners and suppliers are safeguarding systems and data.
Video
Slideshows
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2013-4594
Published: 2014-10-25
The Payment for Webform module 7.x-1.x before 7.x-1.5 for Drupal does not restrict access by anonymous users, which allows remote anonymous users to use the payment of other anonymous users when submitting a form that requires payment.

CVE-2014-0476
Published: 2014-10-25
The slapper function in chkrootkit before 0.50 does not properly quote file paths, which allows local users to execute arbitrary code via a Trojan horse executable. NOTE: this is only a vulnerability when /tmp is not mounted with the noexec option.

CVE-2014-1927
Published: 2014-10-25
The shell_quote function in python-gnupg 0.3.5 does not properly quote strings, which allows context-dependent attackers to execute arbitrary code via shell metacharacters in unspecified vectors, as demonstrated using "$(" command-substitution sequences, a different vulnerability than CVE-2014-1928....

CVE-2014-1928
Published: 2014-10-25
The shell_quote function in python-gnupg 0.3.5 does not properly escape characters, which allows context-dependent attackers to execute arbitrary code via shell metacharacters in unspecified vectors, as demonstrated using "\" (backslash) characters to form multi-command sequences, a different vulner...

CVE-2014-1929
Published: 2014-10-25
python-gnupg 0.3.5 and 0.3.6 allows context-dependent attackers to have an unspecified impact via vectors related to "option injection through positional arguments." NOTE: this vulnerability exists because of an incomplete fix for CVE-2013-7323.

Best of the Web
Dark Reading Radio
Archived Dark Reading Radio
Follow Dark Reading editors into the field as they talk with noted experts from the security world.