What Is DNSSEC Principles, Configuration, and Deployment?

What is DNSSEC Background and Objectives?

The Domain Name System (DNS) was designed by some “Too simple, Too Naive” pioneers of the Internet, operating well in a trusted and clean environment like other protocols or systems on the Internet. However, today’s Internet environment is exceptionally complex, filled with various frauds and attacks, and the vulnerabilities of the DNS protocol have surfaced. Attacks on DNS can cause widespread Internet outages, a phenomenon seen frequently both domestically and internationally. But what is DNSSEC?

Despite ongoing attention to DNS security issues in the Internet research and engineering community, a common attack remains unresolved, namely DNS spoofing and cache poisoning. DNS Security Extensions (DNSSEC) were primarily introduced to address this problem (though they have other uses as well). Therefore, before introducing the principles of DNSSEC, it is necessary to briefly explain the principles of DNS spoofing and cache poisoning attacks.

DNS Spoofing Attack and Cache Poisoning

When a user accesses a website using a domain name (e.g., www.example.com), the user’s computer typically converts the domain name into an IP address through a Domain Name Resolution Server (Resolver Server, also known as a Recursive Server). The resolver server usually needs to obtain the IP address of the target server by querying the Root Domain Name Server (Root), Top-Level Domain Server (TLD), and Authoritative Name Server through recursive queries, and then delivers it to the user’s computer.

For any of the above requests (1, 2, 3, 4), an attacker can impersonate the responder (root, top-level domain, authoritative domain, or resolver server) and send a forged response to the requester containing an incorrect IP address. The user’s computer or resolver server naively accepts the forged response, resulting in the user being unable to access the legitimate website or even redirected to a fraudulent website. Because normal DNS resolution uses UDP protocol rather than TCP, forging DNS responses is relatively easy. If an attacker can monitor any communication link in the process above, this attack is straightforward.

Furthermore, due to the role of DNS caching, such erroneous records can persist for a considerable period (e.g., several hours or even days), preventing all users of that domain name resolution server from accessing the genuine server. According to [1], for well-known reasons, the caches of almost all resolution servers in China have been severely contaminated, posing many challenges for user access and network management. Attackers could be hackers, network administrators, etc., but this article does not delve into the identities and motivations of these attackers.

Objectives, History, and Significance of DNSSEC

The reason such attacks can succeed is that requesters of DNS resolutions cannot verify the authenticity of the responses they receive. DNSSEC provides a weapon for resolvers to prevent being deceived—a mechanism to verify the authenticity and integrity of response information using cryptographic techniques. Domain Name Resolution Servers can validate the responses they receive (including responses indicating the non-existence of a domain) to determine if they are from legitimate servers or if they have been tampered with during transmission.

Although DNSSEC is not complex in principle, it has been more than ten years since the first DNSSEC standard RFC 2065 [2] was published in 1997, with significant progress made only in the last year or two. In 1999, the IETF revised the DNSSEC standard in RFC 2535 [3], which proved unsuccessful. It was not until 2005 that a viable DNSSEC standard was developed (RFC 4033-4035) [4][5][6], which is currently implemented by mainstream domain name service software (such as BIND). In 2008, the IETF released NSEC3 (RFC 5155) [7] to enhance the privacy protection capabilities of DNSSEC. With the deployment of DNSSEC, there may still be new issues and revisions in the development of the DNSSEC standard.

Although DNSSEC’s objectives are limited to this (i.e., not protecting the confidentiality of DNS information and the availability of services), the successful deployment of DNSSEC has other benefits for Internet security, such as enhancing the security of email systems or even using DNS as a Public Key Infrastructure (PKI).

This article introduces the working principle of DNSSEC based on RFC 4033-4035. The details of DNS operation, configuration, and digital signature technology are beyond the scope of this article, and interested readers can refer to [8]. Based on this foundation, the basic configuration process of the most commonly used domain name service system (BIND) is briefly introduced, followed by the international deployment status of DNSSEC and its potential impact on network security.

What is DNSSEC Principle?

Simply put, DNSSEC relies on digital signatures to ensure the authenticity and integrity of DNS response messages. Authoritative name servers sign resource records (RRs) with their private keys, and resolver servers verify the received responses using the public keys of authoritative servers. If verification fails, it indicates that the message may be counterfeit or tampered with during transmission or caching. RFC 4033 provides an overview of the security features provided by DNSSEC and detailed concepts, followed by a simplified example illustrating how DNSSEC works.

As shown in Figure 2, a resolver server supporting DNSSEC (Security-Aware Resolver) requests the domain name www.test.net. from an authoritative name server (Security-Aware Name Server) that supports DNSSEC. In addition to receiving a standard A record (containing an IPv4 address), it also receives a corresponding RRSIG record for test.net. containing the digital signature of the authoritative domain, signed with the private key of test.net. To verify the correctness of this signature, the resolver server can query the corresponding public key of test.net. from the domain server of test.net., named DNSKEY type resource record. Then, the resolver server can use this public key to verify the authenticity and integrity of the www.test.net. record mentioned above.

However, how does the resolver server ensure that the public key (DNSKEY record) is returned by test.net? Is genuine and not counterfeit? Although test.net. returns the DNSKEY record, it also returns a digital signature of this public key (RRSIG record named test.net.), indicating that the attacker can forge both the public key and the digital signature without being detected by the resolver.

Similar to the X509-based PKI system, DNSSEC also requires a trust chain, with one or more initial trusted public keys (or hashes of public keys) that are trusted from the beginning, referred to as “Trust Anchors” in RFC 4033. The previous node in the trust chain signs the hash value of the next node’s public key, ensuring that each public key in the trust chain is authentic. Ideally, each resolver server (with full deployment of DNSSEC) needs only to retain the DNSKEY of the root domain name server.

In the example above, assuming the resolver server initially does not trust the public key of test.net., it can query the DS (Delegation Signer, DS RR) record of test.net. from the parent domain server net., where the resolver server has manually configured the public key of the net. (i.e., Trust Anchor). It can then verify the correctness of the test.net. public key (DNSKEY) accordingly.

Resource Records of DNSSEC

To implement the signing and verification of resource records, DNSSEC introduces four types of resource records: RRSIG (Resource Record Signature), DNSKEY (DNS Public Key), DS (Delegation Signer), and NSEC (Next Secure). The first three records are mentioned in the example above, and the NSEC record is designed to respond to non-existent resource records. For specific explanations, refer to RFC 4034, which is briefly summarized in this article.

DNSKEY Record

The DNSKEY resource record stores the public key. Here is an example of a DNSKEY resource record:

example.com. 86400 IN DNSKEY 256 3 5 (
                        AQPSKmy….. aNvv4w==
                    )

In this example:

• 256 is the flag field, a 16-bit number. If the 7th bit (starting from the left as 0) is 1, it indicates a Zone Key (ZK). This key can be used to validate the signatures of data, and the owner of the resource record (example.com.) must be the name of the zone.
• The next field “3” is the protocol field, which must have a value of 3, indicating it is a DNSKEY, to remain compatible with previous versions of DNSSEC.
• The next field “5” is the algorithm field, identifying the type of algorithm used for signing. Common values include: 1: RSA/MD5; 3: DSA/SHA-1; 5: RSA/SHA-1.
• The last field in parentheses is the Public Key field, the format of which depends on the algorithm field.

In practice, administrators of authoritative domains usually use two keys in conjunction to sign zone data: one is the Zone-Signing Key (ZSK), and the other is the Key-Signing Key (KSK). The ZSK signs the zone data, while the KSK signs the ZSK. This approach has two advantages:

1. Data signed with the KSK key is minimal, and the probability of it being cracked (i.e., the corresponding private key being found) is low. Therefore, a long lifespan can be set. The hash value of this key is stored as a DS record in the parent domain server and requires the digital signature of the parent domain, reducing the workload of key updates.
2. The data volume of ZSK signatures is relatively large, making them more susceptible to cracking, so their lifespan should be shorter. Because of the presence of KSK, ZSKs do not need to be placed in the parent domain’s DNS. Updating ZSKs does not incur significant management overhead (no interaction with the parent domain servers).

RRSIG Records

The RRSIG resource record stores the digital signature of a resource record set (RRSet). Below is an example of an RRSIG record generated after signing an A record:

host.example.com. 86400 IN RRSIG A 5 3 86400 20030322173103 (
                        20030220173103 2642 example.com.
                        oJB1W6WNGv+ldvQ3WDG0MQkg5IEhjRip8WTr
                        ...
                        J5D6fwFm8nN+6pBzeDQfsS3Ap3o= )

Starting from the fifth field (“A”), the meanings of each field are as follows:

Type Covered: Indicates the type of resource record covered by this signature, in this case, A.

Algorithm: The digital signature algorithm, as in the Algorithm field of the DNSKEY record; here, 5 represents RSA/SHA-1.

Labels: The number of labels in the owner name of the signed resource domain name (host.example.com has 3 labels in this example, *.example.com has 2 labels, and “.” has 0 labels).

The subsequent fields denote the TTL of the signed record, the expiration time, and the inception time.

Next (2642) is the Key Tag, a 16-bit integer computed simply by overlaying the corresponding public key data. When a domain has multiple keys (e.g., one KSK and one ZSK), the Key Tag, along with the following signer’s field (example.com.), determines which public key is used to verify the signature.

DS Records

DS (Delegation Signer) records store the hash values of DNSKEYs to authenticate their validity and establish a trust chain. Unlike DNSKEYs stored in the zone files of the authoritative domain, DS records are stored in the parent domain’s servers (Delegation); for example, the DS RR of example.com is stored in the .com zone.

Below is an example of a DS record:

dskey.example.com. 86400 IN DS 60485 5 1 ( 2BB183AF5F22588179A53B0A98631FAD1A292118 )

Following DS are the fields: Key Tag, Algorithm, and Hash Algorithm (1 denotes SHA-1). The content within parentheses represents the hexadecimal representation of the SHA-1 calculation result of dskey.example.com. Example.com must digitally sign this record to validate the authenticity of the DNSKEY.

NSEC Records

NSEC records are designed to respond to queries for non-existent resource records. To ensure the security of private keys and server performance, all signature records are generated in advance (even offline). Servers cannot pre-generate a common “non-existent” signature record for every non-existent record, as this could be replayed. Nor is it feasible to generate a unique signature for each non-existent record because the server doesn’t know what records users will request.

During zone data signing, NSEC records are automatically generated. For instance, between vpn.test.net and xyz.test.net, the following two records are inserted:

vpn.test.net. 10800 IN A 192.168.1.100
172800 NSEC xyz.test.net. A RRSIG NSEC
172800 RRSIG NSEC 5 5 172800 20110611031416 (
                    20110512031416 5271 test.net.
                    Ujw/aq….15dV5tF7XgWSR78= )

The NSEC record includes two items: the sorted next resource record name (xyz.test.net.) and all resource record types for vpn.test.net. (A, RRSIG, NSEC). The subsequent RRSIG record is the digital signature for this NSEC record.

When a user requests a domain name between vpn and xyz, such as www.test.net., the server responds with a domain does not exist message, including the NSEC record of vpn.test.net.

Modifications to the Existing DNS Protocol by DNSSEC

Due to the size of new DNS resource records, DNS servers supporting DNSSEC must also support EDNS0 (RFC2671), allowing DNS message sizes to reach up to 1220 bytes (rather than the original 512 bytes), and possibly up to 4096 bytes.

DNSSEC adds three flags to the message header:

1. DO (DNSSEC OK, see RFC3225): DNS resolving servers that support DNSSEC must set the DO flag to 1 in their DNS query messages. Otherwise, authoritative domain servers will not return RRSIG records assuming the resolver does not support DNSSEC.
2. AD (Authentic Data): AD is the authentication data flag. If the server validates DNSSEC-related digital signatures, it sets the AD flag to 1; otherwise, it sets it to 0. This flag is typically used between non-validating security-aware resolvers and their trusted recursive name servers. A resolver that does not validate digital signatures itself accepts a response with AD set to 1 from the recursive server, assuming the communication link between them is secure, such as through IPSEC and TSIG.
3. CD (Checking Disabled): The checking disabled flag is used between validating security-aware resolvers and recursive domain servers that support DNSSEC validation. When sending a request, the resolver sets CD to 1, instructing the server to skip digital signature validation and directly return the recursive query result for the resolver to validate the signature’s legitimacy.

Finally, DNSSEC validating resolvers must distinguish among four possible outcomes for received RRSIG records:

• Secure: The resolver establishes a trust chain to the signer of the resource record and verifies that the digital signature is correct.
• Insecure: The resolver receives a resource record and its signature but cannot establish a trust chain to the signer, hence cannot validate.
• Bogus: The resolver has a trust chain to the signer of the resource record but the signature verification fails. This may be due to an attack or misconfiguration by the administrator.
• Indeterminate: The resolver cannot obtain sufficient DNSSEC resource records to determine whether the requested resource record should be signed.

What is DNSSEC Configuration?

Despite the daunting nature of how DNSSEC operates, configuring it is not overly complex. This section uses BIND 9 as an example to introduce the basic configuration of DNSSEC. Although DNSSEC has been supported since BIND 9.3, it is recommended to use the latest stable version of BIND (currently 9.8).

There are two main scenarios for configuring DNSSEC:

1. Configuring a Secure Resolver: This server protects its users from DNS spoofing attacks by validating digital signatures.
2. Configuring a Secure Authoritative Name Server: This server signs authoritative domain records to protect against domain spoofing attacks.

Configuring a Secure Resolver

Activating DNSSEC

First, open the DNSSEC options in BIND’s configuration file (usually /etc/named.conf):

options {
    directory "/var/named";
    dnssec-validation yes;
    …
};

Configuring Trust Anchor

Next, configure Trust Anchors for the resolver, which are the DNSKEYs of trusted authoritative domains. Ideally, configure at least the root key. Obtain DNSKEY files from trusted sources such as:

• Root Zone DNSSEC Trust Anchors
• The UCLA secspider
• The IKS Jena TAR

Example format of these files:

trusted-keys {
    "test.net." 256 3 5 "AQPzzTWMz8qS…3mbz7Fh
    ……
    ….fHm9bHzMG1UBYtEIQ==";
    "193.in-addr.arpa." 257 3 5 "AwEAAc2Rn…HlCKscYl
    kf2kOcq9xCmZv….XXPN8E=";
};

Assuming these trust anchors are in /var/named/trust-anchors.conf, include them in /etc/named.conf:

include "/var/named/trust-anchors.conf";

Testing DNSSEC

After making these configuration changes, restart the named process. Test by querying a zone or domain under a trust anchor using dig the resolver:

# dig @127.0.0.1 +dnssec test.net. SOA

If configured correctly, it should return the SOA record for test.net along with the corresponding RRSIG record. Additionally, the response header should include the AD (Authenticated Data) flag, indicating successful DNSSEC signature validation.

If the expected results are not obtained, review DNS logs to identify issues. Configure DNSSEC-related events in /etc/named.conf for logging:

logging {
    channel dnssec_log {
        file "log/dnssec" size 20m; // a DNSSEC log channel 20m;
        print-time yes; // timestamp the entries
        print-category yes; // add category name to entries
        print-severity yes; // add severity level to entries
        severity debug 3; // print debug message <= 3 t
    };
};

category dnssec { dnssec_log; };

Configuring an Authoritative Server

Generating Key Pairs

Generate a Key Signing Key (KSK) and a Zone Signing Key (ZSK) for your zone file:

# cd /var/named
# dnssec-keygen -f KSK -a RSASHA1 -b 512 -n ZONE test.net.
Ktest.edu.+005+15480

# dnssec-keygen -a RSASHA1 -b 512 -n ZONE test.net.
Ktest.edu.+005+03674

Signing

Include these DNSKEY records in your zone file (db.test.net) and sign the zone:

# cat "$INCLUDE Ktest.net.+005+15480.key" >> db.test.net
# cat "$INCLUDE Ktest.net.+005+03674.key" >> db.test.net

# dnssec-signzone -o test.net. db.test.net
db.test.net.signed

Update /etc/named.conf:

options {
    directory "/var/named";
    dnssec-enable yes;
};

zone "test.net" {
    type master;
    file "db.test.net.signed";
};

Remember to re-sign whenever the zone data changes:

# dnssec-signzone -o test.net -f db.test.net.signed.new db.test.net.signed
# mv db.test.net.signed db.test.net.signed.bak
# mv db.test.net.signed.new db.test.net.signed
# rndc reload test.net

Publishing Public Keys

To allow others to verify your signatures, distribute the DS and DNSKEY records generated by dnssec-signzone to the parent zone administrators (e.g., .net):

test.net. 86400 IN NS ns.test.net.
86400 DS 15480 5 1 (
    F340F3A05DB4D081B6D3D749F300636DCE3D
    6C17 )
86400 RRSIG DS 5 2 86400 20060219234934 (
    20060120234934 23912 net.
    Nw4xLOhtFoP0cE6ECIC8GgpJKtGWstzk0uH6
    ……
    YWInWvWx12IiPKfkVU3F0EbosBA= )

If your parent zone server does not yet support DNSSEC, consider submitting these files to public trust anchor databases or directly providing them to resolver administrators who trust your server.

This completes the basic configuration of DNSSEC using BIND 9.

How to Deploy DNSSEC

DNSSEC is widely regarded in the field of Internet engineering as a critical enhancement to Internet infrastructure security. For instance, the U.S. Department of Homeland Security initiated a DNSSEC deployment program, and the U.S. National Strategy to Secure Cyberspace explicitly mandates DNSSEC deployment. The large-scale deployment of DNSSEC may also address other security issues, such as secure email and key distribution.

Despite its importance recognized by the Internet engineering community, large-scale deployment remains cautious. Countries such as Brazil (.br), Bulgaria (.bg), Czech Republic (.cz), Puerto Rico (.pr), and Sweden (.se) began deploying DNSSEC on their national top-level domains early. IANA initiated signing experiments on a root domain server in 2007. Many organizations have made significant efforts in DNSSEC deployment; for details, refer to [9].

Under the initiatives of ICANN and VeriSign, as of July 2010, all 13 root domain servers were signed and operational [10]. Plans are also in place for top-level domains (e.g., .org, .net), with some country-code top-level domain servers (e.g., .cz, .jp, .us, .fr) having completed this task.

Several major international ISPs have begun deploying DNSSEC-supporting resolver servers to safeguard their access users’ security, with Comcast in the U.S. being one of the pioneers.

Summary and Outlook

This paper provides an overview of what is DNSSEC’s objectives, principles, basic configurations, and current deployment status. Due to limitations in length and the author’s experience, some details cannot be discussed in depth; interested readers are encouraged to consult the references provided.

The author believes that widespread deployment of DNSSEC could significantly impact the security framework of the Internet. With DNSSEC’s digital signatures, DNS can feasibly serve as a PKI for key distribution in many applications. It not only enhances the security of the DNS system itself but also provides new solutions to security issues in applications, especially in end-to-end mobile communications and IPv6 network environments.

However, the author also acknowledges that achieving this goal requires considerable effort. While DNSSEC protocols are still evolving, extensive research, experimentation, and eventual standardization are needed for other applications to utilize DNSSEC mechanisms on a large scale. Furthermore, the potential policy obstacles DNSSEC may face in certain countries remain uncertain.

Nevertheless, due to the critical importance of DNS to the Internet, if DNSSEC is indeed the path to a secure and reliable Internet infrastructure (with no alternative solutions currently visible to the author), the costs associated with its deployment are inevitable.