VMware ESXi and vSphere Cluster Management

Configure DNS Name Resolution on Cisco IOS Devices

Learn how to configure Cisco IOS as a DNS client, set name servers and domain suffixes, test hostname resolution, and troubleshoot DNS failures.

What DNS Does on a Cisco IOS Device

DNS, or the Domain Name System, translates human-readable hostnames into IP addresses. For example, DNS can resolve fileshare.example.com to 192.0.2.100.

A Cisco IOS router or switch can act as a DNS client. In this role, it sends name-resolution queries to configured DNS servers. It is not automatically a DNS server for other devices. A DNS server stores or retrieves DNS records and answers queries from clients.

DNS is useful when an administrator enters a hostname in an IP-based command. For example, ping fileshare.example.com first requires IOS to resolve the hostname to an IP address. Similar resolution can be needed during SSH-related connectivity tests and other management operations that accept hostnames.

Prerequisites

Before configuring DNS, make sure the device can reach the DNS server at Layer 3. DNS settings cannot compensate for missing interface addressing or routing.

Know the correct IPv4 address of at least one DNS server.
Verify that the relevant routed interface, VLAN interface, or SVI has a valid IP address and is operational.
Confirm that the device has a route to the DNS server. A default route may be required when the server is outside the local routing table.
Check the correct VRF when the management interface or DNS server uses a non-default VRF.
Ensure ACLs, firewalls, and other security policies permit DNS traffic, normally UDP or TCP port 53 as required by the environment.

Useful prerequisite knowledge includes IPv4 addressing, Cisco IOS configuration modes, interface and SVI configuration, basic routing, and using ping for IP connectivity tests.

Enable DNS Lookup

DNS lookup is controlled globally. Enter global configuration mode and enable it with ip domain-lookup.

Router> enable
Router# configure terminal
Router(config)# ip domain-lookup
Router(config)# end

Some administrators intentionally disable lookup. When lookup is enabled, IOS may interpret an unrecognized CLI entry as a hostname and try to resolve it. A mistyped command can therefore cause a noticeable pause while IOS waits for DNS responses.

Router# configure terminal
Router(config)# no ip domain-lookup
Router(config)# end

Disabling lookup can make typo-related delays disappear, but it also prevents hostname-based commands from resolving names through DNS. Use it only when that behavior is acceptable.

To verify the setting, inspect the running configuration. If no ip domain-lookup appears, lookup is disabled. If ip domain-lookup appears, or no disabling command is present on a platform where lookup is enabled by default, lookup is enabled.

Router# show running-config | include ip domain-lookup

Configure DNS Name Servers

Configure resolver addresses in global configuration mode with ip name-server. The addresses must be reachable from the Cisco device.

Router# configure terminal
Router(config)# ip name-server 192.0.2.53
Router(config)# ip name-server 192.0.2.54
Router(config)# end

Cisco IOS supports up to six configured name servers. Multiple resolvers provide redundancy: if one resolver is unavailable, IOS can use another according to its configured resolver behavior and availability. Do not assume that merely listing a server guarantees immediate failover in every platform or software release; verify behavior on the device being administered.

Use actual DNS server addresses in production. The addresses in the example use documentation IPv4 space.

Verify, replace, or remove resolver entries

Check the running configuration for configured name servers:

Router# show running-config | include ip name-server

To replace an incorrect entry, remove it and add the correct address:

Router# configure terminal
Router(config)# no ip name-server 192.0.2.53
Router(config)# ip name-server 198.51.100.53
Router(config)# end

Repeat no ip name-server for each address that should be removed. A resolver address that is configured but unreachable can cause slow or unsuccessful lookups.

Configure a Default Domain Suffix

An optional domain suffix is a domain that IOS can append to an unqualified hostname during lookup. Configure it with ip domain-name.

Router# configure terminal
Router(config)# ip domain-name example.com
Router(config)# end

fileshare is an unqualified name or short hostname. fileshare.example.com is an FQDN, meaning fully qualified domain name. When the default domain is example.com, IOS can use the suffix to form a lookup such as fileshare.example.com.

A suffix is useful when administrators regularly access devices and services in one DNS domain. An FQDN is preferable when names could exist in multiple domains or when the intended domain must be explicit.

Verify the configured domain with:

Router# show running-config | include ip domain-name

Remove an incorrect suffix with:

Router# configure terminal
Router(config)# no ip domain-name example.com
Router(config)# end

Complete DNS Client Configuration Example

The following example configures a router to use two internal resolvers and a default domain.

Router# configure terminal
Router(config)# ip domain-lookup
Router(config)# ip name-server 192.0.2.53
Router(config)# ip name-server 192.0.2.54
Router(config)# ip domain-name example.com
Router(config)# end

In this scenario, the router can attempt to resolve the short name fileshare using the configured suffix. The equivalent explicit name is fileshare.example.com.

Test Hostname Resolution

Use ping with a hostname to test both name resolution and subsequent IP reachability.

Router# ping fileshare
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.0.2.100, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5)

The destination IP shown before the ICMP results demonstrates that IOS resolved fileshare to 192.0.2.100. The exclamation marks then report the result of the ICMP test.

Also test the FQDN when relevant:

Router# ping fileshare.example.com

Compare this with a direct test to the DNS server:

Router# ping 192.0.2.53

A successful ping to the DNS server proves basic IP and ICMP reachability to that address, but it does not prove that DNS service is answering queries. Conversely, a DNS lookup can succeed while the destination refuses or filters ICMP.

Verify DNS Configuration and Learned Mappings

The following commands inspect the main DNS-related settings and hostname information:

Router# show hosts
Router# show running-config | include ip domain|ip name-server|ip host

show hosts displays the IOS host name table, including locally configured entries and, where supported, names learned through resolution. It can also display information about the default domain and name servers depending on the IOS platform and release.

show running-config confirms the actual configured commands. Look for:

ip domain-lookup or no ip domain-lookup
ip domain-name and its suffix
One or more ip name-server entries
ip host entries for static local mappings

Command output varies between IOS platforms and releases. If a particular detail is not shown by one command, use the running configuration and a hostname-based test together.

Static Local Hostname Mappings

A local host table is a set of static hostname-to-address mappings configured directly on the Cisco device. It can supplement DNS or provide name resolution in a small, fixed lab.

Router# configure terminal
Router(config)# ip host fileshare 192.0.2.100
Router(config)# end
Router# ping fileshare

This mapping is local to the device. It is not a DNS record learned from an external name server, and changing the address in the network does not automatically update the entry.

Static mappings are practical for a few stable devices, isolated labs, or emergency name resolution. They do not replace centralized DNS in a scalable environment because every Cisco device would need separate updates.

DNS Troubleshooting Workflow

Check whether DNS lookup is enabled.
Confirm that at least one correct name server is configured.
Ping the configured DNS server by IP address.
Check the route, source interface, VLAN or SVI, and VRF used to reach the resolver.
Try a known-good FQDN.
If the FQDN works but the short name fails, inspect the default domain suffix.
If the name resolves but ping fails, troubleshoot routing, ACLs, host firewalls, and ICMP policy rather than DNS alone.
Confirm that the DNS infrastructure contains a record for the requested hostname.
Check firewalls and security policies for DNS filtering, including UDP or TCP port 53.

Symptom	Likely cause	Verification step	Corrective action
Hostname is not resolved	Lookup is disabled, no resolver is configured, the record is absent, or the resolver is unreachable	Inspect the running configuration, run `show hosts`, ping the resolver by IP, and test a known-good FQDN	Enable lookup, configure a valid reachable resolver, correct the suffix, or create the required DNS record
DNS server cannot be reached	Missing route, incorrect interface or SVI, wrong VRF, ACL, firewall, or resolver outage	Ping the resolver by IP and inspect routing and security policy	Correct addressing, VLAN, routing, VRF, or filtering; restore the resolver if it is unavailable
Short hostname fails but FQDN works	Missing or incorrect default domain, or the name belongs to another suffix	Inspect `ip domain-name` and compare the working FQDN	Correct the domain suffix or use the FQDN explicitly
FQDN resolves but ping fails	Destination is unreachable or ICMP is blocked	Identify the resolved IP and test routing and reachability to that address	Fix routing, ACLs, interface state, host firewall, or ICMP policy; do not treat this alone as a DNS failure
CLI pauses after an invalid command	IOS is attempting DNS lookup for text interpreted as a hostname	Check whether `ip domain-lookup` is enabled	Disable lookup with `no ip domain-lookup` if hostname resolution is not required
Incorrect or unavailable DNS server is configured	Wrong address, missing route, wrong VRF, port 53 filtering, or resolver outage	Review `ip name-server` entries and test each resolver by IP where possible	Remove the bad entry, configure a correct alternate resolver, or repair connectivity and policy

Practical Scenarios

Internal DNS and a short hostname

Assume an internal DNS server is at 192.0.2.53 and the organization uses example.com.

Router# configure terminal
Router(config)# ip domain-lookup
Router(config)# ip name-server 192.0.2.53
Router(config)# ip domain-name example.com
Router(config)# end
Router# ping fileshare

IOS can use the configured suffix to look up fileshare.example.com. Verify the returned IP before interpreting the ICMP results.

Use an FQDN to avoid suffix ambiguity

If the service belongs to a different domain, or if the suffix is uncertain, use the complete name:

Router# ping fileshare.example.com

This test does not depend on the device guessing which suffix should be appended.

Redundant resolvers

Configure a primary and secondary resolver, then verify both entries:

Router# configure terminal
Router(config)# ip name-server 192.0.2.53
Router(config)# ip name-server 192.0.2.54
Router(config)# end
Router# show running-config | include ip name-server

Multiple resolvers reduce dependence on one DNS server. IOS supports a maximum of six configured name servers.

Exam-Relevant Notes

ip domain-lookup enables DNS hostname lookup globally.
no ip domain-lookup disables lookup and can prevent delays caused by mistyped commands.
ip name-server identifies DNS resolvers used by the IOS device.
ip domain-name defines the default domain suffix; it is not itself a DNS server address.
ip host creates a local static hostname mapping.
A successful hostname resolution does not guarantee successful ICMP reachability.
A device configured as a DNS client is not automatically a DNS server for network hosts.

For related Cisco IOS management topics, see Cisco IOS DNS configuration.