DNS Interview Questions and Labs

# CHAPTER 19

DNS Interview Questions and Labs #

1. Introduction #

A profound understanding of DNS is the ultimate litmus test in technical interviews. Whether you are interviewing for a Junior Helpdesk role, a Senior DevOps position, or a Cloud Architecture role, interviewers will ruthlessly probe your knowledge of DNS resolution, caching behaviors, and command-line diagnostics. They do this because a developer who does not understand DNS will spend days debugging code when the actual issue is a misconfigured A Record. In this chapter, we have curated the most rigorous, high-impact DNS interview questions, alongside practical troubleshooting labs designed to train your deductive reasoning.

2. Learning Objectives #

By the end of this chapter, you will be able to:

• Confidently answer foundational and advanced DNS interview questions.

• Articulate the mechanical difference between Recursive and Iterative lookups.

• Approach scenario-based troubleshooting questions using a structured methodology.

• Demonstrate deep knowledge of DNS records (A, CNAME, MX, TXT, PTR).

• Prepare effectively for cloud, network, and security technical interviews.

3. Core Architectural Interview Questions #

Q1: "Walk me through the exact step-by-step process of what happens when a user types google.com into their browser." *How to answer (The Gold Standard):*

1. 1. Local Cache: The browser checks its internal cache, then the OS checks its cache and /etc/hosts file.

1. 2. Recursive Query: If empty, the OS sends a Recursive query to the configured DNS Resolver (e.g., ISP or 8.8.8.8).

1. 3. Iterative Queries: The Resolver checks its cache. If empty, it initiates Iterative queries:

• It queries the Root Server (which provides the .com TLD IP).

• It queries the TLD Server (which provides Google's Authoritative Nameserver IP).

• It queries the Authoritative Nameserver (which provides the final A Record IP).

1. 4. Delivery: The Resolver caches the answer and returns the IP to the OS. The browser initiates a TCP handshake on Port 443 with the IP.

Q2: "Explain the difference between a Recursive query and an Iterative query." *How to answer:* A Recursive query is sent by the client to the Resolver; it demands a final, complete answer or an error. The burden of work is on the server. An Iterative query is sent by the Resolver to the global hierarchy (Root, TLD); it accepts the "best possible answer" or a referral to another server, continuing the hunt itself.

Q3: "What is Split-Horizon (Split-Brain) DNS, and why is it used?" *How to answer:* Split-Horizon DNS is an enterprise architecture where a single domain name (like app.company.com) points to two different IP addresses based on the user's location. If queried from the public internet, it returns a Public IP. If queried from the internal corporate network, the internal DNS server intercepts it and returns a Private IP, allowing for optimized internal routing and strict security access.

4. Scenario-Based Troubleshooting Labs #

Scenario 1: The Outdated Migration *The Setup:* You migrated your company's website to a new AWS server. You updated the A Record. You can see the new website from your home Wi-Fi, but the CEO complains that from the corporate office, they still see the old website. *The Interview Question:* Diagnose the issue and explain how you would have prevented it. *The Answer:* This is a classic DNS Caching issue caused by a high TTL (Time to Live). The corporate office's Recursive Resolver is still caching the old IP address. To prevent this, I should have lowered the TTL on the A Record to 5 minutes at least 48 hours *before* executing the migration, ensuring all global caches expired and fetched the new IP instantly.

Scenario 2: The Rejected Emails *The Setup:* A developer deploys a new mass-mailing application on an internal server. All emails sent to Gmail and Outlook addresses are bouncing back as "Rejected - Spam". *The Interview Question:* What three DNS records must you investigate? *The Answer:* I must audit the email authentication trinity:

1. 1. SPF (TXT Record): Verify the IP address of the new mailing server is authorized in the SPF list.

1. 2. DKIM (TXT Record): Ensure the application is cryptographically signing the emails and the Public Key is published.

1. 3. Reverse DNS (PTR Record): Ensure the ISP hosting the server has configured a PTR record so Gmail can perform a reverse lookup on the IP address.

5. Deep-Dive Protocol Questions #

Q4: "Can you place a CNAME record on the root/apex domain (e.g., company.com)?" *How to answer:* No. According to fundamental DNS RFC standards, a CNAME cannot coexist with any other records (like MX or TXT). Because a root domain must have SOA and NS records, placing a CNAME there causes a fatal conflict, breaking email and routing. CNAMEs should only be used on subdomains (like www). For the root, we must use an A Record (or an ALIAS/ANAME record if the DNS provider supports that custom flattening logic).

Q5: "What is the mechanical difference between DNSSEC and DoH (DNS over HTTPS)?" *How to answer:* DNSSEC guarantees *authenticity* by using cryptographic signatures to prevent Cache Poisoning attacks; however, the query remains in plain text. DoH guarantees *privacy* by encrypting the query inside an HTTPS tunnel over Port 443, hiding the browsing activity from ISPs and firewalls. They solve two completely different problems.

6. Command-Line Diagnostics #

Q6: "If a user cannot resolve any domain names, but can successfully ping 8.8.8.8, what command-line tool would you use to isolate the failure?" *How to answer:* I would use dig or nslookup. I would first run dig google.com to confirm the local resolver is failing. Then, I would bypass the local resolver and explicitly query a public server by running dig google.com @8.8.8.8. If the explicit query succeeds, I have proven the physical internet is fine, but the local ISP or router DNS settings are misconfigured or crashed.

7. Preparing for the Interview #

When answering DNS questions:

• Be Precise with Vocabulary: Do not say "The DNS server checks the other DNS server." Say "The Recursive Resolver queries the Authoritative Nameserver." Precision demonstrates seniority.

• Start at Layer 1: When given a troubleshooting scenario, explicitly state that you would first verify physical connectivity (ping IP) before jumping into complex DNS diagnostics. This proves you possess a structured, OSI-model methodology.

8. Summary #

In Chapter 19, we stress-tested our theoretical and operational knowledge against the rigorous standards of professional technical interviews. We practiced articulating the complex, multi-server choreography of recursive resolution. We tackled scenario-based labs, identifying TTL caching errors and missing PTR records as the root causes of common enterprise outages. We solidified our command-line diagnostic strategies using dig. Armed with these responses, you are prepared to demonstrate absolute architectural mastery in any networking, security, or cloud engineering assessment.

9. Next Chapter Recommendation #

You know the theory, and you passed the interview. Now it is time to build it. Proceed to Chapter 20: Build and Configure a Real DNS Infrastructure.