You don’t have to wait to deploy DNSSEC

Overview of DNSSEC

DNSSEC (Domain Name System Security Extensions) is a suite of specifications which implement record signing to ensure the integrity of certain types of transactions. It uses both asymmetric and symmetric cryptography for RR (Resource Record) or zone transfer transactions, respectively. To ensure the authenticity of information received by a resolver, DNSSEC provides the following (Wikipedia.org):

• Origin authentication of DNS data

• Data integrity

• Authenticated denial of existence

These capabilities are added to the existing DNS framework by using a new set of resource record (RR) types, including (nominet.org.uk):

• DNSKEY contains the public key used to sign the data in a secure zone.

• NSEC shows the interval between names in the zone. These are used in DNSSEC for ‘authenticated denial of existence’ of an address.

• RRSIG contains the signature of other RR types in the zone, including DNSKEY and NSEC. For each set of RRs for which the zone is authoritative, there exists a corresponding RRSIG RR. (An RR set, or RRSet, consists of RRs with the same name, type, and class values. All records in an RRSet are signed with the same signature.)

• DS (Designated Signer) RRs contain hashes of the keys of child zones. They’re used to build the chain of trust central to DNSSEC integrity protection.

Figure 1 shows a DNS host RR with its associated signature. When a resolver using DNSSEC receives this information in response to a name resolution query, it uses information contained in the RRSIG RR (contents of Key Tag and Signer’s Name fields) and the sender’s public key to validate the signature.

Figure 1
(nominet.org.uk)

Securing DNS with DNSSEC begins with establishing a chain of trust. Resolvers use ‘anchor keys’ to verify parent domains, beginning with the trust anchor. The trust anchor is the foundation of any chain of trust.

The public key (of the Trust Anchor) is used to verify digital signatures and the associated data. Furthermore, the public key is used to constrain the types of information for which the Trust Anchor is authoritative.

A relying party uses Trust Anchors to determine if a digitally signed object is valid by verifying a digital signature using the trust anchor’s public key, and by enforcing the constraints expressed in the associated data for the trust anchor. (Wikipedia.org)

In an ideal world, the DNS trust anchor for the Internet consists of the root name servers. However, there are issues.

DNSSEC Challenges

There are two categories of challenges when trying to design and implement global DNSSEC security. The first consists of technical and security issues, including (Wikipedia.org & ISC):

• There is a problem with DNSSEC’s reporting of names not present in a signed zone via the NSEC RR. It allows enumeration of zone contents. However, NSEC3 is expected to resolve this issue.

• An effective method of dealing with trust anchor key rollover has not been defined.

• Earlier versions of DNSSEC had issues. This adversely affected confidence in the ability of DNSSEC to improve DNS integrity without introducing other, potentially worse, problems.

• DNSSEC will increase DNS traffic with more requests and larger responses. Domains with high volume traffic should prepare for increased bandwidth needs.

• DNSSEC is more sensitive to time issues than standard DNS. System clocks must be reasonably accurate.

Although these five problems are important, they are minor when compared to the second set of challenges, challenges related to political posturing and mistrust, including (Wikipedia.org):

• The U.S. wants to control the trust anchor keys for the root name servers. Other countries are concerned this would give the U.S. too much control over the Internet. Centralized control by any one country is probably not acceptable to many nations.

• It’s unclear how ICANN would handle delegation of names to TLDs managed by entities with which it has no formal agreement, such as .ca.

• Some governments are encryption averse. Will they try to ban DNSSEC-backed encryption key distribution?

Some security and Internet professionals are using these challenges as a reason to not implement DNSSEC. The assumption is that it can’t be used without global acceptance. But global acceptance is not necessary to begin making DNS more reliable.

Islands of trust

Even without global implementation, DNSSEC implementation can incrementally improve DNS transaction integrity through the use of islands of trust. See Figure 2.

Figure 2
(nominet.org.uk)

Instead of the trust anchor being a root name server, it is the uk-DNSSEC domain. This could represent something as restricted as a corporate domain with internal child domains. As other levels in the DNS hierarchy transition to DNSSEC, these islands can easily establish a trust relationship with them by exchanging keys, as shown in Figure 3.

Figure 3
(SP800-81, NIST)

Note that in this example, the .com TLD does not have a trust relationship with root. However, this would not prevent all domains under .com from building chains of trust up to the .com trust anchor.

The final word

DNSSEC is not a DNS panacea, and it doesn’t encrypt data. It only signs RRs. However, it promises to establish a level of authenticity in DNS transactions. Overcoming challenges preventing global acceptance might take years. However, several country TLDs already support DNSSEC, making national islands of trust possible. Incremental steps like these will help make DNS, and the Internet, safer. They should not be ignored.

DNSSEC is a complex topic. See the following documents for detailed analysis, design and deployment:

• Secure Domain Name System (DNS) Deployment Guide, NIST SP 800-81
• DNSSEC: The Protocol, Deployment, and a Bit of Development (Cisco)
• The Case Against DNSSEC
• Resource Records for the DNS Security Extensions (IETF, RFC 4034)
• A Illustrated Guide to the Kaminsky DNS Vulnerability
• Verisign and ICANN Square off Over the DNS Root
• DNSSEC Introduction and Resources (ISC)

Source: Tom Olzak, You don’t have to wait to deploy DNSSEC, Retreived from http://blogs.techrepublic.com.com/security/?p=663 on November 19th, 2008

Proposal for Signing the DNSSEC Root

The U.S. National Telecommunications and Information Administration (NTIA) is soliciting comments on signing the DNSSEC root. Ignore the caption on the page: this is not about DNSSEC deployment, which is already happening just fine. It's about who gets to sign the root zone.

A handful of us DNSSEC dweebs wrote a response that emphasizes the technical need to start signing sooner rather than later, and strongly supports signing by either of the parties who are already trusted to put information into the root—IANA or the root zone operators. My name is on the 'From:' line simply because I was the one to email it to the NTIA. I wrote the first draft of the document, but other signers did some serious editing before we turned it in.

We hope that this will help NTIA feel more at ease about moving forwards quickly without agonizing about all the different people who want to hold the keys.

Source:circleid.com/posts/20081113_proposal_signing_dnssec_root_zone

Internaut | Antidote to DNS cache poisoning

Commentary: To protect against Domain Name System poisoning, consider these strategies

Chances are your agency is in the middle of locking down all its Domain Name System servers. Security vulnerabilities discovered this summer have caused government agencies to rush to implement the appropriately named DNS Security Extensions (DNSSEC). But keep in mind that there are a range of DNS vulnerabilities that could threaten the government's business continuity.

So let's examine DNS and the security problems a bit more closely.

As you might know, the Internet DNS is the international system for translating domain names into numeric locations. It also provides the official hierarchical naming system for all connected networks.

Many descriptions of DNS start with the world's top-level domains, including .gov, .mil, .org, .com, .edu and more. But sometimes it's easier to comprehend DNS from the bottom up. Taking that view is also a good way to understand why a government DNS server that lacks the new — and now required — DNSSEC can be vulnerable to fraud or spoofing.

So let's start the journey from an end user's computer.

When people need to reach your government agency via the Internet, they probably type www.YourAgencyName.gov into their Web browsers. Their computers, in turn, must find a way to translate that name into a numeric IP address. That's how the Internet finds your server.

Most Internet service providers maintain at least one DNS server. In fact, a local DNS server connection is part of each computer's TCP/IP properties when it is set up for Internet connectivity. The ISP's local DNS server is usually the first place the Web surfer's computer goes to look for the address translation.

If you work in a big organization, you probably have a local DNS server right in your building.

Traditionally, the local DNS server first tries to use its cache of resource record information to answer queries. Because those types of servers remember previous lookups in a cache, they are sometimes called caching name servers or caching resolvers. If the end user is trying to connect to a popular domain name, chances are it's already in the local DNS server's memory. That is called a recursive query.

But if there is no local record for the requested domain name, the DNS server can query other DNS servers on the network and send an answer back to the client. That is called an iterative query.

Somewhere between a recursive query and an iterative query, things can be spoofed or "poisoned." An attacker can send fake DNS information in response to a query. This fools the local DNS server into accepting the wrong information for a domain name. This is called cache poisoning because the server remembers the incorrect information in its cache. It will continue to provide the wrong information in future lookups.

Think of the Internet DNS as a distributed database system. Top-level domains and subdomains have to maintain one or more authoritative DNS servers that store records about domain names and the names of devices within that domain.

The DNS server at the top of the domain serves as the root. It is the ultimate authority, with the latest domain name information updated daily or even more often.

An iterative DNS lookup might need to reach all the way back upstream to the authoritative DNS root when it looks up domain names.

The good news is that authoritative name servers at the top of the DNS pyramid are not vulnerable to cache-poisoning attacks unless those servers are configured as both authoritative and recursive name servers.

The bad news is that depending on how high up in the DNS food chain a cache is poisoned, the bad data can trickle down to many other servers as domain names are looked up.

DNSSEC was created to better protect local DNS servers. That's why the federal government is hustling to install the solution on all DNS servers. But there are other things that can be done.

To protect against DNS poisoning, consider the following strategies:

* The authoritative name server on a government network should never be configured to also serve as a recursive name server.
* Install the official DNSSEC on your DNS server. Those extensions add data-origin authentication and data-integrity assurances.
* Look for patches for your server that randomly select a source port for DNS queries. Cache poisoning is more difficult if the port is not known.
* If possible, set your local DNS servers to greatly reduce the number of recursive lookups they perform.
* Fixing the government's servers is one thing. But cache poisoning can occur elsewhere on the Internet. That means a government employee connecting to a government network from an external ISP (from home or while on the road) could be vulnerable to DNS issues when trying to reach a government domain. Thus, managers should educate employees in how to spot spoofed Web pages, and they should consult ISPs to make sure they are working to address DNS security issues.

For a quick test, go to recursive.iana.org and point the test server at your home domain. That will tell you if your DNS servers are configured in a risky way.

Source: www.gcn.com/online/vol1_no1/47490-1.html