Unified DNS Resolution Workflow: Combining Recursive and Authoritative Processes

Introduction

DNS resolution is a critical process that translates human-readable domain names into IP addresses, enabling communication over the internet. This article presents a unified workflow for DNS resolution, combining the key points from both recursive and authoritative DNS resolution processes. This comprehensive article is essential for network architects and IT professionals seeking to understand the complete DNS resolution process.

Unified DNS Resolution Workflow

1. DNS Query: A user's device (e.g., a computer, smartphone) initiates a DNS query. It sends a message asking for the IP address of a specific domain name, such as "www.cisco.com".
2. Local DNS Resolver: The device first checks its local DNS resolver, which might be configured on your network or provided by your internet service provider (ISP).
3. Recursive DNS Resolver: If the local resolver doesn't have the answer, it sends the query to a recursive DNS resolver. This resolver is responsible for chasing down the answer until it's found.
4. Root Name Servers: The recursive resolver starts by querying the root name servers, which are the top-level authorities for the DNS hierarchy.
5. TLD Name Servers: The root name servers provide a referral to the .com Top-Level Domain (TLD) name servers.
6. Authoritative Name Servers: The .com TLD name servers then provide the IP address of the authoritative name servers for the "cisco.com" domain.
7. DNS Response: The recursive resolver queries the authoritative name servers for "cisco.com" and receives the IP address (198.133.219.25).
8. Response to Client: The recursive resolver sends the IP address back to the original DNS resolver, which then forwards it to the user's device.

This process, where the server recursively queries other servers to find the authoritative answer, is known as DNS recursion. It ensures that the client can eventually get the correct answer even if the original server doesn’t have it directly.

The above process is straightforward, and most of our day-to-day DNS resolution on the internet happens this way. However, things get interesting in an organization's enterprise environment, where they have their internal DNS servers and external DNS resolvers. The following list enumerates some of the additional aspects regulated by DNS flags that are essential to be aware of:

Additional Considerations

Server Checks if It’s Authoritative: If the server is configured as authoritative for the domain, it will respond with an authoritative answer (marked as “Authoritative Answer” in the “ANSWER” section of the response message). If it lacks this information, it will respond with “NXDOMAIN” (Non-Existent-Domain).

Server is Not Authoritative and Not Recursive: If the server is not authoritative and not configured as recursive, it will respond with a referral response. This response contains records in the “AUTHORITY” and “ADDITIONAL” sections informing the resolver where to direct its query to obtain authoritative information.

Server is Not Authoritative but is Recursive: If the server is not authoritative but is configured as recursive, it will initiate iterative queries to find the authoritative server for the domain. This process involves the server contacting other DNS servers along the way, asking for the authoritative server for the domain.

Server Receives Authoritative Answer: Once the server finds the authoritative server and receives the answer, it returns the record to the client (resolver), indicating that it is a non-authoritative answer.

Caching: The server caches the response for future use. It will reply by consulting its cache if it is asked about the same resource again and the time-to-live (TTL) has not elapsed.

Let's strengthen our skills with some engaging hands-on exercises.?

Dig (Domain Information Groper) is the go-to tool for sending DNS queries. Its output closely resembles the structure of DNS packets on the wire. It offers extensive options for querying DNS. Let's utilize the dig command to resolve www.sdntechforum.com and then decode the output

sdntech:~$dig www.sdntechforum.com +multi

; <<>> DiG 9.10.6 <<>> www.sdntechforum.com +multi
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 62721
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;www.sdntechforum.com.	IN A

;; ANSWER SECTION:
www.sdntechforum.com.	1800 IN	CNAME parkingpage.namecheap.com.
parkingpage.namecheap.com. 30 IN A 91.195.240.19

;; Query time: 124 msec
;; SERVER: 2603:6081:e240:24c::1#53(2603:6081:e240:24c::1)
;; WHEN: Thu Sep 26 09:09:51 EDT 2024
;; MSG SIZE  rcvd: 101        

The dig output with flags is explained below:

opcode: query, notify, update, DSO
status/rcode:
o NOERROR - the operation was successful
o NXDOMAIN - the domain name requested does not exist (or is not delegated)
o SERVFAIL - some remote DNS server failure or DNSSEC validation failure
o FORMERR - the query was not correct DNS
o REFUSED - this server has an access control list that forbids the answer to this client
o NOTIMPL - a feature used/requested that this server does not implement
o BADCOOKIE - Bad/missing Server Cookie

queryid: 16bit value to sort DNS answers to DNS queries
flags: information on the query and the answer (see IANA registry for DNS Header Flags
AA authoritative answer - answer is coming directly from an authoritative server
TC truncated - answer does not fit into the advertised UDP packet size, please re-query over TCP
RD recursion desired - this is a query from a client machine, please provide a full complete answer (no referral please)
RA recursion available - this answer comes from a DNS resolver that is willing to accept queries with RD flag set

DNSSEC flags: AD- and CD-Flag
  ? AD authentic data - the DNS resolver sending this answer has performed a successful DNSSEC validation on the data. If we trust the resolver, we can trust the data
  ? CD checking disabled - a client asking a DNSSEC validating DNS resolver to not perform DNSSEC validation but to pass all DNSSEC data unaltered (even if the data is wrong). Used for troubleshooting DNSSEC issues.

QUERY: number of query resource records (usually one)
ANSWER: count of DNS resource records in the answer. Can be more than one. Can be zero if no data is available for the query.
AUTHORITY: number of authority records in the answer. Can be a SOA-Record (for negative answers) or NS-Records for referrals or positive answers. Many modern DNS server only fill the authority section if required by the protocol to keep answer packets small
ADDITIONAL: additional resource records that not have been requested but might help with the name resolution, and the EDNS (Extended DNS) OPT-Record.        

Conclusion

The unified DNS resolution workflow combines the key points from both recursive and authoritative DNS resolution processes, providing a comprehensive understanding of the DNS resolution process. By following this workflow, network architects and IT professionals can ensure efficient and accurate DNS resolution, enhancing the overall performance and reliability of their networks.

This guide is essential for anyone looking to understand the complete DNS resolution process and improve their network’s security and management capabilities.

#DNSResolution #RecursiveDNS #AuthoritativeDNS #RootNameServers #TLDNameServers #DNSQuery #DNSResponse #NetworkArchitecture #ITProfessionals #sdntechforum