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:

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