DNS Client Configuration on Cisco IOS

Every network engineer works with hostnames daily — ping R2, ssh admin@R2, or a router resolving a software repository by name for an update. Without DNS, every command that uses a hostname pauses for a timeout before failing — an irritating delay on every mistyped command in the CLI, and a real operational gap when tools and scripts depend on name resolution.

A Cisco IOS router can act as a DNS client — querying an external or internal DNS server to resolve hostnames to IP addresses. Three configuration elements are needed: enable DNS lookup, specify the DNS server IP, and optionally set a default domain name so short hostnames like R2 are automatically expanded to R2.netstuts.local before the query is sent. A local host table provides a router-side override — useful for lab environments without a DNS server or for critical entries that must always resolve correctly regardless of DNS availability. For a full explanation of how DNS works, see How DNS Works.

Before starting, ensure IP reachability to the DNS server — DNS uses UDP/TCP port 53 and requires a routed path. Complete Static Route Configuration or OSPF Single-Area Configuration for the routing prerequisite. For timestamped logging that benefits from reliable hostname resolution in log messages, see NTP Configuration.

1. DNS on Cisco IOS — Core Concepts

How IOS Resolves a Hostname

When a Cisco router needs to resolve a hostname (from a ping, telnet, ssh, or any name-based command), it follows a lookup sequence:

Step	Lookup Source	Command / Location	Notes
1	Local host table	`ip host [name] [IP]`	Checked first — static entries always win over DNS. Instant, no network query.
2	DNS server query	`ip name-server [IP]`	Queried if no host table entry exists. Requires `ip domain-lookup` to be enabled (it is by default).
3	Domain name appended + retry	`ip domain-name [name]`	If the first DNS query fails, IOS appends the default domain and retries — e.g., "R2" becomes "R2.netstuts.local"
4	Failure	—	If all attempts fail and `ip domain-lookup` is enabled, IOS waits for the query timeout (default 3 sec × 3 retries = up to 9 sec per name-server) before reporting failure

ip domain-lookup is enabled by default. On a router with no ip name-server configured, every mistyped command that IOS cannot recognise (e.g., shw) is treated as a hostname and broadcast-queried for DNS — causing a 3–9 second delay before the "bad command" error appears. This is why many engineers add no ip domain-lookup in lab environments where DNS is not needed. In production, configure a valid ip name-server instead of disabling lookup entirely.

DNS Configuration Commands

Command	Purpose	Default
`ip domain-lookup`	Enables DNS resolution — IOS queries name-servers when a hostname is used	Enabled by default
`no ip domain-lookup`	Disables DNS resolution — IOS never sends DNS queries. Mistyped commands fail instantly without timeout	—
`ip name-server [IP1] [IP2]`	Specifies up to 6 DNS server IPs. IOS queries them in order — first reachable server that responds wins	Not configured
`ip domain-name [name]`	Sets the default domain suffix appended to unqualified hostnames (e.g., "R2" → "R2.netstuts.local")	Not configured
`ip domain-list [name]`	Adds multiple domain suffixes tried in sequence — more flexible than a single `ip domain-name`	Not configured
`ip host [name] [IP]`	Creates a static host table entry — resolved before DNS is queried	Not configured

DNS Record Types Relevant to IOS

Record Type	Resolves	IOS Use Case
A	Hostname → IPv4 address	Most common — `ping R2.netstuts.local` queries for an A record
AAAA	Hostname → IPv6 address	Used when `ipv6 unicast-routing` is enabled and IPv6 DNS is queried
PTR	IP address → Hostname (reverse lookup)	Used in `show ip dns view` and debug outputs to show hostnames instead of IPs

2. Lab Topology & Scenario

NetsTuts_R1 is the edge router with internet access. It is configured as a DNS client pointing to an internal DNS server (192.168.10.53) for the netstuts.local domain and to Google's public DNS (8.8.8.8) as a fallback for external names. NetsTuts_R2 uses only the internal DNS server. Both routers have local host table entries as a safety net for critical infrastructure hostnames.

                    Internet (8.8.8.8 — Google DNS)
                           |
                      Gi0/0 (WAN)
                      203.0.113.2
               ┌─────────────────────────┐
               │      NetsTuts_R1         │
               │  ip name-server          │
               │    192.168.10.53         │
               │    8.8.8.8               │
               │  ip domain-name          │
               │    netstuts.local        │
               └─────────────────────────┘
                      Gi0/1 (LAN)
                      192.168.10.1
                           |
         ══════════════════════════════════════
                    192.168.10.0/24
              |                         |
         192.168.10.53              10.0.12.2
         [DNS Server]            ┌──────────────┐
         netstuts.local          │ NetsTuts_R2  │
                                 │ ip name-server│
                                 │  192.168.10.53│
                                 └──────────────┘

Device	DNS Server 1	DNS Server 2	Domain Name	Host Table Entries
NetsTuts_R1	192.168.10.53 (internal)	8.8.8.8 (Google)	netstuts.local	R2, SW1, DNS-SRV
NetsTuts_R2	192.168.10.53 (internal)	—	netstuts.local	R1, SW1

3. Step 1 — Configure DNS Client on NetsTuts_R1

All three DNS commands work together — lookup must be enabled, at least one name-server must be reachable, and the domain name provides automatic suffix expansion for short hostnames entered at the CLI:

NetsTuts_R1>en
NetsTuts_R1#conf t
Enter configuration commands, one per line.  End with CNTL/Z.

! ── Enable DNS lookup (on by default — explicit for clarity)
NetsTuts_R1(config)#ip domain-lookup

! ── Primary: internal DNS server for netstuts.local ──────
! ── Secondary: Google public DNS for external names ──────
NetsTuts_R1(config)#ip name-server 192.168.10.53 8.8.8.8

! ── Default domain suffix for unqualified hostnames ──────
NetsTuts_R1(config)#ip domain-name netstuts.local

NetsTuts_R1(config)#end
NetsTuts_R1#wr
Building configuration...
[OK]
NetsTuts_R1#

With these three commands: typing ping R2 at the CLI causes IOS to first query 192.168.10.53 for "R2" — if not found, it retries as "R2.netstuts.local". If the internal server still cannot resolve it, IOS queries 8.8.8.8. Name-servers are queried in the order listed — primary first, secondary only if primary times out or returns no result.

DNS Command Breakdown

Command	What It Does	Without It
`ip domain-lookup`	Permits IOS to send DNS queries when a hostname is used in any command	All hostname-based commands fail immediately — no DNS query sent
`ip name-server 192.168.10.53 8.8.8.8`	Defines which DNS servers to query, in preference order	DNS lookup is enabled but no server to query — all lookups time out
`ip domain-name netstuts.local`	Appended to short hostnames — `ping R2` becomes `ping R2.netstuts.local`	Only fully qualified names resolve — `ping R2.netstuts.local` works but `ping R2` fails

4. Step 2 — Configure DNS Client on NetsTuts_R2

NetsTuts_R2>en
NetsTuts_R2#conf t
Enter configuration commands, one per line.  End with CNTL/Z.

NetsTuts_R2(config)#ip domain-lookup
NetsTuts_R2(config)#ip name-server 192.168.10.53
NetsTuts_R2(config)#ip domain-name netstuts.local

NetsTuts_R2(config)#end
NetsTuts_R2#wr
Building configuration...
[OK]
NetsTuts_R2#

5. Step 3 — Configure the Local Host Table

The local host table provides static name-to-IP mappings directly on the router — no DNS server query is needed. Host table entries are always resolved before DNS is consulted. This is essential for: critical infrastructure devices that must always be reachable by name, lab environments without a DNS server, and overriding DNS for specific hostnames (e.g., forcing R2 to always resolve to a specific management IP):

! ── Host table entries on R1 ─────────────────────────────
NetsTuts_R1(config)#ip host R2           10.0.12.2
NetsTuts_R1(config)#ip host SW1          192.168.10.11
NetsTuts_R1(config)#ip host DNS-SRV      192.168.10.53
NetsTuts_R1(config)#ip host NTP-SRV      192.168.10.1

! ── Multiple IPs for one hostname (round-robin) ──────────
NetsTuts_R1(config)#ip host BACKUP-SRV   192.168.10.20 192.168.10.21

! ── Host table entries on R2 ─────────────────────────────
NetsTuts_R2(config)#ip host R1           192.168.10.1
NetsTuts_R2(config)#ip host SW1          192.168.10.11

The ip host command accepts up to 8 IP addresses per hostname — IOS round-robins between them for load distribution. Host table entries survive even when the DNS server is unreachable, making them a reliable backstop for critical device names. Entries are stored in running-config and persist across reloads when saved to startup-config with wr.

Host Table vs DNS — When to Use Each

Scenario	Use Host Table	Use DNS
Critical infrastructure (core routers, DNS server itself)	✅ Yes — always reachable even if DNS is down	Too risky — DNS server failure breaks name resolution for the DNS server itself
Lab with no DNS server	✅ Yes — simple, no external dependency	Not applicable
Large network with hundreds of devices	❌ Not scalable — each router needs individual entries	✅ Yes — centrally managed, one update propagates everywhere
Hostnames that must override DNS	✅ Yes — host table takes priority over DNS	Would return a different result

6. Step 4 — Multiple Domain Suffixes with ip domain-list

In environments with multiple internal domains (e.g., a company with separate domains for different departments or sites), ip domain-list defines multiple suffixes to try in sequence. When configured, ip domain-list overrides ip domain-name — only the list entries are used for suffix expansion:

! ── Remove single domain-name (replaced by domain-list) ──
NetsTuts_R1(config)#no ip domain-name netstuts.local

! ── Define multiple domain suffixes ──────────────────────
NetsTuts_R1(config)#ip domain-list netstuts.local
NetsTuts_R1(config)#ip domain-list corp.netstuts.com
NetsTuts_R1(config)#ip domain-list mgmt.netstuts.local

When ping R2 is entered, IOS tries resolution in this order: R2 (no suffix), R2.netstuts.local, R2.corp.netstuts.com, R2.mgmt.netstuts.local. The first successful resolution wins. ip domain-list entries are tried sequentially until one succeeds or all are exhausted.

7. Step 5 — Disabling DNS Lookup (Lab Best Practice)

In a lab environment with no DNS server, leaving ip domain-lookup enabled causes every typo or unrecognised command to trigger a DNS lookup — resulting in a 3–9 second delay per error. The sequence below shows both how to disable it and how to limit the damage when it is enabled without a reachable server:

! ── Disable DNS lookup to prevent typo delays ────────────
NetsTuts_LAB_R1(config)#no ip domain-lookup

! ── Alternatively: keep lookup but point to localhost ────
! ── 127.255.255.255 fails instantly — no timeout ─────────
! NetsTuts_LAB_R1(config)#ip name-server 127.255.255.255

! ── To re-enable later when DNS is available ─────────────
! NetsTuts_LAB_R1(config)#ip domain-lookup
! NetsTuts_LAB_R1(config)#ip name-server 192.168.10.53

The most important lab command: no ip domain-lookup is the first configuration applied in most lab environments — it makes typos fail immediately with "% Unknown command" instead of hanging for 9 seconds while IOS broadcasts DNS queries into the void.

What Happens With and Without no ip domain-lookup

! ── WITHOUT no ip domain-lookup (DNS enabled, no server) ─
Router(config)#shw running-config
Translating "shw"...domain server (255.255.255.255)
% Unknown command or computer name, or unable to find computer address

! ── WITH no ip domain-lookup ─────────────────────────────
Router(config)#shw running-config
                     ^
% Invalid input detected at '^' marker.

Without no ip domain-lookup, the typo "shw" triggers a DNS broadcast with a timeout before the error appears. With no ip domain-lookup, the error appears immediately — a much better lab experience.

8. Verification

ping by Hostname — DNS Resolution Test

! ── Ping using short hostname — domain suffix appended ───
NetsTuts_R1#ping R2
Translating "R2"...domain server (192.168.10.53) [OK]

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.0.12.2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/1/2 ms
NetsTuts_R1#

The line "Translating "R2"...domain server (192.168.10.53) [OK]" confirms DNS resolution. IOS queried 192.168.10.53, received the answer (10.0.12.2), and then sent the pings to that IP. The hostname R2 was expanded to R2.netstuts.local (via ip domain-name) before the query was sent. If the host table had an ip host R2 entry, "Translating" would not appear — host table lookups are instant and silent.

ping by Hostname — Host Table Resolution (No DNS Query)

! ── Ping using host table entry — no DNS query needed ────
NetsTuts_R1#ping SW1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.10.11, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/1/2 ms
NetsTuts_R1#

No "Translating" line appears — SW1 was found in the local host table (ip host SW1 192.168.10.11), so no DNS server was queried. The ping went directly to 192.168.10.11. This demonstrates the lookup priority: host table is checked first, DNS is only consulted if no host table entry exists.

show hosts — View Host Table and DNS Cache

NetsTuts_R1#show hosts
Default domain is netstuts.local
Name/address lookup uses domain service
Name servers are 192.168.10.53, 8.8.8.8

Codes: UN - unknown, EX - expired, OK - OK, ?? - revalidating
       temp - temporary, perm - permanent
       NA - Not Applicable  None - Not Applicable

Host                      Port  Flags      Age Type   Address(es)
R2                        None  (perm, OK)  0  IP     10.0.12.2
SW1                       None  (perm, OK)  0  IP     192.168.10.11
DNS-SRV                   None  (perm, OK)  0  IP     192.168.10.53
NTP-SRV                   None  (perm, OK)  0  IP     192.168.10.1
BACKUP-SRV                None  (perm, OK)  0  IP     192.168.10.20
                                                       192.168.10.21
google.com                None  (temp, OK)  2  IP     142.250.189.14

show hosts displays both static host table entries and the dynamic DNS cache. Key columns: perm = configured with ip host — permanent, stored in config. temp = learned from DNS — temporary, cached for the TTL period then discarded. OK = valid entry. EX = expired — will be re-queried on next use. The header confirms the active configuration: default domain (netstuts.local) and the name-servers in use (192.168.10.53, 8.8.8.8).

show ip dns view — DNS View Details

NetsTuts_R1#show ip dns view
DNS View default parameters:
  Domain lookup is enabled
  Default domain name: netstuts.local
  Domain search list:
    netstuts.local
    corp.netstuts.com
  Name server: 192.168.10.53 (Up  0:00:05)
  Name server: 8.8.8.8       (Up  0:00:03)

show ip dns view provides a structured summary of the entire DNS client configuration — lookup state, default domain, search list order, and the status of each name-server (Up/Down with last response time). This is the most comprehensive single DNS verification command.

debug ip domain — Live DNS Query Trace

NetsTuts_R1#debug ip domain
DNS activity debugging is on
NetsTuts_R1#ping R3
DNS: sending DNS query "R3" to server 192.168.10.53
DNS: no answer from 192.168.10.53 for "R3", retrying "R3.netstuts.local"
DNS: received DNS reply from 192.168.10.53
DNS: resolved "R3.netstuts.local" as 10.0.13.2
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.0.13.2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/2/3 ms
NetsTuts_R1#undebug all

debug ip domain shows every DNS transaction in real time — the query sent, whether it succeeded or required the domain suffix to be appended, the server that answered, and the resolved IP. This debug is invaluable when troubleshooting resolution failures — it shows exactly where in the lookup chain the failure occurs. Always disable after use: undebug all.

SSH by Hostname — Real-World Use

! ── SSH to R2 using hostname ─────────────────────────────
NetsTuts_R1#ssh -l admin R2
Translating "R2"...domain server (192.168.10.53) [OK]
Password:

NetsTuts_R2>

SSH uses DNS resolution before establishing the connection — the hostname R2 is resolved to 10.0.12.2 and SSH connects to that IP. This works because ip domain-lookup, ip name-server, and ip domain-name are all configured. For SSH to work by hostname, the destination also needs SSH configured — see SSH Configuration.

Verification Command Summary

Command	What It Shows	Primary Use
`show hosts`	All host table entries (perm) and DNS cache (temp) — flags, age, IP addresses	Verify host table entries exist and DNS-cached names
`show ip dns view`	Complete DNS client config — lookup state, domain name, search list, name-server status	Comprehensive single-command DNS config and status check
`ping [hostname]`	Triggers DNS resolution — "Translating [name]...domain server [IP] [OK/failed]" in output	End-to-end test: name resolution + IP reachability in one command
`show running-config \| include ip`	All `ip domain-lookup`, `ip name-server`, `ip domain-name`, `ip host` lines	Quick audit of entire DNS client configuration
`debug ip domain`	Live DNS queries — server queried, suffix appended, response received, resolved IP	Troubleshoot resolution failures — shows exactly where lookup fails
`show clock`	Verify time accuracy — DNS-related authentication (DNSSEC, Kerberos) requires correct system time	Confirm NTP is synced before diagnosing DNS auth issues

9. Troubleshooting DNS Client Issues

Problem	Symptom	Cause	Fix
Every typo causes a long pause	Mistyped commands hang for 9+ seconds showing "Translating..."	`ip domain-lookup` is enabled but no valid `ip name-server` is configured — IOS broadcasts DNS queries with no server to respond	In labs: `no ip domain-lookup`. In production: configure a valid `ip name-server` IP that is reachable. Alternatively use `ip name-server 127.0.0.1` to fail fast.
Hostname not resolving — "% Unknown host"	`ping R2` returns "% Unknown host" immediately	Either `ip domain-lookup` is disabled (`no ip domain-lookup`) or no `ip name-server` is configured. Also check host table — `show hosts`.	Verify with `show running-config \| include ip domain`. Re-enable: `ip domain-lookup`. Add server: `ip name-server [IP]`. Check that the name-server IP is reachable: `ping [name-server-IP]`
DNS query times out — name-server unreachable	Hostname lookup hangs for several seconds before failing — "% Name lookup failed"	The configured name-server IP is unreachable — no route, interface down, ACL blocking UDP/53, or server is down	Ping the name-server IP: `ping 192.168.10.53`. Verify routing with static routes or OSPF. Check for ACLs blocking UDP/53. Run `debug ip domain` to see which server is being queried and whether a response arrives.
Short hostname resolves correctly but FQDN fails	`ping R2` works via host table but `ping R2.netstuts.local` fails	DNS server does not have an A record for R2.netstuts.local — the DNS server-side configuration is incomplete	Verify the DNS server has the correct zone and record. Use `debug ip domain` to confirm the query is sent and what response arrives. The issue is on the server side, not the IOS client. Use nslookup or dig from a workstation to test the DNS server directly.
Wrong IP returned for a hostname	`ping R2` resolves but pings fail — wrong IP in the answer	Host table has an outdated entry overriding DNS — `ip host R2` may point to an old IP. Or DNS has a stale A record.	Check `show hosts` — if a perm entry exists with the wrong IP, remove it: `no ip host R2` and re-add with correct IP. Clear the DNS cache: `clear ip host *`.
Hostname resolves but SSH fails	DNS resolves the hostname correctly but `ssh -l admin R2` times out or is refused	DNS resolution succeeded but the SSH issue is separate — SSH may not be configured on R2, or an ACL is blocking TCP/22 to the resolved IP	Verify with `ping [resolved-IP]` first. Then check SSH Configuration on R2. Review ACLs on R2's VTY lines with `show running-config \| section line vty`.

Key Points & Exam Tips

ip domain-lookup is enabled by default on Cisco IOS. Without a configured ip name-server, every unrecognised command causes a 3–9 second DNS broadcast timeout — use no ip domain-lookup in labs to prevent this.
Three DNS client commands work together: ip domain-lookup (enables queries), ip name-server [IP] (specifies server), and ip domain-name [name] (appends suffix to short hostnames). All three are needed for full DNS client functionality. See How DNS Works for background.
IOS resolves hostnames in order: local host table first (instant, no network query), then DNS server. Host table entries created with ip host always override DNS responses for the same hostname.
Up to 6 DNS servers can be configured with ip name-server — listed in a single command, queried in order. If the primary times out, IOS automatically tries the next server.
ip domain-list defines multiple domain suffixes tried in sequence — it overrides ip domain-name when both are configured. Useful in multi-domain environments.
In show hosts output: perm = static host table entry (from ip host), temp = dynamically cached DNS response. Temp entries expire based on DNS TTL. See How DNS Works for an explanation of TTL.
When a hostname is resolved via DNS, the output shows "Translating [name]...domain server ([IP]) [OK]". When resolved via the host table, no "Translating" line appears — the resolution is silent and instant.
debug ip domain is the most useful DNS troubleshooting command — it shows every query sent, whether the domain suffix was appended, which server responded, and the resolved IP.
Use clear ip host * to flush the DNS cache — forces re-querying all temp entries. Permanent host table entries (ip host) are not affected by this command.
On the CCNA exam: know that ip domain-lookup is on by default, what no ip domain-lookup does, the difference between ip host (permanent, local) and DNS (dynamic, server-based), and how to read show hosts output. See DNS Record Types for A, AAAA, and PTR record details.
For DHCP clients to automatically receive the correct DNS server address, configure the dns-server option in the DHCP server pool. For clients on remote subnets, use a DHCP relay agent.

Next Steps: With DNS client configured, hostnames resolve correctly across the network. For SSH connections by hostname to work end-to-end, complete SSH Configuration on the destination devices. For DHCP clients to receive the correct DNS server IP automatically, revisit DHCP Server Configuration — the dns-server option in the DHCP pool distributes 192.168.10.53 to all hosts automatically. For hosts on remote subnets, configure a DHCP Relay Agent. To verify DNS resolution from a workstation, use nslookup or dig.

TEST WHAT YOU LEARNED

1. A network engineer types `shw ver` by mistake on a router with no `ip name-server` configured. The CLI pauses for about 9 seconds before showing an error. What is happening and how is it fixed for a lab environment?

A. The router is processing a large routing table — unrelated to DNS. Add more memory. B. ip domain-lookup is enabled by default — IOS treats "shw" as a hostname and broadcasts a DNS query (255.255.255.255) three times with 3-second timeouts. Since no server responds, it eventually times out. Fix: no ip domain-lookup in global config C. The console connection is slow — enable faster baud rate on the console line D. The router is sending the command to a remote device — disable exec-timeout on the console line

Correct answer is B. When ip domain-lookup is enabled (the default) and IOS encounters a string it does not recognise as a valid command, it interprets it as a hostname and attempts DNS resolution. Without a configured ip name-server, IOS broadcasts to 255.255.255.255 on UDP/53. It tries 3 times with a 3-second timeout each = up to 9 seconds before giving up. In a lab with no DNS server, this makes every typo painful. The fix is no ip domain-lookup in global configuration mode — mistyped commands then fail instantly with "% Invalid input detected" without any DNS lookup delay.

2. A router is configured with `ip name-server 192.168.10.53` and `ip domain-name netstuts.local`. An engineer types `ping R2`. In what order does IOS attempt to resolve the hostname?

A. Queries 192.168.10.53 for "R2.netstuts.local" immediately — short hostnames always get the domain appended first B. Checks DNS first, then the local host table if DNS fails C. Broadcasts to 255.255.255.255 first, then queries 192.168.10.53 D. Checks the local host table first (silent, instant) — if no ip host R2 entry exists, queries 192.168.10.53 for "R2". If that fails, appends the domain and retries as "R2.netstuts.local" on the same server

Correct answer is D. IOS hostname resolution follows a strict priority: (1) local host table — if ip host R2 [IP] exists, the query is resolved instantly with no network traffic. (2) DNS query for the bare hostname "R2" sent to 192.168.10.53. (3) If the DNS server returns no result for "R2", IOS appends the default domain and retries as "R2.netstuts.local" on the same server. This three-step process is why the domain name suffix is a fallback — it is only applied when the bare hostname query fails first. The host table check always precedes DNS regardless of configuration.

3. What is the key difference between a perm and a temp entry in `show hosts` output?

A. Perm entries are statically configured with ip host — they persist in the config and never expire. Temp entries are dynamically cached from DNS responses — they expire after the DNS TTL period and are re-queried on next use B. Perm entries are for IPv6 addresses and temp entries are for IPv4 addresses C. Perm entries are learned from DHCP and temp entries are manually configured D. Perm entries are backed up to TFTP automatically while temp entries are stored only in RAM

Correct answer is A. In show hosts output, the flags column distinguishes the two types. "perm" (permanent) entries were created by the ip host command — they are stored in the running configuration, survive reloads when saved, and never expire. "temp" (temporary) entries were learned dynamically when DNS resolved a hostname — they are cached in RAM only and expire when the DNS TTL runs out, after which the entry is marked "EX" (expired) and re-queried on next access. Clear temp entries with clear ip host *. Perm entries are only removed with no ip host [name].

4. When performing `ping SW1`, the output shows no "Translating" line and the ping succeeds immediately. When performing `ping R3`, the output shows "Translating "R3"...domain server (192.168.10.53) [OK]" before the ping succeeds. What explains the difference?

A. SW1 was recently pinged and its result is cached — the cache expires after 60 seconds B. R3 is on a different subnet — remote hosts always require DNS while local hosts do not C. SW1 has a permanent host table entry (ip host SW1 192.168.10.11) — resolved instantly with no DNS query. R3 has no host table entry — IOS must query the DNS server (192.168.10.53) which returns the IP. The "Translating" line only appears when DNS is queried, not for host table lookups D. SW1 responds to ARP — IOS uses ARP for local hosts and DNS for remote hosts

Correct answer is C. The presence or absence of the "Translating" line is the definitive indicator of whether DNS was queried. Host table lookups (perm entries from ip host) are resolved entirely within the router's local memory — no "Translating" message, no network traffic, instant resolution. DNS lookups always show the "Translating [hostname]...domain server ([IP]) [OK/FAILED]" message because IOS is actively sending a UDP query to the name-server and waiting for a response. This behaviour makes it easy to determine the resolution source just by observing the ping output.

5. A router has `ip name-server 192.168.10.53 8.8.8.8` configured. The internal DNS server (192.168.10.53) goes down. What happens to hostname resolution?

A. All hostname resolution fails immediately — IOS does not try the second server until the first is manually removed B. IOS switches permanently to 8.8.8.8 and ignores 192.168.10.53 until the router is reloaded C. Resolution fails only for internal names — external names still resolve via 8.8.8.8 without delay D. IOS queries 192.168.10.53 first — after the timeout (3 seconds × retries), it automatically falls back to 8.8.8.8. Internal names that only exist in the internal DNS will fail, but external names (google.com etc.) will still resolve via 8.8.8.8 after the fallback delay

Correct answer is D. IOS always queries name-servers in the order they are listed. When 192.168.10.53 is unreachable, IOS waits for the query timeout (default 3 seconds per retry, 3 retries = up to 9 seconds) before moving to 8.8.8.8. External hostnames like google.com will eventually resolve via 8.8.8.8 but with a noticeable delay equal to the 192.168.10.53 timeout period. Internal-only names (like R2.netstuts.local) will fail even after fallback because 8.8.8.8 has no knowledge of the netstuts.local zone. Host table entries for critical devices are unaffected — they resolve instantly regardless of DNS server status.

6. What does `ip domain-list` do, and how does it interact with `ip domain-name` when both are configured?

A. ip domain-list defines multiple domain suffixes tried in sequence when a short hostname fails to resolve. When ip domain-list entries exist, they override ip domain-name — only the list entries are used for suffix expansion B. ip domain-list and ip domain-name are used simultaneously — all suffixes (including domain-name) are tried in alphabetical order C. ip domain-list is only for IPv6 domains — ip domain-name handles IPv4 D. ip domain-list specifies which DNS servers to query in order — it duplicates the function of ip name-server

Correct answer is A. ip domain-list allows multiple domain suffixes to be configured — when a short hostname query fails, IOS tries appending each domain from the list in order until one succeeds. Crucially, when ip domain-list is configured, it takes precedence and ip domain-name is ignored for suffix expansion purposes (though it still appears in the config). This makes domain-list more flexible than domain-name for environments with multiple DNS zones (e.g., netstuts.local for internal devices and corp.netstuts.com for application servers in a different zone).

7. An engineer runs `clear ip host *`. What is the effect on the host table?

A. All entries including permanent host table entries are removed — the router must be reconfigured B. All entries are removed but automatically re-populated from DNS within 60 seconds C. Only temporary (dynamically cached DNS) entries are cleared — permanent entries configured with ip host remain intact. The cleared temp entries are re-queried from DNS the next time those hostnames are used D. Only expired (EX) entries are removed — valid temp entries with remaining TTL are preserved

Correct answer is C. clear ip host * flushes the dynamic DNS cache — all "temp" entries that were learned by querying DNS servers are removed. Permanent entries created with the ip host command are part of the running configuration and are completely unaffected by this command. To remove a specific permanent entry, use no ip host [hostname]. The DNS cache is cleared during troubleshooting when stale entries (old IP addresses for moved devices) are causing resolution failures, forcing IOS to perform fresh DNS queries and get current IP addresses.

8. A router resolves hostnames correctly but engineers want to ensure that `R1.netstuts.local` always resolves to 192.168.10.1 even if the DNS server returns a different IP (e.g., after an incorrect DNS record update). What configuration achieves this?

A. Configure a longer DNS TTL on the DNS server so the cached entry lasts longer B. Add ip host R1 192.168.10.1 and ip host R1.netstuts.local 192.168.10.1 to the local host table — host table entries always take precedence over DNS responses, guaranteeing R1 always resolves to 192.168.10.1 regardless of what DNS returns C. Use ip dns spoofing 192.168.10.1 to redirect all DNS queries for R1 D. Set R1 as the primary DNS server — DNS servers always use their own records for self-resolution

Correct answer is B. The local host table has higher priority than DNS — it is always checked before any DNS query is sent. By adding ip host R1 192.168.10.1, any command on this router that tries to resolve "R1" is answered instantly from the local table with 192.168.10.1, regardless of what the DNS server says. For the fully qualified name, adding ip host R1.netstuts.local 192.168.10.1 covers both short and FQDN lookups. This is a reliable override mechanism for critical infrastructure — if the DNS server is misconfigured or compromised, the host table ensures critical devices remain reachable by their correct names.

9. `debug ip domain` output shows: "DNS: sending DNS query "fileserver" to server 192.168.10.53 — DNS: no answer from 192.168.10.53 for "fileserver", retrying "fileserver.netstuts.local" — DNS: no answer from 192.168.10.53 for "fileserver.netstuts.local"." What does this indicate?

A. The DNS server (192.168.10.53) is unreachable — UDP/53 is blocked by an ACL B. The router's ip domain-name is misconfigured — it should be netstuts.com not netstuts.local C. The hostname "fileserver" contains too many characters — DNS has a 12-character limit D. The DNS server (192.168.10.53) is reachable and responding (it sent "no answer" — not a timeout) but has no A record for "fileserver" or "fileserver.netstuts.local". The DNS zone exists and the server is working, but the record for this hostname is missing from the zone

Correct answer is D. The debug output distinguishes between "no answer from server" (server responded but has no record) and a timeout (server did not respond at all). "No answer" means the DNS server received the query, processed it, and replied with NXDOMAIN (no such name) or an empty response. The server is functional and the network path is clear — the problem is that the DNS zone on 192.168.10.53 does not have an A record for "fileserver" or "fileserver.netstuts.local". The fix is on the DNS server side — add the missing A record. To confirm from a workstation, use nslookup or dig against 192.168.10.53 directly. A timeout or unreachable server would show different debug output (no reply received, retrying).

10. Which command provides the most comprehensive single-command view of a Cisco router's complete DNS client configuration including lookup state, domain name, domain search list, and name-server status?

A. show hosts B. show running-config | include ip name C. show ip dns view — displays lookup enabled/disabled state, default domain name, complete domain search list in order, all configured name-servers with their current up/down status and last response time D. show ip interface brief

Correct answer is C. show ip dns view is the most complete DNS client status command — it consolidates everything in one output: whether domain lookup is enabled or disabled, the default domain name, the full ordered domain search list, and each configured name-server with its current reachability status (Up/Down) and the timestamp of the last successful response. show hosts shows the host table and cache but not server status. show running-config | include ip name shows configuration text but not live status. show ip dns view is the go-to command for a complete DNS health check on a Cisco IOS device.

Back to Home