S 4.353 Use of DNSSEC
Initiation responsibility: IT Security Officer, Head of IT
Implementation responsibility: Administrator
DNS Security Extensions (DNSSEC) is not yet widely used, despite design-related vulnerabilities in the DNS protocol and vulnerabilities in the DNS software. For example, this again became apparent in the design vulnerability in the DNS protocol published in summer 2008. This error in design results in cache poisoning attacks (and thereby further methods of attack) being significantly easier. In the short term, this design vulnerability may be avoided by using cryptographically strong random numbers as IDs and a random source port for requests. In the long term, problems and crises like these may only be eliminated with the help of DNSSEC. DNSSEC was specially developed to protect DNS against a large number of attacks, including cache poisoning attacks.
This is achieved with the help of asymmetrical cryptography, which is why safeguard S 2.46 Appropriate key management must be implemented together with this safeguard.
For DNSSEC, the entirety of the zone information is signed with a private key. These signatures can be verified with the help of the related public key. The pair of keys is referred to as zone-signing key (ZSK). If a DNSSEC-supporting resolver provides a DNS server where DNSSEC is configured with a request, the server returns the domain information with the signatures as response. The resolver may verify the correctness of the domain information with the help of the signature and the public key.
In order to ensure the authenticity of the ZSK, it is signed with the help of key-signing keys (KSKs). A hash value of the public share of the KSK is transmitted to the superior domain. The superior domain signs the hash value with the help of its keys and confirms the authenticity of the hash value. In this way, a chain of trust is formed. If the superior domain does not use DNSSEC, it does not have any key and is not able to create a signature in order to confirm the KSKs' authenticity. However, you may instruct your DNS servers to trust your own keys, resulting in the formation of islands of trusts. With an increasing degree of distribution of DNSSEC, these islands of trust will become larger and the level of security will become higher. DNSSEC offers the following security mechanisms:
- The source of the DNS information is authenticated.
- The integrity of the domain information is ensured so that it is no longer possible to manipulate domain information as a consequence, since the signature makes this manipulation visible. For examples, customers can be sure they are communicating with the proper web server, email server, etc.
- If a domain name does not exist, an authenticated error message is sent.
The keys ZSK and KSK must be managed carefully and changed at regular intervals as described in safeguards S 2.46 Appropriate key management. Since the ZSKs are used to sign more data material, they must be changed more often. Depending on the size of the signed zones, changing the keys every one to three months is an appropriate level of security. The KSKs should be changed at least once a year. If the KSKs and ZSKs are disclosed to the public, the keys must be changed immediately.
The use of DNSSEC and the cryptographic operations required based on the this make it necessary to adapt the capacity of DNS servers; the computing power must be increased in particular, if required. It must be ensured that the response time remains short even in the event of load peaks.
Review questions:
- Has it been ensured that the keys KSK and ZSK for DNSSEC are changed regularly?
- Has the capacity of the DNS servers been increased when compared to DNS servers without DNSSEC?