The Hidden Potential of DNS In Security: Combating Malware, Data Exfiltration, and more - The Guide for Security Professionals by Joshua Kuo & Ross Gibson

Author:Joshua Kuo & Ross Gibson [Kuo, Joshua & Gibson, Ross]
Language: eng
Format: epub, pdf
Published: 2023-08-02T04:00:00+00:00

A Brief Overview of Recursive Resolvers and Delegation

To better understand how malicious actors exploit recursive resolvers in cache poisoning attacks, it’s helpful to know a few basics of a process known as DNS delegation. It should come as no surprise to learn that the DNS is essentially a vast, distributed database. DNS root servers do not store every single name in the world in a giant database. Not only would responses from the root servers be horribly slow, but it would also be extremely difficult to manage entries in such a large database. Instead, DNS root servers delegate responsibility for portions of the global namespace, such as com., net., and org., to other servers. Those other servers each delegate further to the servers that control subdomains of their namespace— example.com., slashdot.net., and isc.org., are a few examples. If you think of the DNS as many disjointed pieces of information, delegation is a directional sign that allows recursive resolvers to quickly locate specific resources from within that globally distributed database.

Let’s use a short example to illustrate how recursive resolvers “chase down” delegations. Say Morpheus wants to know Neo’s phone number. He knows the Oracle knows everything, so he calls the Oracle, who tells Morpheus to talk to Courtney. When Morpheus calls Courtney, she says she doesn’t know Neo’s number, but she knows that Satya works with Neo. So, Courtney refers Morpheus to Satya by sending him the name and number of Satya. Morpheus then calls up Satya, who may be able to provide Neo’s number or, if not, refer Morpheus to yet another person, and this process continues until Morpheus finds the direct number to reach Neo. In DNS, these referrals of name and numbers are NS (nameserver) and glue records, respectively.

Essentially, when a recursive resolver (Morpheus) is looking for a domain name (Neo), it always starts by contacting the root servers (represented by the Oracle), which provides the answer (referral) pointing to the TLD (e.g., com.): “The name you are looking for is delegated to someone else (Courtney) to manage. Here is the name (NS record) and address (glue record) of the responsible party. That’s who you should talk to next.” The recursive resolver then presses on, querying the next name server (Courtney). If it gets another referral (e.g., Satya), it keeps asking other name servers until it receives a final answer to its question.

As the recursive resolver goes through this process, it adds each piece of data to its cache to help speed up the process for subsequent queries. For example, if it already has information for com. in its cache, it can talk to the com. servers directly, rather than having to go to the root servers first.

Once the recursive resolver gets the last bit of information needed to provide the answer to the original query (Neo’s phone number), it checks that the information is valid before accepting the information and saving that data in its cache. This brings us to our next section, which discusses how recursive resolvers check the validity of the responses they receive.

Download

Copyright Disclaimer:
This site does not store any files on its server. We only index and link to content provided by other sites. Please contact the content providers to delete copyright contents if any and email us, we'll remove relevant links or contents immediately.