DNSSEC: Security for Essential Network Services - Page 3
How DNSSEC Works
From our discussion so far, it is clear that DNS has some major security issues that urgently need to be addressed. The Internet and security engineering communities have responded to the threats by developing DNSSEC, a new secure DNS protocol, which addresses the data integrity and source-spoofing issues by means of a public key distribution. Interestingly, the extensions do not protect against buffer overruns or DDoS types of attack, nor do they provide confidentiality -- another major issue.
To maintain as much backwards compatibility as possible, the DNSSEC protocol requires only minor changes to the DNS protocol. DNSSEC has added four additional record types (SIG, KEY, DS, and NXT) and two new message header bits (CD and AD). Because the UDP protocol has a packet size limit of 512 bits, DNSSEC requires the use of EDNS0 extensions that override the limitation so that larger key sizes can be accommodated.
The DNSSEC implementation uses the familiar public/private key system. The site administrator generates a key pair for the secured domain. The private key is generally kept on the domain's primary master name server, and the public key is published in the domain in a KEY record. The administrator signs the domain's data record to verify its authenticity and adds a SIG record, which contains the signature for each domain record. The administrator submits the public KEY to the administrator of the domain's parent to sign with proof that he is the administrator of that domain. The parent domain's administrator signs the domain's public KEY and returns it. Unfortunately, a major unresolved issue is that nobody has really determined key authentication and verification methodologies. How keys are configured initially and how they are updated has yet to be determined as well.
Advantages
DNSSEC solves many of the worst DNS security problems. It is based on generally known technology and is backwards compatible with the existing DNS infrastructure. It is completely transparent to the user population and downstream administrators if they choose not to implement the extensions. While it does require installation of BIND 9 or later, you should upgrade to BIND 9 for many other beneficial reasons.
Disadvantages
So why has DNSSEC not been widely adopted by the Internet community to date? After all, increased security of such a vital service should be an important priority for the maintenance of the Internet. Unfortunately, the implementation of DNSSEC is problematic because of the large increase in the computational load it puts on the servers, the hierarchical model of trust, the lack of tools to support the additional administrative overhead, the need for a higher level of time synchronization between the servers, and most critically, DNSSEC by itself does not begin to solve all the known DNS security vulnerabilities.
Increased Computational Load
DNSSEC significantly increases the size of DNS response packets, which drastically increases the computational load on the DNS servers and also increases the query response time. Just the process of verifying signed resource records is computationally intensive, particularly if you choose larger key sizes. The DNSSEC standard allows up to 1024 bit keys. Adding digital signatures to a domain increases each record size 5-7 times, which puts a burden on upstream name servers.
Hierarchical Trust Model
Like DNS itself, DNSSEC's trust model is almost totally hierarchical. Any compromise in the chain between the root servers and a target machine can damage DNSSEC's ability to protect the integrity of the data owned by that downstream system.
Lack of Management Tools
DNSSEC is an order of magnitude more complex than DNS. Since the system is relatively new, there are few tools to help with the cumbersome task of maintaining a signed domain. Serious problems can occur with configuration errors and expired keys, and monitoring and log analysis tools are virtually non-existent. Debugging the errors by hand can be time consuming and difficult.
Forces Stricter Time Synchronization
DNSSEC requires at least some time synchronization between the primary and secondary name servers. This is problematic because NTP (Network Time Protocol) itself is insecure, which opens up the possibility of DoS attacks based on invalid times.
