CCNA online course

Mapping Hostnames to IP Addresses: DNS and Hostname Resolution

Learn how DNS, hosts files, and Cisco IOS map hostnames to IPv4 and IPv6 addresses, including lookups, caching, configuration, and troubleshooting.

Why Hostnames Must Be Mapped to IP Addresses

People prefer readable names such as web01.example.com because names are easier to remember than numerical addresses. Network protocols, however, use IP addresses to identify the source and destination of packets. Before an application can normally connect to a named service, a resolver must translate the name into one or more IP addresses.

A hostname is a human-readable label assigned to a host or network device, such as router1. A domain name is a name in the hierarchical DNS namespace, such as example.com. A fully qualified domain name (FQDN) contains the complete name from the host label through the domain hierarchy, such as web01.example.com. An IP address is the IPv4 or IPv6 address used for packet forwarding, such as 192.0.2.25 or 2001:db8:100::25.

Name resolution is part of application connectivity, not a replacement for routing. If DNS fails, a client may still reach a service by entering its IP address directly. If the name resolves successfully but the route, firewall, or service is unavailable, the application can still fail.

DNS Fundamentals

The Domain Name System (DNS) is a distributed naming system. Instead of storing every name in one database, DNS divides responsibility among administrative portions called zones and uses a hierarchy of servers.

• DNS client: Software on an endpoint or network device that requests name resolution.
• Recursive resolver: A DNS server that obtains an answer for a client. It checks its cache and, when necessary, queries other DNS servers.
• Authoritative name server: A server that holds the official records for a DNS zone.
• Root servers: Servers at the top of the DNS hierarchy. They direct resolvers to the appropriate top-level-domain servers.
• Top-level-domain (TLD) servers: Servers responsible for extensions such as .com, .org, or country-code TLDs. They direct resolvers toward the authoritative servers for a domain.
• Zone servers: Authoritative servers that publish records for a particular administrative zone.

A forward lookup resolves a hostname or FQDN to an IP address. A reverse lookup resolves an IP address to a name, normally by querying a PTR record in a reverse DNS zone.

DNS answers include a time to live (TTL). A resolver may cache an answer for the TTL period. Caching reduces lookup traffic and speeds up repeated requests, but it also means that a recently changed record may not be visible everywhere immediately. DNS can also cache negative results, such as a name that does not exist, for a period specified by the zone's policies.

The DNS Namespace and Domain Hierarchy

DNS names are hierarchical and are read from the most specific label on the left toward the root on the right. In www.sales.example.com, the labels are:

• Root: The unnamed top of DNS, commonly shown as a trailing dot.
• Top-level domain: com.
• Second-level domain: example.
• Subdomain: sales.
• Host label: www.

The complete name www.sales.example.com., including the optional final root dot, is an FQDN. It identifies a name at a specific place in the DNS hierarchy. In everyday configuration, the final dot is usually omitted, so www.sales.example.com is still treated as the FQDN.

A short name contains fewer labels, such as web01. A DNS search domain lets a resolver try a suffix automatically. If the search domain is example.com, a request for web01 may cause the resolver to try web01.example.com. Search behavior depends on the operating system and resolver configuration. Using an FQDN avoids ambiguity.

Common DNS Resource Records

A DNS zone contains resource records. Each record has a type that describes the relationship being published.

An A record supplies an IPv4 address, while an AAAA record supplies an IPv6 address. A CNAME is an alias, not an address. For example, portal.example.com can be a CNAME for web01.example.com; the canonical name must ultimately lead to address records such as A or AAAA.

Forward and reverse DNS are maintained independently. An A record for web01.example.com does not automatically guarantee a PTR record for its address.

Forward Hostname Resolution

When an application requests www.example.com, the following general sequence occurs:

1. The application asks the operating system's resolver for an address.
2. The resolver checks applicable local caches.
3. The operating system checks the local hosts file according to its configured name-service order.
4. If no usable local answer exists, the resolver sends a query to a configured DNS server.
5. The configured recursive resolver checks its cache. If the answer is absent or expired, it follows DNS referrals until it reaches an authoritative server.
6. The resolver returns a positive answer containing an A record, AAAA record, or both, and caches it according to its TTL.
7. The application selects an address and begins the actual connection to the destination service.

A recursive query asks the receiving DNS server to obtain the final answer on the client's behalf. A recursive resolver may use iterative queries between DNS servers: one server responds with the best referral it knows, and the resolver then queries the referred server. For an uncached lookup, the resolver can ask a root server, then a TLD server, and finally an authoritative server.

A positive response contains the requested data. NXDOMAIN means that the queried domain name does not exist. A response can also indicate that the name exists but has no requested record type. A SERVFAIL response means the server could not complete the lookup, often because of an upstream failure, DNSSEC validation problem, or an unavailable authoritative server. Timeouts indicate that no response was received within the retry period. Negative answers can be cached, so correcting a missing record may not immediately change every client's result.

Example: Web Service Lookup

A client requests www.example.com. The resolver may return an A record such as 198.51.100.20 and an AAAA record such as 2001:db8:100::20. The client then uses the selected IP address to establish the web connection. DNS does not carry the web traffic; it supplies information needed before that traffic begins.

Example: CNAME Alias

Suppose portal.example.com is a CNAME for web01.example.com, and web01.example.com has an A record for 192.0.2.25. The resolver follows the alias and returns the final address information. A reverse query for 192.0.2.25 may return web01.example.com only if a matching PTR record exists.

Local Static Hostname Mappings

A hosts file is a local text file containing static mappings. The usual structure is an IP address followed by a hostname and optional aliases:

192.0.2.50 app-lab.example.com app-lab

A local entry can be useful in a lab, during temporary testing before DNS is updated, or as an emergency override. For example, mapping app-lab.example.com to 192.0.2.50 allows a workstation to test a new server before the central DNS zone contains the record.

Local mappings have maintenance costs. They can become stale after a migration, differ between workstations, or conflict with production DNS. Resolution precedence is operating-system-specific, but commonly involves local static mappings and caches before configured DNS servers. Always verify the actual name-service order rather than assuming one universal sequence.

DNS Configuration on Hosts

An endpoint must know the IP address of at least one reachable DNS resolver. The resolver may be on the local subnet or on a remote subnet. If it is remote, the endpoint also needs a valid default gateway and routing path. The network must permit DNS traffic, normally UDP port 53 and, when required, TCP port 53.

Host configuration commonly includes DNS server addresses and one or more search suffixes. DHCP frequently supplies these values, although they can also be configured manually. Inspect both the DNS server list and the search domain when diagnosing short-name failures.

Windows Commands

ipconfig /all
nslookup www.example.com
nslookup -type=AAAA www.example.com
nslookup 192.0.2.25
ipconfig /displaydns
ipconfig /flushdns

Linux and macOS Commands

cat /etc/hosts
cat /etc/resolv.conf
dig www.example.com A
dig www.example.com AAAA
dig -x 192.0.2.25
dig @192.0.2.53 www.example.com
nslookup www.example.com

Resolver settings can also be managed by platform-specific services, so /etc/resolv.conf may be generated rather than edited permanently. Treat it as an inspection point unless the operating system documentation identifies it as the authoritative configuration file.

Cisco IOS Hostname Resolution

Cisco IOS can use DNS for names and can maintain a local static host table. The device needs a route to the DNS server and an appropriate source interface or IP configuration. The following example enables lookup, defines two DNS servers, sets a domain name, and adds a local mapping:

configure terminal
 ip domain lookup
 ip name-server 192.0.2.53
 ip name-server 192.0.2.54
 ip domain name example.com
 ip host web01 192.0.2.25
end
show hosts
ping web01
ping www.example.com

The ip domain name command supplies the device's domain name and can influence the construction of fully qualified names. Use an FQDN in tests when short-name behavior might be affected by search-domain rules.

When domain lookup is enabled, IOS may interpret an unrecognized command or mistyped word as a hostname and attempt DNS resolution. In a training lab or isolated environment, disable this behavior to avoid pauses:

configure terminal
 no ip domain lookup
end

DNS Resolution Versus ARP and Neighbor Discovery

DNS resolves an application name to an IP address. It does not resolve an IP address to an Ethernet destination in the same way as ARP or IPv6 Neighbor Discovery.

1. DNS: printer.example.com becomes 192.0.2.60.
2. Next-hop resolution: The client determines which local link-layer address should receive the frame.
3. Application traffic: The client sends packets toward the printer's IP address.

If the printer is on the local IPv4 subnet, the client uses ARP for 192.0.2.60. If the printer is on a remote subnet, the client uses ARP for the default gateway's IPv4 address, not for the printer's remote address. IPv6 uses Neighbor Discovery to resolve the local or next-hop IPv6 address to a link-layer address. A remote DNS server follows the same normal forwarding process: routing selects a next hop, and ARP or Neighbor Discovery resolves that next hop on the local link.

Verification and Troubleshooting

Use lookup tools to test the exact record type and resolver involved. A query through the normal client configuration tests the client path; a query directed at a particular server tests that server specifically. Check A, AAAA, PTR, CNAME, and authoritative-server information as appropriate.

nslookup www.example.com
nslookup -type=AAAA www.example.com
nslookup 192.0.2.25
dig www.example.com A
dig www.example.com AAAA
dig -x 192.0.2.25
dig @192.0.2.53 www.example.com
dig www.example.com NS
dig www.example.com SOA

Practical Diagnostic Path

1. Confirm the exact spelling and test the FQDN.
2. Inspect client DNS server addresses, search domains, default gateway, and routes.
3. Test reachability to the configured resolver.
4. Query the name with nslookup or dig, including the required A or AAAA type.
5. Compare the returned address with the expected service address.
6. Query a known resolver or the authoritative server where appropriate.
7. Check for UDP and TCP port 53 filtering.
8. Inspect the hosts file and local DNS cache for stale entries, then clear the cache for controlled testing.
9. For reverse failures, verify the reverse zone and PTR record separately from the forward zone.

If a client can reach an IP address but not the hostname, likely causes include an incorrect DNS server, missing A or AAAA record, a typographical error, or an unreachable resolver. If DNS returns an old address after a migration, check the authoritative record, its TTL, cached data, and local static entries.

Operational and Security Considerations

DNS availability and accuracy affect web access, email, authentication, monitoring, software updates, and many management tools. A resolver outage can make services appear unavailable even when the destination servers and routes are healthy.

Split-horizon DNS provides different answers to internal and external clients. For example, internal users might receive a private address for an application, while public users receive a public address. Troubleshooting must therefore identify which resolver and view supplied an answer.

DNS spoofing and cache poisoning attempt to make clients accept false DNS data. Use trusted resolvers, protect DNS infrastructure, monitor unexpected changes, and understand the role of DNSSEC, which provides validation of signed DNS data. DNSSEC does not encrypt ordinary DNS queries or automatically secure the application connection.

Public DNS zones should publish only the records required for public services. Unnecessary internal hostnames and private addressing details can reveal network structure and increase the information available to attackers.

Key Takeaways

• Applications commonly need name resolution before they can connect to a service by hostname.
• DNS is a distributed, hierarchical system using recursive resolvers and authoritative zones.
• A records map names to IPv4 addresses; AAAA records map names to IPv6 addresses; PTR records support reverse lookups.
• CNAME records provide aliases that ultimately resolve to address records.
• TTL-based caching improves performance but can preserve old or negative answers temporarily.
• Hosts files and Cisco IOS static host entries are local alternatives with limited scalability.
• DNS resolution occurs before ARP or Neighbor Discovery resolves the local next-hop link-layer address.
• When troubleshooting, check resolver configuration, gateway and routing, port 53 access, record content, caches, and static overrides.

For supporting networking concepts, review the OSI Reference Model and computer networking fundamentals.