Earlier in an article dedicated to DNS servers, we examined how they interact with each other during domain name resolution. However, some security aspects were not considered — aspects that affect server operation due to protection mechanisms against attacks, one of which is DNSSEC. Let’s look at the specifics of its use and its impact on the DNS system.
Vulnerabilities in DNS Protocol Operation
During domain name resolution, DNS clients (resolvers) constantly communicate with servers to obtain authoritative information about a domain in the form of its IP address. To speed up the system, such queries are cached, and this information is later used by servers to generate responses to other DNS clients.
If an incorrect IP address enters the cache in any way, it quickly spreads across the network, leading to mass redirection of clients from the requested domain’s address to the one stored in the cache. This vulnerability is most often exploited by attackers. This type of attack is known as DNS cache poisoning.
The cache can be “poisoned,” for example, in the following way.
A target object named Server1 sends a query to a malicious object named Server2. The A record may look like this:
subdomain.attacker.mynewsite. IN A
Server2 sends the following response:
Answer: (no response) Authority section: attacker.mynewsite. 3600 IN NS ns.target.mynewsite. Additional section: ns.target.mynewsite. IN A a.b.c.d
Where a.b.c.d is the IP address of Server2.
As a result, Server1 saves in its cache the IP address of Server2 specified in the additional section. This allows the distributor of false information to later respond to queries for the entire target.mynewsite domain — that is, to redirect DNS clients wherever the attacker wants, for example, to a website infected with ransomware.
Thus, if servers do not verify the correctness of responses received from other servers, there will always be a high likelihood of cache poisoning and, consequently, of issuing incorrect addresses in the DNS system.
Such attacks can be mitigated through the following DNS server–side measures:
- Ignoring records that are not directly related to the DNS query;
- Using random UDP ports for DNS queries;
- Applying the DNSSEC mechanism.
Ignoring unrelated records, as well as reducing trust in incoming information in general, will certainly reduce the chance of cache poisoning, but will not eliminate it entirely.
The protection method using UDP ports could be effective if network devices performing port address translation (PAT) did not interfere with the randomness generated by the server. This negates the server’s efforts by preventing the guarantee of random port selection.
The DNSSEC (Domain Name System Security Extensions) mechanism uses digital signatures to ensure data integrity. Its use can be effective only when specialized software is present on both the DNS server and client sides. Below we take a closer look at this mechanism.
DNSSEC Basics
This extension allows a chain of “trust” to be created between servers, thereby preventing them from receiving false information. This chain begins at the root zone, which is why the implementation of DNSSEC starts with signing the root zones of domains and then extends to the root servers of domain areas. This is a long process that began several years ago and is still not fully completed.
The specifications RFC 4033, RFC 4034, and RFC 4035 describe the structure of the DNSSEC protocol in detail, enabling it to be implemented across all network domain zones — most of which already use it in practice.
The essence of the mechanism is as follows. Each DNS record stored on a zone server has a corresponding digital signature. A server’s response is considered trustworthy only if it passes all checks and the record is fully verified. A system of keys is used for this purpose.
The main KSK (Key Signing Key) is required to sign the root zone key, known as the ZSK (Zone Signing Key). ZSK keys are temporary and are updated four times a year. They are generated by a division of the international ICANN corporation.
At the top of the trust chain is the root domain and the root zone ZSK.
Processing DNS Queries with DNSSEC Enabled
Below is a simplified scheme of DNS server interaction when the security extension is enabled:
- The user enters the website address information.com;
- The local server’s cache is checked, and if the answer is absent, the DNS client (resolver) queries the provider’s server;
- If the requested domain data is absent, the query is redirected to the root server, which indicates that DNSSEC is enabled;
- The root server returns the address of the server responsible for the .com zone (m.b.v.net), as well as NS and DS records and their signatures;
- The DNS client verifies the ZSK, the DS signatures of the root zone, and, if successful, the signature of the DNSKEY record of the level below the .com zone;
- If the checks are successful, the resolver redirects the query to m.b.v.net;
- The m.b.v.net server responds that the information.com zone is handled by the server z.com, and returns the ZSK key set for the .com zone signed by the .com KSK, as well as the DS record of the information.com KSK signed by the .com ZSK;
- The DNS client compares the hash received from the root server with the hash it computed from the .com KSK, and if they match, verifies the signatures of the .com zone keys and begins to trust that zone’s ZSK. The information.com KSK is also verified;
- If the previous verifications are successful, the resolver receives the DS record of the information.com KSK and the address of the z.com server that stores information for the information.com zone;
- The client contacts the z.com server to obtain the IP address of information.com, indicating that DNSSEC is enabled;
- When the z.com server determines that the information.com zone is hosted on it, it sends the client a response containing the ZSK key set for information.com signed by the information.com KSK, as well as the IP address of information.com signed by the ZSK;
- The client verifies the information.com KSK, the information.com ZSK, and the IP address of information.com;
- If verification is successful, the resolver returns the response to the user with the IP address of information.com and confirmation that the response has passed validation.
Here, DS (Delegation of Signing) is a record containing the hash of the child domain and its KSK; DNSKEY is a record containing the public part of the key and its identifiers.
The algorithm above is fundamental and is always performed during domain name resolution in the DNS system.