# DNS

> Source: Courseiva IT Certification Glossary — https://courseiva.com/glossary/dns

## Quick definition

When you type a website name into your browser, DNS is what turns that name into the actual number address the computer needs to connect. It works like a phonebook for the internet, matching names to numbers so your device can find the right server. Without DNS, you would have to remember long strings of numbers to visit any website.

## Simple meaning

Think of the internet as a huge city. Every building in that city has a street address, which is like an IP address. But you don't want to remember the exact street address of every place you want to go, you just want to say "I'm going to the library" or "I'm going to the coffee shop." DNS is the system that looks up the street address for the name you give. When you type "google.com" into your browser, your computer doesn't know what that is. It needs to ask a DNS server, which is like a giant city directory, to find out that "google.com" actually points to the IP address 142.250.190.46. Once your computer has that number, it can connect to Google's server and load the page.

This all happens in the background in just a fraction of a second. Your computer first checks its own memory, called a DNS cache, to see if it already knows the address for that name. If not, it asks a DNS resolver, which is usually run by your internet service provider or a public service like Google's 8.8.8.8. The resolver might already know the answer from previous requests, or it may have to go on a chain of queries: it asks the root DNS server, then the top-level domain server (like .com), and finally the authoritative name server for that specific domain. Each step gets you closer to the exact IP address. Once the resolver has the answer, it sends it back to your computer, and your browser can then load the website.

This whole process is critical for both the internet and internal company networks. Inside a corporate network, DNS helps employees access internal resources like "hr-app.company.local" without having to memorize IP addresses. In cloud environments like AWS or Azure, DNS services like Route 53 or Azure DNS let you map your custom domain to cloud resources. DNS is also a common target for attackers, DNS spoofing, cache poisoning, and DDoS attacks on DNS servers can bring down large parts of the internet. That's why understanding DNS is not just about knowing how to look up a name. It's about knowing how to secure it, troubleshoot it, and configure it correctly in IT environments.

If you've ever seen an error that says "DNS server not responding," that means your computer couldn't get an address for the name you typed. Your internet connection might be fine, but the directory service is broken. Restarting your router often helps because it clears a temporary glitch in the DNS resolver. Many home networks automatically use the DNS servers provided by the ISP, but you can change them to public alternatives like Cloudflare's 1.1.1.1 for better performance and privacy. DNS is one of the most fundamental services on any network, and no IT certification exam ignores it.

## Technical definition

The Domain Name System is a hierarchical, distributed naming system that translates domain names to IP addresses and performs other essential functions like mail server discovery and reverse lookups. DNS is defined by numerous RFCs, most notably RFC 1034 and RFC 1035, which specify the architecture, protocols, and data structures. The system is critical because humans prefer names, but network devices rely on numeric IP addresses for communication. DNS essentially provides a globally scalable lookup service that resolves names to IPs (A and AAAA records), IPs back to names (PTR records), mail exchange servers (MX records), name servers (NS records), and many other resource record types.

The architecture of DNS is hierarchical and decentralized. At the top are the root name servers, which are 13 logical groups (operated by various organizations) that know the addresses of top-level domain servers. Below the root are TLD servers for domains like .com, .org, .net, .gov, and country-code TLDs. Below TLDs are the authoritative name servers for individual domains. Each domain owner maintains authoritative records for their own zone. The resolution process begins when a client makes a recursive query to a DNS resolver. If the resolver doesn't have the answer cached, it performs iterative queries: it starts at a root server, follows referrals to the TLD server, then to the authoritative server, and finally receives the concrete answer. The resolver then caches the result for a time period controlled by the TTL value on the record.

DNS communication primarily uses UDP on port 53 for standard queries and TCP on port 53 for zone transfers or responses larger than 512 bytes. EDNS0 extends the UDP message size limit. Security extensions like DNSSEC add cryptographic signatures to ensure response authenticity and integrity, protecting against cache poisoning and spoofing. In modern cloud and virtualized environments, DNS is often paired with dynamic DNS (DDNS) so that devices can automatically update their records when their IP addresses change. Load balancing can also be implemented through DNS, where multiple IP addresses are returned for the same name and clients choose among them, or via more sophisticated health-check-based DNS services like AWS Route 53's latency-based routing or geolocation routing.

DNS resolution involves several components. The stub resolver is the library inside the operating system that applications call. It typically sends queries to a configured recursive resolver. The recursive resolver is the main workhorse, it performs the iterative lookups on behalf of the client. Both caching resolvers and forwarding resolvers are common in enterprise environments. Authoritative name servers hold the actual records for a zone and are typically managed by domain registrars or DNS hosting providers. Resource records are stored in zone files, which include SOA (Start of Authority) records that provide administrative metadata. The TTL controls how long each record can be cached. Understanding the difference between recursive and authoritative DNS is essential for troubleshooting and for many exam scenarios.

In exam contexts, DNS appears in multiple areas. The record associates a name with an IPv4 address. AAAA records do the same for IPv6. CNAME records alias one name to another. MX records specify mail servers. SRV records locate services like SIP or LDAP. NS records delegate authority to name servers. PTR records enable reverse lookups. TXT records hold arbitrary text, often used for domain ownership verification or SPF/DKIM email security. Many cloud and network courses test DNS configuration, troubleshooting with tools like nslookup, dig, and host, and understanding of DNS propagation delays caused by TTL values. DNS is also a favorite attack surface. DNS amplification attacks exploit open resolvers to amplify traffic in DDoS attacks. DNS tunneling can be used to exfiltrate data. Securing DNS with DNSSEC, firewalls, and proper resolver configuration is covered in security-focused certifications like Security+ and CCNA.

## Real-life example

Imagine you're traveling to a new city and you want to visit a specific restaurant called "The Blue Plate." You don't know the street address. You could wander around aimlessly, but that would take forever. Instead, you pull out your phone and search for the restaurant's address. Your phone doesn't know it either, so it sends a query to the internet, but that's where the analogy gets technical. Let's stay on the ground. Think of your phone as your computer, and the restaurant name as the domain name. The first thing you do is check your own notes: maybe you wrote the address down earlier. That's like your DNS cache. If you don't have it, you ask someone, a front desk receptionist at your hotel. The receptionist might have a list of common addresses, or she might call the central directory service. That receptionist is your DNS resolver.

If the receptionist doesn't know the address, she calls the city's main directory office. That office knows which region the restaurant is in, maybe it's in the "Downtown" area, which is like the top-level domain (.com). The directory office then gives the receptionist the phone number for the Downtown area's specific information desk. The receptionist calls that desk, which is like the authoritative name server for that domain. That desk has the exact street address for "The Blue Plate." The receptionist writes it down, gives it to you, and also keeps it in her own quick-reference list (caching) for a while so next time someone asks, she can answer faster.

Now you have the address (the IP address). You walk to the restaurant and enjoy your meal. But what if you get the wrong address because someone tampered with the directory? That's DNS poisoning. Or what if an attacker floods the directory office with so many calls that no one can get through? That's a DDoS attack on DNS. Notice also that every step involved a query and a response, that's exactly how DNS works, with a chain of servers each pointing to the next more specific source of truth.

For a real-world IT professional, this analogy plays out constantly. A user reports they can't access a website. You check the network, it's up. You check the server, it's up. But the name isn't resolving. You run nslookup and see that the resolver is timing out. You change the resolver to a public one like 8.8.8.8, and suddenly everything works. The issue was that the ISP's DNS resolver was down. This is one of the most common troubleshooting scenarios. Understanding the step-by-step flow prevents you from wasting time checking the server when the problem is really in the naming system.

## Why it matters

DNS is one of the most fundamental services on any IP network. Without DNS, the internet as we know it would not function because users would have to type IP addresses to reach every website, send every email, or connect to any resource. For IT professionals, understanding DNS is non-negotiable. Almost every network service depends on it: web browsing, email delivery, file sharing, remote access, cloud service endpoints, and even Active Directory domain authentication. A single DNS misconfiguration can bring down an entire company's ability to function, even if all other network components are working perfectly.

In modern cloud infrastructures, DNS plays an even larger role. Cloud providers like AWS, Azure, and GCP offer managed DNS services that integrate directly with their other products. Route 53 can route traffic based on latency, geography, or health checks. Azure DNS can be linked to private virtual networks. GCP Cloud DNS provides global anycast resolution. Understanding how to configure public and private DNS zones, how to set up split-brain DNS (different results for internal vs external users), and how to troubleshoot DNS resolution in complex environments is a core skill for cloud administrators, network engineers, and security professionals.

Security professionals must also understand DNS because it is a frequent attack vector. DNS spoofing, cache poisoning, and DNS-based DDoS amplification are common threats. Tools like DNSSEC and DNS over HTTPS (DoH) add layers of security but also change the troubleshooting landscape. Without a solid grasp of DNS, a security analyst cannot fully understand how an attacker might redirect traffic or exfiltrate data using DNS tunneling. For all these reasons, DNS appears in every major IT certification, from CompTIA A+ and Network+ to CCNA, AWS SAA, Security+, Azure AZ-104, and Google ACE. It is a pillar topic because it underpins everything else.

## Why it matters in exams

DNS appears prominently across almost all major IT certification exams because it is a universal networking concept. In the CompTIA A+ exam (220-1101), DNS is covered under networking basics. You are expected to know what DNS does, how to configure DNS settings on a client machine, and the role of the DNS server in a local network. You may be asked to troubleshoot a scenario where a user can't browse the internet but can ping an IP address, the likely answer is a DNS issue.

For CompTIA Network+ (N10-008), DNS is tested more deeply. You must understand the DNS resolution process, record types (A, AAAA, CNAME, MX, TXT, SRV, PTR), and the role of different servers (root, TLD, authoritative, recursive). You will need to know how to use nslookup and dig for troubleshooting, and how to interpret zone transfer issues. Questions often present a scenario where a hostname resolves to the wrong IP and ask you to identify the cause, incorrect A record, stale cache, or DNS poisoning.

In CCNA (200-301), DNS is part of the IP connectivity and network access domains. Cisco emphasizes the use of DNS for device naming, the ip domain-lookup command, and how DNS interacts with DHCP. CCNA questions may ask about configuring DNS client settings on a Cisco router, understanding DNS-based load balancing, or troubleshooting name resolution on a network where the DNS server is unreachable. You may also see questions about DNS over TCP vs UDP and when TCP is required.

For AWS Solutions Architect (SAA-C03), DNS appears heavily through Amazon Route 53. You must know how to create hosted zones, configure record sets, and choose routing policies (simple, weighted, latency, geolocation, failover, multivalue). You need to understand how Route 53 integrates with ELB, CloudFront, and S3. Questions often present a scenario where an application needs high availability across regions and you must pick the correct routing policy. Understanding DNS TTL and how it affects failover speed is also tested.

Microsoft Azure AZ-104 covers Azure DNS and custom domain names. You need to know how to configure public and private DNS zones, link private zones to virtual networks, and use DNS resolvers. Questions may ask about resolving naming conflicts when connecting on-premises networks to Azure via VPN or ExpressRoute. Security+ (SY0-601) addresses DNS security threats: DNS poisoning, DNSSEC, and DNS sinkholes. You must understand how to configure DNSSEC and what security controls to implement on DNS resolvers.

The Google Associate Cloud Engineer (ACE) exam covers Cloud DNS, including managed zones, record management, and integration with GCP load balancers. You need to understand DNS resolution for App Engine and Compute Engine instances. Across all these exams, DNS is rarely tested in isolation, it is often combined with scenarios involving HTTP, email, load balancing, security, or hybrid cloud connectivity. The ability to read DNS configuration errors and understand the impact on end users is the common thread.

## How it appears in exam questions

DNS questions in certification exams generally fall into three categories: scenario-based troubleshooting, configuration choices, and conceptual understanding. In scenario questions, the candidate is told about a user who cannot access a website but can ping external IP addresses. The correct answer is usually that the DNS resolver is not working or the DNS server is misconfigured. Another common scenario is a mail server not receiving email, the answer points to a missing or incorrect MX record. A network administrator configures a new web server but users still go to the old IP, the answer is that the DNS TTL has not expired, or the A record has not been updated.

Configuration questions often present a simple network diagram and ask which DNS record should be added to achieve a certain goal. For example, "A company wants to point www.example.com to the same server as example.com. Which record should they add?" The answer is a CNAME record. Or, "Which record do you create to verify domain ownership?" The answer is a TXT record. On cloud exams like AWS SAA, you may be asked to select the correct Route 53 routing policy for a specific availability and latency requirement. Weighted routing is the answer when you want to send a percentage of traffic to each of two load balancers for testing.

Troubleshooting questions often ask what tool to use to check DNS resolution. The answers include nslookup, dig, host, ping, traceroute, and ipconfig /flushdns. Knowing when to use each tool is essential. For example, in a Network+ exam, you might be told that a user can access a website by IP but not by name. The correct first step is to use nslookup to check what IP the name resolves to. Another common question: "After changing a website's IP, users in some locations still see the old website. Why?" The answer is cache retention due to TTL. A more advanced scenario involves a split-brain DNS setup: internal users cannot resolve a domain that external users can. The fix is to ensure the internal DNS zone has the correct A record for the internal IP of the server.

Security-focused questions describe a recent security incident where users were redirected to a fake website. The cause could be DNS cache poisoning, and the mitigation is to implement DNSSEC and configure DNS resolvers to prevent unauthorized updates. Some questions ask about DNS amplification attacks, where an attacker sends small queries with a spoofed source IP to open DNS resolvers, which then flood the target with large responses. The solution is to restrict recursive queries to trusted clients. For cloud exams, you might see a question about private DNS zones: a company needs internal resources to resolve a custom domain without exposing it to the internet. The answer is to create a private hosted zone and associate it with the VPC.

## Example scenario

You are a help desk technician. A user calls and says, "I can't get to the company website. When I type www.example.com in Chrome, it says 'DNS server not found.'" You start by asking what other websites they can reach. They say they can reach google.com and youtube.com. That tells you the internet connection is working and the DNS resolver is responding for other queries. The problem is likely with the specific domain. You try pinging the domain from your own computer and get the same error. You then use nslookup www.example.com. The response is empty, with no IP address returned. This means the authoritative DNS server for example.com is either misconfigured or unreachable.

You check the public WHOIS record for the domain and see that the name servers are ns1.exampledns.com and ns2.exampledns.com. You try to query those name servers directly: nslookup www.example.com ns1.exampledns.com. The server does not respond. You realize that the domain's name servers are down. You contact the domain registrar and ask them to check the name servers. They confirm that the DNS hosting is having an outage. To resolve the issue quickly, you could point the domain to a backup DNS service by updating the NS records at the registrar. Meanwhile, you inform users that the problem is external, and you've escalated it to the domain provider. This scenario illustrates how DNS failures can affect a single domain while others work fine, and how systematic troubleshooting isolates the problem to the authoritative name server level.

## How DNS Resolution Works: From Query to Response

The Domain Name System (DNS) resolution process is the core mechanism that translates human-readable domain names, such as www.example.com, into machine-readable IP addresses. Understanding this process is essential for networking exams like the CCNA, Network+, and AWS-SAA because it underpins nearly all internet communication.

The resolution process begins when a client application, such as a web browser, needs to connect to a server. The application initiates a DNS query by calling the operating system's resolver library. This library first checks the local DNS cache, which stores recently resolved domain names. If the requested domain is found in the cache and its Time to Live (TTL) has not expired, the resolver returns the IP address immediately, bypassing further steps. If the cache does not contain the entry, the resolver sends a recursive query to the DNS resolver configured on the client, often provided by the Internet Service Provider (ISP) or a public DNS service like Google's 8.8.8.8.

A recursive resolver is responsible for obtaining the complete answer on behalf of the client. It begins by querying a root name server. The root servers, managed by organizations like ICANN, do not know the IP address for the domain but can direct the resolver to the appropriate Top Level Domain (TLD) name server. For example, for www.example.com, the root server responds with the address of the .com TLD server. The recursive resolver then queries the .com TLD server, which responds with the address of the authoritative name server for example.com. Finally, the recursive resolver queries the authoritative name server, which holds the actual DNS records for the domain. The authoritative server returns the IP address (often an A or AAAA record) for www.example.com. The recursive resolver caches this answer for the duration of the TTL and sends the result back to the client.

Several key concepts are tested in exams. The distinction between recursive and iterative queries is critical. In a recursive query, the resolver performs all the work and returns either the final answer or an error. In an iterative query, the server may respond with a referral to another server, leaving the client to make further queries. The DNS hierarchy includes root servers (13 logical roots, many physical instances), TLD servers (.com, .org, .net), and authoritative servers. Caching reduces latency and network load, but stale cache entries can cause issues. DNS uses UDP port 53 for standard queries and TCP port 53 for zone transfers or large responses. Understanding the resolution process helps troubleshoot connectivity issues and is foundational for security concepts like DNS poisoning and DNSSEC.

## Essential DNS Record Types for Exams

DNS records are the building blocks of the Domain Name System, defining how domain names map to various resources. For exams like the Security+, AWS-SAA, and AZ-104, knowing the purpose and format of each record type is crucial for configuring services and troubleshooting.

The A (Address) record is the most fundamental. It maps a domain name to an IPv4 address. An example is: www.example.com IN A 192.0.2.1. The AAAA (Quad A) record serves the same purpose for IPv6 addresses, mapping to a 128-bit address like 2001:db8::1. These records are used when a client requests a connection to a server. For load balancing, multiple A or AAAA records can point to different IPs, and clients may choose randomly (round-robin DNS).

The NS (Name Server) record delegates a domain to a set of authoritative name servers. For example: example.com IN NS ns1.example.com. These records are essential for zone delegation. Without correct NS records, no other record for that domain will be resolved. The SOA (Start of Authority) record begins every DNS zone file. It contains administrative metadata: the primary name server, the responsible person email, serial number (for zone transfers), refresh interval, retry interval, expire time, and minimum TTL. Exam questions often test that the serial number must be incremented after any zone change.

The CNAME (Canonical Name) record creates an alias. It maps one domain to another using an A or AAAA record. For example: blog.example.com IN CNAME example.com. This is commonly used for services like www that point to the root domain. The MX (Mail Exchange) record specifies mail servers for a domain, with priority values. Lower priority numbers are preferred. Example: example.com IN MX 10 mail.example.com. The TXT (Text) record stores arbitrary text, often for verification (SPF, DKIM, DMARC) or domain ownership validation. The PTR (Pointer) record is used for reverse DNS lookup, mapping an IP address to a domain name, crucial for email authentication and logging.

Other record types appear in advanced exams. The SRV (Service) record specifies service-specific servers, like for SIP or LDAP. The SOA record's TTL fields are regularly tested. Network+ and CCNA exams may ask which record type is used for a specific purpose, such as directing email traffic (MX) or providing redundancy (multiple A records). AWS-SAA may test Route 53 alias records, which function like CNAME but work at the zone apex. Understanding these records is vital for configuring any network service.

## DNS Security Threats and Mitigations

DNS is a critical infrastructure but also a frequent attack vector. Exams like Security+, Network+, and Azure AZ-104 test knowledge of common DNS threats and how to defend against them. The goal is to understand both the attack mechanism and the preventive controls.

One of the most dangerous threats is DNS Spoofing (also called DNS Cache Poisoning). An attacker injects false DNS records into the cache of a recursive resolver. When a user queries a legitimate domain, the resolver returns a fraudulent IP address, redirecting the user to a malicious site. This can lead to credential theft or malware installation. Mitigation requires using DNS Security Extensions (DNSSEC), which digitally signs DNS records. DNSSEC ensures that responses are authentic and have not been tampered with. However, DNSSEC does not encrypt the query, so it does not provide privacy.

Another prevalent attack is DNS Tunneling. Attackers encapsulate non-DNS traffic (like HTTP or SSH) within DNS queries and responses. Since DNS traffic is often allowed through firewalls, this can be used to exfiltrate data or establish command-and-control channels. Defenses include implementing deep packet inspection, restricting DNS queries to known resolvers, and monitoring for unusually large or frequent DNS queries.

DNS Amplification is a form of Distributed Denial of Service (DDoS) attack. An attacker sends small DNS queries with a spoofed source IP (the victim's address) to open resolvers. The resolver sends a large response (often many times larger than the query) to the victim, overwhelming their network. Mitigation involves disabling open recursion on authoritative servers, using rate limiting, and deploying anti-spoofing measures like BCP 38 (ingress filtering).

NXDOMAIN attacks flood a resolver with queries for non-existent domains, causing resource exhaustion and legitimate requests to be dropped. This is countered by using aggressive caching of NXDOMAIN responses as per RFC 2308. DNS hijacking occurs when an attacker gains control of a domain registrar account and changes the NS records to point to their name servers, effectively taking over the domain. Two-factor authentication and monitoring for unauthorized changes are essential.

Finally, DNS over HTTPS (DoH) and DNS over TLS (DoT) encrypt the query path, preventing eavesdropping and manipulation. However, they can bypass corporate security controls. Exam questions often ask about the difference between these protocols and when to use them. Understanding these threats and their mitigations is critical for securing any network.

## DNS in Cloud: AWS Route 53, Azure DNS, and Google Cloud DNS

Cloud providers offer managed DNS services that integrate with their ecosystem. For cloud-focused exams like AWS-SAA, AZ-104, and Google ACE, understanding how DNS works in these environments is crucial for designing resilient, high-performance architectures. Each service has unique features but shares core DNS concepts.

AWS Route 53 is a highly available and scalable DNS service. It supports standard record types (A, AAAA, CNAME, MX, etc.) and advanced features like alias records. Alias records are unique because they can map a zone apex (e.g., example.com) to AWS resources (ELB, CloudFront, S3 bucket) without the typical CNAME restriction at the apex. Route 53 offers routing policies: Simple (one record), Weighted (distribute traffic by weight), Latency (route to lowest latency region), Geolocation (route based on user location), Failover (active-passive), and Multivalue Answer (return multiple healthy IPs). Health checks verify endpoint availability; if a resource is unhealthy, Route 53 stops returning its IP. Route 53 also provides Domain Registration and DNSSEC support. Exam scenarios often involve routing based on latency or geolocation for global applications.

Azure DNS provides domain hosting and resolution using Azure's global infrastructure. It supports integration with Azure Private DNS zones for internal name resolution (e.g., resolving VM names within a virtual network). Azure DNS also offers alias records (similar to AWS) for pointing to Azure resources like Front Door, Traffic Manager, or Azure CDN. Azure Traffic Manager is a DNS-based traffic load balancer that uses different routing methods: Performance (like latency), Priority (failover), Weighted, and Geographic. Unlike Route 53, Traffic Manager operates at the DNS level and does not use health checks directly on endpoints but relies on probes. Azure DNS Private Resolver allows custom DNS resolution for hybrid networks.

Google Cloud DNS offers similar capabilities: managed authoritative DNS, high availability, and integration with Cloud Load Balancing. It supports DNSSEC, Cloud Logging for audit trails, and Private DNS zones for internal networks. Google's routing policies include Geo, Weighted, and Failover. A unique feature is that Google Cloud DNS can be used with Cloud CDN and HTTP(S) Load Balancers.

All three services are managed, meaning they handle redundancy and DNS scaling automatically. Common exam topics include: when to use a routing policy, how TTL affects failover time, and the difference between DNS-based load balancing and application-level load balancing. For example, a low TTL speeds up failover but increases query load on the DNS server. Cloud architects must balance performance, cost, and availability when designing DNS strategies.

## Common mistakes

- **Mistake:** Thinking DNS is only about resolving domain names to IP addresses.
  - Why it is wrong: DNS also supports many other resource record types such as MX for mail exchange, CNAME for aliases, TXT for verification and security, PTR for reverse lookups, and SRV for service discovery. Ignoring these record types leads to incomplete troubleshooting.
  - Fix: Study the most common record types and understand their specific purposes. Remember that each record type solves a different naming problem on the network.
- **Mistake:** Confusing the roles of recursive resolvers and authoritative name servers.
  - Why it is wrong: A recursive resolver (like 8.8.8.8) does the work of finding the answer for the client. An authoritative name server holds the actual records for a domain. They are not the same, and misidentifying which one is failing leads to incorrect troubleshooting steps.
  - Fix: Remember: recursive resolvers ask questions up the chain. Authoritative servers provide the final answers. If a resolver cannot reach an authoritative server, the domain fails to resolve.
- **Mistake:** Believing that changing a DNS record takes effect immediately everywhere.
  - Why it is wrong: DNS records have a TTL that tells caching resolvers how long to keep a record. Changes can take up to the TTL duration to propagate. If you reduce the TTL before a planned change, propagation speeds up, but you cannot force immediate global update.
  - Fix: Always lower the TTL value to a small number (e.g., 60 seconds) at least 24 hours before making a change. After the change, verify the new record and then restore a normal TTL.
- **Mistake:** Assuming that DNS is always an internet service, not used internally.
  - Why it is wrong: Internal networks, including Active Directory domains and private cloud environments, rely heavily on DNS to resolve local server names and services. Misconfiguring internal DNS can break file sharing, authentication, and application connectivity.
  - Fix: Configure internal DNS servers or private hosted zones for your internal domain. Use conditional forwarding or split-brain DNS to differentiate internal and external resolution.
- **Mistake:** Ignoring security considerations like DNSSEC and resolver restrictions.
  - Why it is wrong: DNS is a common attack vector. Without DNSSEC, an attacker can forge DNS responses. Without restricting which clients can use a resolver, you open the door to amplification attacks. Many exams test these security aspects.
  - Fix: Implement DNSSEC for domains you manage. Configure access control lists on resolvers to allow only authorized clients. Monitor DNS traffic for anomalies.
- **Mistake:** Forgetting that DNS uses both UDP and TCP on port 53, but for different purposes.
  - Why it is wrong: Standard queries use UDP. If the response is too large, the resolver will switch to TCP. Zone transfers always use TCP. Some exam questions ask why a zone transfer fails, the answer is often a firewall blocking TCP port 53.
  - Fix: Remember: UDP for fast lookups, TCP for large responses and zone transfers. Ensure both protocols are permitted through firewalls if you have DNS servers exchanging zone data.

## Exam trap

{"trap":"A question states: 'A user types www.example.com and gets an IP address that belongs to a different domain. The network administrator has verified that the A record on the authoritative server is correct. What is the most likely cause?' The wrong answer choices often include 'incorrect subnet mask' or 'DHCP server failure'.","why_learners_choose_it":"Learners often focus on the client side and think the problem is local, so they pick a network configuration issue. They forget that DNS caching can return stale or poisoned data from a resolver.","how_to_avoid_it":"If the authoritative server has the correct record but the user gets a wrong IP, the problem is almost certainly on the resolver side or in the client's DNS cache. The most common cause is a poisoned or stale cache. Always look for options like 'DNS cache poisoning' or 'outdated TTL in caching resolver' as the answer."}

## Commonly confused with

- **DNS vs DHCP:** DHCP assigns IP addresses and other network configuration to devices automatically. DNS resolves domain names to IP addresses. DHCP can hand out the DNS server address, but DHCP itself does not perform name resolution. (Example: When you connect to a new Wi-Fi network, DHCP gives your computer an IP address and also tells it which DNS server to use. The DNS server then handles name lookups.)
- **DNS vs IP Address:** An IP address is the actual numeric label that identifies a device on a network. DNS is a service that translates human-readable names into those IP addresses. They are not interchangeable. (Example: Google.com is a name, and 8.8.8.8 is an IP address. DNS maps the name to the IP. Without DNS, you would have to type 8.8.8.8 to reach Google's DNS server.)
- **DNS vs Proxy Server:** A proxy server handles requests on behalf of clients, usually for caching, anonymity, or content filtering. DNS only resolves names to addresses; it does not forward or modify the actual data traffic between the client and the server. (Example: A proxy can be configured to block certain websites. DNS can block access by refusing to resolve the name, but the proxy actually sits between the client and the web server, intercepting the traffic.)
- **DNS vs VPN:** A VPN creates an encrypted tunnel for all traffic between a device and a remote network. DNS queries often go through this tunnel, but DNS itself is a separate protocol. Some VPNs change your DNS resolver to one controlled by the VPN provider to avoid leaks. (Example: When you connect to a VPN, your computer might start using the VPN's DNS server instead of your local one, so you can resolve names in that remote network.)
- **DNS vs Hosts File:** The hosts file is a local text file on a computer that maps hostnames to IP addresses. It takes precedence over DNS. DNS is a network service that provides the same function but is centralized and scalable across the internet. (Example: You can manually add an entry in the hosts file to override a DNS resolution. For example, you might block a website by pointing its name to 127.0.0.1.)

## Step-by-step breakdown

1. **User enters a domain name** — The user types a URL like www.example.com into a browser and presses Enter. The application (browser) calls a system library called the stub resolver with that domain name.
2. **Stub resolver checks local cache** — The stub resolver first looks in the operating system's DNS cache for the answer. If the name was resolved recently, the cached IP address is returned immediately, saving time. This is why clearing the cache (ipconfig /flushdns) sometimes fixes stale resolution problems.
3. **Check hosts file** — Before sending a network query, the stub resolver also checks the local hosts file. Entries in this file override any DNS server responses. This feature is sometimes used for local overrides or to block malicious domains by pointing them to 127.0.0.1.
4. **Recursive query sent to DNS resolver** — If the answer is not cached and not in the hosts file, the stub resolver sends a recursive query to the DNS resolver configured on the network adapter (often automatically assigned by DHCP). The resolver is responsible for finding the final answer.
5. **Resolver queries root name server** — The resolver starts the iterative process by contacting one of the 13 root name servers. The root server does not know the exact IP but knows which TLD server (e.g., for .com) can help. It responds with the list of TLD name servers for the domain's extension.
6. **Resolver queries TLD name server** — The resolver then asks the TLD server (like .com) for information about the domain. The TLD server replies with the names of the authoritative name servers for example.com. This step narrows the search to the specific domain's DNS management.
7. **Resolver queries authoritative name server** — The resolver contacts one of the domain's authoritative name servers and asks for the record for www.example.com. The authoritative server responds with the IP address and the TTL value. This is the actual answer the resolver was looking for.
8. **Resolver caches and returns the answer** — The resolver stores the response in its cache for the duration specified by the TTL. It then sends the IP address back to the stub resolver, which also caches it. The application receives the IP address and can now initiate a connection to the server.
9. **Browser connects to the IP address** — Using the received IP address, the browser opens a TCP connection on port 80 (HTTP) or 443 (HTTPS) and requests the web page. The DNS resolution is complete, and the content loads for the user.

## Practical mini-lesson

One of the most important skills for any IT professional is being able to diagnose and fix DNS problems. Let's go deeper into what you really need to know in practice. First, understand the difference between public and private DNS. Public DNS is what everyone uses on the internet, servers like 8.8.8.8 or 1.1.1.1. Private DNS operates inside your corporate network. For example, in a Windows environment, Active Directory (AD) relies heavily on DNS. If your internal DNS is misconfigured, domain controllers may not replicate, clients may not authenticate, and group policy may not apply. In a cloud environment, private DNS zones allow resources in a Virtual Private Cloud (VPC) to resolve internal names without leaving the network.

Consider configuring DNS on a typical network. When you set up a new server, you will usually assign it a static IP address and specify the DNS server addresses manually. The primary DNS server is the one your host queries first. The secondary is a fallback. If your primary fails, the secondary should still resolve names. However, if the DNS servers are reachable but not functioning correctly (e.g., returning incorrect results), a fallback won't help. That's why monitoring DNS service health is crucial. Many network monitoring tools perform regular DNS lookups to ensure the service is responding correctly.

Troubleshooting DNS problems systematically is a skill. Start by seeing if the problem affects one client or many. On a Windows client, run ipconfig /displaydns to see cached entries. If you suspect a stale cache, run ipconfig /flushdns. Then try nslookup or dig to isolate. If nslookup fails for all domains, the resolver itself is likely unreachable or misconfigured. If it works for some domains but not others, the issue is with the specific domain's authoritative servers. If it works on one client but not another, check the DNS server settings on the failing client. Also, verify that the client is actually sending queries to the correct DNS server, sometimes DHCP settings get overwritten manually.

A common real-world scenario is split-brain DNS. A company wants its external users to see a public website, but internal users should see the same website but hosted on an internal server for performance and security. To achieve this, you configure the public DNS zone on the external DNS server to resolve www.example.com to the public IP. The internal DNS server has a private zone for example.com that resolves www.example.com to the internal IP of the web server. Internal users query their own DNS server (which holds the private zone) and get the internal IP. External users query public resolvers and get the public IP. If you forget to create the internal zone, internal users will get the public IP, which may not be reachable inside the network. This is a classic configuration mistake.

What can go wrong with DNS? Records can be accidentally deleted or misconfigured. TTL values set too high cause slow propagation (and slow failover). Too low TTL increases query traffic to the authoritative server. DNSSEC misconfigurations can make a domain entirely unresolvable because the signature on the record is invalid. Firewalls blocking port 53 (UDP or TCP) will stop resolution. DNS resolvers can be overloaded by traffic and drop queries. An attacker could poison the cache of a public resolver, causing users to be redirected to malicious sites. These are not just exam scenarios, they happen in production networks every day.

For cloud professionals, the practical aspects include understanding how to use Route 53 health checks with failover routing policies. If your primary web server goes down, Route 53 can automatically return the IP of your backup server. But this only works if health checks are properly configured and TTL is low enough that clients re-query quickly. Similarly, in Azure, you can use Traffic Manager with Azure DNS to distribute traffic and respond to failures. Knowing these services and how they interact with DNS is what separates a theoretical understanding from a practical, exam-ready one.

## Commands

```
nslookup www.example.com
```
Queries the default DNS resolver for the IP address of www.example.com. Used for basic troubleshooting of name resolution.

*Exam note: Exams test that nslookup uses the system's configured DNS server and can query different record types with -type=MX. Common for Network+ and A+.*

```
dig +trace www.example.com
```
Performs a full iterative DNS resolution from root servers down to authoritative servers. Useful for identifying where a resolution fails.

*Exam note: The +trace flag is often tested in CCNA and Network+ for understanding the complete DNS hierarchy. Shows root, TLD, and authoritative responses.*

```
dig @8.8.8.8 example.com MX
```
Queries Google's public DNS server (8.8.8.8) for the MX records of example.com. Verifies mail server configuration.

*Exam note: Security+ and Network+ exams may ask how to check mail server records using dig with a specific type. The @ specifies the resolver.*

```
host -t A www.example.com
```
Simpler alternative to dig for looking up an A record. Often faster for basic queries.

*Exam note: Linux+ and A+ exams might present host as a lightweight tool. Know the -t flag for record types and -a for all types.*

```
ipconfig /flushdns
```
Clears the local DNS cache on Windows. Used when stale DNS entries cause resolution errors.

*Exam note: A+ and Network+ frequently test that clearing cache resolves issues from recent DNS changes. Equivalent on Linux is systemd-resolve --flush-caches.*

```
dig +short www.example.com ANY
```
Returns a short, concise answer for all record types. Useful for quick diagnostics but note that ANY queries are being deprecated.

*Exam note: Security+ may ask about the risks of ANY queries (amplification) and why they are disabled on modern resolvers. Also tests understanding of query types.*

```
systemd-resolve --statistics
```
Shows DNS cache statistics on Linux systems using systemd-resolved. Helps monitor cache efficiency and misses.

*Exam note: Linux+ and Azure-related exams may test knowledge of systemd-resolved. Similar to checking cache on Windows with ipconfig /displaydns.*

## Troubleshooting clues

- **DNS Resolution Failure (Server Not Found)** — symptom: Browser displays 'Server not found' or ping returns 'ping: unknown host'. DNS lookup times out.. This occurs when the recursive resolver cannot reach an authoritative server or the domain does not exist. Root causes include incorrect DNS server configuration on the client, network connectivity issues to the DNS server, or the domain has expired or is not delegated. (Exam clue: Exams present scenarios where a client's DNS is set to an unreachable IP. The correct step is to check the network adapter settings or run 'nslookup' to see which server is being used.)
- **Stale DNS Cache (Incorrect IP)** — symptom: Website loads an old version or points to the wrong server even after DNS records were updated hours ago.. The local DNS cache or recursive resolver's cache still holds the old record with a TTL that has not expired. The TTL determines how long a record is cached. Until it expires, the old IP is served. (Exam clue: Network+ and A+ ask: What is the quickest way to resolve a stale cache? Answer: flush the local DNS cache (ipconfig /flushdns) or wait for TTL to expire. Tests understanding of TTL.)
- **DNS Redirect to Spoofed Site (Possible Poisoning)** — symptom: User is redirected to a phishing page when typing a legitimate URL. The IP address returned by nslookup is different from the known legitimate IP.. An attacker has poisoned the DNS cache by inserting fraudulent records. This can happen if the resolver accepts non-authoritative responses or is vulnerable to cache poisoning attacks. (Exam clue: Security+ exam tests: What technology prevents DNS cache poisoning? Answer: DNSSEC. Also, what should you clear? The local and resolver cache.)
- **DNS Timeout (Slow Resolution)** — symptom: Web pages load very slowly; first connection takes 5-10 seconds. After initial load, subsequent pages load fine.. The client's DNS resolver is timing out and retrying. This often happens if the primary DNS server is unreachable and the client waits for the time-out before trying the secondary server. High latency or packet loss to the DNS server is a common cause. (Exam clue: CCNA and Network+ questions: What command tests DNS server availability? 'nslookup' with a specific server IP. Also check firewall rules for UDP port 53.)
- **MX Record Not Found (Email Delivery Failure)** — symptom: Emails to a domain bounce with 'DNS lookup failed' or 'No MX record found'. Sending server cannot deliver mail.. The domain's zone file lacks an MX record, or the MX record points to a non-existent or unreachable mail server. This can also occur if the domain's NS records are misconfigured. (Exam clue: Security+ and Azure exams may test that MX records are required for email. Use 'dig MX' to verify. Also check that the MX record's target has an A record.)
- **CNAME Record Conflict (Coexistence Issue)** — symptom: Adding a CNAME record for a subdomain causes other record types (like MX or NS) to stop working for that subdomain.. According to RFC, a CNAME record cannot coexist with any other record type at the same node. If you have an MX record for 'mail.example.com', you cannot also have a CNAME for 'mail.example.com'. The CNAME must be for a different name. (Exam clue: Network+ and AWS-SAA exams ask: What record type can coexist with a CNAME? Answer: None; CNAME takes precedence. The fix is to use an A record or an alias record instead.)
- **Zone Transfer Failure (Authoritative Server Sync)** — symptom: Secondary DNS server shows old records or no records at all. Reports 'zone transfer failed' in logs.. Zone transfers (AXFR or IXFR) use TCP port 53. Failures occur if the primary server's configuration does not allow transfers to the secondary's IP, or if a firewall blocks TCP 53. Also, the serial number must be higher on the primary. (Exam clue: CCNA and Network+ test: What port and protocol does zone transfer use? TCP 53. What must be configured on the primary? Allow-transfer list. What number must be incremented? Serial number.)

## Memory tip

Think of DNS as the phonebook for the internet: it matches names (like a contact name) to numbers (like phone numbers). The name is the domain, the number is the IP address.

## FAQ

**What is the difference between recursive and iterative DNS queries?**

A recursive query asks the DNS resolver to find the answer completely, even if it requires multiple queries to other servers. The resolver does all the work. An iterative query gives the best answer it currently has without asking other servers. Recursive queries are used by clients; iterative queries are used between resolvers.

**Why does my DNS change sometimes take hours to work everywhere?**

Because of DNS caching. Each record has a TTL (Time to Live) value that tells caching resolvers how long to keep the record. If the old TTL was set high (e.g., 86400 seconds = 24 hours), all resolvers that cached the old record will continue to use it until the TTL expires. You cannot force a global cache flush.

**What is a DNS zone transfer and why is it important?**

A zone transfer is the process by which secondary DNS servers replicate zone data from a primary authoritative server. This ensures redundancy. Zone transfers use TCP port 53. If you secure your DNS infrastructure, you should restrict zone transfers to authorized secondary servers.

**What does 'DNS server not responding' mean?**

It means that the DNS resolver your computer is configured to use did not respond to the query within the timeout period. This could be because the resolver is down, the network path is blocked (firewall or routing issue), or your computer's DNS configuration is wrong.

**How do I clear the DNS cache on Windows and macOS?**

On Windows, open Command Prompt as administrator and run 'ipconfig /flushdns'. On macOS, run 'sudo dscacheutil -flushcache' and 'sudo killall -HUP mDNSResponder'. Clearing the cache forces the system to query the resolver again for fresh results.

**What is the difference between A and AAAA records?**

An A record maps a domain name to an IPv4 address. An AAAA record maps a domain name to an IPv6 address. They serve the same purpose but for different IP protocol versions.

**What is DNSSEC and why should I use it?**

DNSSEC adds a layer of security by digitally signing DNS response records. This helps prevent attacks like cache poisoning, where an attacker forges a DNS response to redirect users to a malicious website. It ensures that the response actually comes from the authoritative server and hasn't been tampered with.

---

Practice questions and the full interactive page: https://courseiva.com/glossary/dns