Dark Reading is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them.Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.


Guest Blog // Selected Security Content Provided By Sophos
What's This?
01:00 PM
Dark Reading
Dark Reading
Security Insights

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.

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
Newest First  |  Oldest First  |  Threaded View
COVID-19: Latest Security News & Commentary
Dark Reading Staff 7/14/2020
Omdia Research Launches Page on Dark Reading
Tim Wilson, Editor in Chief, Dark Reading 7/9/2020
Why Cybersecurity's Silence Matters to Black Lives
Tiffany Ricks, CEO, HacWare,  7/8/2020
Register for Dark Reading Newsletters
White Papers
Current Issue
Special Report: Computing's New Normal, a Dark Reading Perspective
This special report examines how IT security organizations have adapted to the "new normal" of computing and what the long-term effects will be. Read it and get a unique set of perspectives on issues ranging from new threats & vulnerabilities as a result of remote working to how enterprise security strategy will be affected long term.
Flash Poll
The Threat from the Internetand What Your Organization Can Do About It
The Threat from the Internetand What Your Organization Can Do About It
This report describes some of the latest attacks and threats emanating from the Internet, as well as advice and tips on how your organization can mitigate those threats before they affect your business. Download it today!
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
PUBLISHED: 2020-07-15
Advantech iView, versions 5.6 and prior, has an improper access control vulnerability. Successful exploitation of this vulnerability may allow an attacker to obtain all user accounts credentials.
PUBLISHED: 2020-07-15
Advantech iView, versions 5.6 and prior, has an improper authentication for critical function (CWE-306) issue. Successful exploitation of this vulnerability may allow an attacker to obtain the information of the user table, including the administrator credentials in plain text. An attacker may also ...
PUBLISHED: 2020-07-15
Advantech iView, versions 5.6 and prior, has an improper input validation vulnerability. Successful exploitation of this vulnerability could allow an attacker to remotely execute arbitrary code.
PUBLISHED: 2020-07-15
Advantech iView, versions 5.6 and prior, contains multiple SQL injection vulnerabilities that are vulnerable to the use of an attacker-controlled string in the construction of SQL queries. An attacker could extract user credentials, read or modify information, and remotely execute code.
PUBLISHED: 2020-07-15
Advantech iView, versions 5.6 and prior, has an improper neutralization of special elements used in a command (“command injection�) vulnerability. Successful exploitation of this vulnerability may allow an attacker to send a HTTP GET or POST request that create...