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.
| 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-lookupis enabled by default on Cisco IOS. Without a configuredip name-server, every unrecognised command causes a 3–9 second DNS broadcast timeout — useno ip domain-lookupin labs to prevent this.- Three DNS client commands work together:
ip domain-lookup(enables queries),ip name-server [IP](specifies server), andip 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 hostalways 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-listdefines multiple domain suffixes tried in sequence — it overridesip domain-namewhen both are configured. Useful in multi-domain environments.- In
show hostsoutput: perm = static host table entry (fromip 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 domainis 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-lookupis on by default, whatno ip domain-lookupdoes, the difference betweenip host(permanent, local) and DNS (dynamic, server-based), and how to readshow hostsoutput. 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-serveroption 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
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?
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.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?
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.What is the key difference between a perm and a temp entry in show hosts output?
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].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?
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.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?
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.
What does ip domain-list do, and how does it interact with ip domain-name when both are configured?
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).An engineer runs clear ip host *. What is the effect on the host table?
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.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?
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.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?
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).
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?
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.Related Topics & Step-by-Step Tutorials
Related concepts and next steps:
- Purpose of DNS – Domain Name System Explained — DNS — why name resolution is needed
- How DNS Works – Domain Name System Explained — recursive and iterative queries
- nslookup — nslookup — DNS testing from CLI
- DHCP Server Configuration on a Cisco Router
- NTP Configuration
- Basic Interface Configuration (IP Addressing)