CCNA online course

Domain Name System (DNS) Fundamentals for CCNA

Learn DNS hierarchy, records, resolution, caching, transport, Cisco IOS configuration, and practical DNS troubleshooting for CCNA.

Domain Name System (DNS) is the distributed service that translates human-readable names into IP addresses and stores other information about network services. DNS lets users and applications connect to resources such as intranet.example.com without memorizing an IPv4 or IPv6 address.

This lesson covers DNS architecture, records, queries, caching, transport, enterprise configuration, Cisco IOS operation, security basics, and a methodical troubleshooting process.

DNS Purpose and Role

A hostname is a human-readable name assigned to a networked device or service. An application could connect directly to an address such as 192.0.2.25, but names are easier to remember and can remain stable when the underlying server address changes.

DNS is a distributed, hierarchical naming system. Information is divided among many servers and organized into levels. This design avoids one central database and allows different organizations to administer their own namespaces.

• Forward lookup: resolves a hostname to an IP address, commonly using an A record for IPv4 or an AAAA record for IPv6.
• Reverse lookup: resolves an IP address to a hostname, commonly using a PTR record.
• Service discovery: records such as MX and SRV identify mail and application services.

DNS is used by workstations, servers, web browsers, email systems, routers, switches, monitoring platforms, automation tools, and network-management applications. A router may resolve a hostname in a ping or SSH command, while a monitoring system may use DNS to locate a managed device.

DNS, DHCP, and Host Files

DHCP does not normally resolve names. Instead, DHCP can tell a client which DNS servers to use. A hosts file can override or supplement DNS locally, but it does not provide a distributed naming service.

DNS Namespace and Hierarchy

An FQDN, or fully qualified domain name, is a complete name within the DNS hierarchy. In www.sales.example.com, the labels are read from right to left:

• The empty label at the far right represents the root domain.
• com is the top-level domain, or TLD.
• example is a second-level domain.
• sales is a delegated or administratively distinct subdomain.
• www identifies a host or service within that namespace.

A trailing dot can show the root explicitly: www.sales.example.com. Most user interfaces omit the trailing dot.

Domains, Zones, and Delegation

A domain is a portion of the namespace administered under a common naming structure. A zone is the portion of the namespace for which a DNS server holds authoritative data. A domain and a zone can have the same name, but they are not identical concepts.

A zone can delegate a subdomain to other authoritative servers. For example, the administrators of example.com can delegate research.example.com by publishing NS records that identify the servers responsible for that subdomain. The parent zone retains the delegation, while the child zone contains its own authoritative records.

Public DNS zones are reachable through the public DNS hierarchy. Private internal namespaces are administered inside an organization and may contain names and private addresses that should not be exposed publicly. Some organizations use a subdomain of a registered name, such as corp.example.com, for internal services.

FQDN Example

For fileserver.it.example.com, com is the TLD, example is the organizational domain, it is a subdomain, and fileserver is the host label. The complete name is the FQDN.

DNS Server Roles

A primary authoritative server holds the writable source of zone data in a traditional primary-secondary design. A secondary authoritative server obtains a read-only copy through zone transfer. Both can answer authoritatively, improving availability.

A conditional forwarder sends queries for a particular namespace to designated servers. For example, an enterprise resolver might forward partner.example queries to a partner DNS server while using another forwarder for Internet names.

DNS Name-Resolution Process

1. An application asks the local stub resolver for a name such as intranet.example.com.
2. The stub resolver checks local information, including its cache and possibly a hosts file.
3. If no usable local answer exists, it sends a query to the configured recursive resolver.
4. The recursive resolver checks its cache. A valid cached answer is a cache hit and can be returned immediately.
5. For a cache miss, the resolver may ask a root server. The root server returns a referral to the appropriate TLD servers.
6. The resolver asks a TLD server, which returns a referral to the authoritative servers for the target domain.
7. The resolver asks an authoritative server and receives the requested resource record or a negative response.
8. The recursive resolver caches the result for the permitted TTL and returns the answer to the client.

A recursive query expects the queried resolver to return a final answer or an error. An iterative query permits a server to return the best information it has, such as a referral to another server. A stub resolver normally makes a recursive request to its configured resolver, while that resolver commonly uses iterative queries toward root, TLD, and authoritative servers.

A negative response indicates that the requested name or record does not exist, or that the server cannot provide the requested type. Negative answers can also be cached for a limited period. Consequently, adding a newly missing record may not appear immediately to every client.

If DNS is unavailable, a user may be unable to open a resource by name even when routing and the destination server are functioning. Direct IP access can work while web browsing, SSH, email, monitoring, or automation by hostname fails.

Common DNS Resource Records

A resource record is one DNS data entry. Records generally contain a name, type, value, and TTL. Some types also contain priorities, weights, ports, or other fields.

MX records include a preference value; lower values are generally preferred. SRV records use priority, weight, port, and target fields. A CNAME points to another name rather than directly to an address, so the resolver may need an additional lookup.

Zones and Zone Data

A forward lookup zone contains records used to resolve names to addresses or services. A reverse lookup zone contains PTR records used to resolve addresses to names.

Zone data is commonly stored in a zone file or equivalent database. An SOA record includes the primary name server, an administrative contact representation, a serial number, and timing values used by secondary servers. The serial number must change when zone data changes so secondary servers know that synchronization is needed.

Zone transfer is the process by which a secondary server obtains zone data from a primary or another permitted source. Access should be restricted to authorized secondary servers. NS records support delegation by identifying the servers responsible for a zone or child zone.

Split-Horizon DNS

Split-horizon DNS, also called split-view DNS, returns different answers based on the client or query path. For example, internal users may receive a private address for portal.example.com, while external users receive a public address. This can keep internal traffic inside the enterprise and avoid exposing private addresses.

Caching and TTL Behavior

A caching resolver stores DNS answers for the duration specified by their TTL, or time to live. Caching reduces lookup latency and external DNS traffic. It also reduces the number of queries sent to authoritative servers.

There can be several caches: an application cache, an operating-system client cache, a local network resolver cache, and additional upstream caches. When a record changes, different users may receive different answers until their cached values expire.

For example, if a web server moves from 192.0.2.25 to 192.0.2.50, a resolver that cached the old A record may continue returning 192.0.2.25 until the TTL expires. Clearing the client cache removes one local copy, but it does not remove the record from upstream resolver caches.

During troubleshooting, inspect the returned TTL, query more than one resolver, and compare results with an authoritative server when possible. Negative caching can also delay the visibility of a newly created record.

DNS Transport and Network Requirements

Most ordinary DNS exchanges use UDP port 53. TCP port 53 is used for zone transfers and may be used when a response is too large for the original UDP exchange. A truncated UDP response can signal the resolver to retry using TCP.

The client must have IP connectivity to its configured DNS server over IPv4 or IPv6, as appropriate. Routing, default gateways, firewalls, and ACLs must permit DNS traffic. Configuring an unreachable resolver address is functionally similar to having no DNS service.

Enterprise DNS Configuration

An enterprise can provide DNS server addresses manually or through DHCP. DHCP is usually preferred for large client populations because a change can be distributed centrally. Internal resolvers can answer private names, apply policy, cache Internet results, and forward selected namespaces.

Public resolvers may be suitable for Internet-only clients, but they generally cannot resolve private internal names. Internal clients often need enterprise resolvers, while external services use public authoritative servers. Security policy should determine which resolver addresses clients are allowed to use.

Cisco IOS DNS Configuration

Cisco IOS can resolve hostnames for management-plane commands such as ping, traceroute, SSH, and Telnet. The following configuration enables lookup, sets a domain name, and defines two resolver addresses:

configure terminal
ip domain lookup
ip domain name example.com
ip name-server 192.0.2.53
ip name-server 198.51.100.53
end

The domain name provides a local DNS suffix and is also relevant to some device identity and management functions. The configured name servers are tried when IOS needs to resolve a hostname.

A static host mapping is useful for a small number of stable devices or when DNS is unavailable:

configure terminal
ip host fileserver 192.0.2.25
ip host web01 192.0.2.26
end

Static mappings are local to that IOS device. They do not replace enterprise DNS for a large or frequently changing network.

Disabling Unwanted IOS Lookups

When an administrator enters an invalid IOS command, the device may interpret the text as a hostname and attempt DNS resolution. If no resolver responds, the CLI can pause while the lookup times out. On devices where CLI hostname resolution is not needed, disable it:

configure terminal
no ip domain lookup
end

With lookup disabled, hostname-based commands such as ping hostname may not work unless the name is supplied through a static mapping or lookup is enabled again. This is a usability choice, not a replacement for securing DNS.

Verify Cisco IOS Settings

show running-config | include ip domain|ip name-server|ip host
ping hostname
traceroute hostname

Confirm that the resolver addresses are correct and reachable. Test both a static mapping and a DNS-resolved name when diagnosing the source of a failure.

DNS Security and Reliability Basics

• Use redundancy: provide more than one reachable DNS server. A single failed resolver can make name-based access appear to be a broad network outage.
• Restrict zone transfers: allow transfers only to authorized secondary servers.
• Control access: use ACLs and firewall policy to limit who can query or administer internal DNS services.
• Understand spoofing and cache poisoning: an attacker may attempt to provide false DNS data or insert false answers into a cache.
• Know DNSSEC: DNS Security Extensions provide origin authentication and integrity validation for signed DNS data. DNSSEC does not encrypt ordinary DNS queries.
• Monitor service health: track DNS availability, response time, failures, and differences between redundant servers.

Reliability depends on both server redundancy and correct client configuration. Two DNS addresses are not useful if both are behind the same failed path or if both contain inconsistent zone data.

DNS Troubleshooting Methodology

1. Confirm the client has a valid IP address, subnet mask or prefix, default gateway, and basic connectivity.
2. Inspect the DNS server addresses supplied by DHCP or configured manually.
3. Test reachability to the configured DNS server. Remember that a successful ping alone does not prove that UDP or TCP port 53 is permitted.
4. Resolve a known-good hostname and compare the result with direct IP access.
5. Query a specific DNS server instead of relying only on the operating system's default resolver.
6. Inspect the returned record type, address, response status, and TTL.
7. Compare answers from the local resolver, another trusted resolver, and authoritative servers when appropriate.
8. Check firewall rules, ACLs, routing, NAT behavior, and UDP/TCP port 53 reachability.
9. Determine whether the problem is a client cache, resolver cache, forwarding issue, incorrect zone data, missing record, stale record, or unreachable authoritative server.

Client Query Examples

On Windows, inspect the DNS settings and query the default or a specified resolver:

ipconfig /all
nslookup example.com
nslookup example.com 192.0.2.53
ipconfig /flushdns

On Linux or macOS, inspect resolver configuration and perform forward or reverse queries:

cat /etc/resolv.conf
dig example.com
dig @192.0.2.53 example.com
dig -x 192.0.2.25
nslookup example.com

Querying a specific resolver separates a local client problem from a server or delegation problem. Clearing the client cache is useful, but it cannot correct an incorrect authoritative record or a stale upstream cache that has not reached its TTL.

Common Diagnostic Patterns

IP works, hostname fails: verify configured DNS addresses, query the name directly, check A and AAAA records, and inspect firewall or ACL rules. If the direct query succeeds but the application still fails, investigate the local cache or application behavior.

An old address remains after migration: inspect the answer TTL, query authoritative servers directly, compare internal and external answers, and verify that primary-secondary synchronization occurred and the SOA serial increased.

Internal users receive an unreachable public address: compare the internal resolver's answer with an external resolver's answer. Verify split-horizon zones, forwarding policy, and internal A or AAAA records.

Forward lookup succeeds but reverse lookup fails: check for a PTR record, verify the relevant in-addr.arpa or ip6.arpa reverse zone, and confirm that the organization controls or has been delegated the reverse namespace.

Exam-Relevant Notes

• DNS normally uses UDP port 53, but TCP port 53 is important for zone transfers and large or truncated responses.
• A records map names to IPv4 addresses; AAAA records map names to IPv6 addresses; PTR records support reverse lookups.
• A recursive query expects a final answer, while an iterative query can return a referral.
• Authoritative servers provide official zone data. Caching resolvers temporarily store answers according to TTL.
• NS records identify authoritative name servers. SOA records contain zone authority information and the serial number used for synchronization.
• DNS and DHCP have different roles: DHCP supplies configuration, while DNS resolves names.
• no ip domain lookup prevents IOS from attempting DNS resolution for mistyped CLI input.
• DNS failure can prevent access by hostname even when IP connectivity to the destination is working.

DNS is therefore both a naming service and a dependency for many network operations. Understanding hierarchy, query behavior, records, caching, transport, and resolver configuration makes DNS failures much easier to isolate.