CCNA online course

Configure DNS on a Cisco IOS Device

Learn how to configure Cisco IOS routers and switches as DNS clients, use local host mappings, enable basic IOS DNS service, verify resolution, and troubleshoot DNS failures.

Domain Name System (DNS) translates human-readable hostnames into IP addresses. On a Cisco IOS router or multilayer switch, DNS can make commands such as ping, ssh, telnet, traceroute, and copy easier to use. Instead of remembering an address such as 192.0.2.10, an administrator can use a name such as core-sw1.example.com.

DNS Fundamentals for Cisco Devices

A hostname is a human-readable name assigned to a device or service. DNS, the Domain Name System, maps that name to an IP address. A Cisco device can participate in DNS in several different ways:

• DNS client or resolver: Sends name-resolution requests to configured DNS servers.
• Local host table: Uses static hostname-to-IP mappings stored in the IOS configuration.
• DNS server: On supported IOS platforms and releases, answers DNS queries using locally configured records.

A DNS client is not automatically a DNS server. Configuring ip name-server tells the device where to send queries; it does not make the device answer queries from other clients.

Forward and reverse lookups

A forward lookup resolves a name to an address. For example, resolving router1.example.com to 192.0.2.1. A reverse lookup performs the opposite operation: it uses an IP address to look up a name. Reverse lookups commonly use DNS PTR records.

Forward and reverse records are independent. A forward lookup can work even when no reverse record exists.

FQDNs, short names, and domain suffixes

A fully qualified domain name (FQDN) contains the complete name, such as router1.example.com. A short hostname contains only the host portion, such as router1. The domain suffix is the domain appended to a short name.

When ip domain name example.com is configured, IOS can try a short name such as router1 as router1.example.com. Using the FQDN explicitly avoids ambiguity and is useful when testing the configured suffix.

DNS, local host entries, and direct IP addresses

A manually entered IP address does not require DNS. For example, ping 192.0.2.10 tests IP connectivity without first resolving a name. A hostname requires either a matching local host entry or a successful DNS lookup.

Local host entries are static records configured with ip host. They are useful for a small lab, for names that must work when an external DNS server is unavailable, or for a few management devices. In normal operation, IOS checks local host information before asking an external DNS server. Local records are not automatically synchronized with DNS infrastructure.

Prerequisites for DNS Connectivity

DNS configuration is useful only when the Cisco device can reach its name server. Before configuring DNS, identify the DNS server IP address and, when applicable, the organization’s domain suffix.

1. Configure a management IP address on the router or switch.
2. Ensure the relevant interface is operational.
3. Configure a default gateway on a Layer 2 switch, or a default route on a router or multilayer switch.
4. Verify Layer 3 reachability to the DNS server by testing its IP address.
5. Confirm that ACLs and firewalls permit DNS traffic to the server.

For a switch that is operating as a Layer 2 device, the management default gateway is commonly configured with ip default-gateway. A router or multilayer switch normally uses a route, such as a static default route, to reach a remote DNS server.

show ip interface brief
show ip route
ping 192.0.2.53

If the ping to the DNS server’s IP address fails, resolve addressing, interface, routing, ACL, or firewall problems before investigating DNS records.

Configure a Cisco IOS Device as a DNS Client

To configure IOS as a DNS client, enable name lookup, specify one or more name servers, and optionally configure a default domain name.

configure terminal
ip domain lookup
ip name-server 192.0.2.53
ip name-server 198.51.100.53
ip domain name example.com
end
copy running-config startup-config

ip domain lookup enables DNS name resolution. It is enabled by default on many IOS devices, but explicitly configuring it makes the intended behavior clear.

ip name-server identifies a DNS server by IP address. Multiple commands add multiple servers. IOS generally attempts the configured servers in order and can use another configured server if an earlier server does not respond. Exact retry and failover behavior can vary by IOS release, so do not treat a second server as a guarantee that every query will immediately fail over.

ip domain name configures the device’s default domain name. It supports short-name expansion and is also used by several IOS services, including some SSH configurations. Configure it with the organization’s intended domain rather than an arbitrary suffix.

Command reference

Configure Local Hostname Resolution

Use ip host to create static mappings in the IOS local host table. This is appropriate for a few lab or management devices when maintaining a full DNS service would be unnecessary.

configure terminal
ip host core-sw1 192.0.2.10
ip host branch-r1 192.0.2.11
end

The names can then be used in commands:

ping core-sw1
ssh -l admin branch-r1
traceroute core-sw1

You can also create a mapping using an FQDN:

configure terminal
ip host app-server.example.com 192.0.2.20
end

Local records are stored in the running configuration and remain after a reload only when the configuration is saved. They are different from DNS cache entries, which are temporary information retained after a successful lookup.

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

To remove a record, negate the exact host command:

configure terminal
no ip host core-sw1
end

Use a Supported IOS Device as a Basic DNS Server

Some Cisco IOS platforms and releases support a basic DNS server feature. Enable it with ip dns server and provide records with local ip host commands.

configure terminal
ip dns server
ip host app-server.example.com 192.0.2.20
end
copy running-config startup-config

Clients can use the Cisco device’s IP address as their DNS server and query the locally configured record. Verify that the clients can reach that address and that filtering permits DNS traffic.

This IOS feature is limited compared with dedicated DNS platforms. It should not be treated as a replacement for enterprise DNS infrastructure that requires authoritative zones, recursive resolution, high availability, detailed policy controls, dynamic updates, logging, or large-scale record management. Suitable uses include a small lab, a temporary isolated network, or a limited network with a few static records.

Support and behavior vary by platform and IOS release. Confirm feature availability for the specific device before designing a deployment around it.

Comparison of DNS roles

Verify DNS Operation

Verification should separate name resolution from IP connectivity. First test the destination by address, then test its hostname.

ping 192.0.2.10
ping core-sw1
ping core-sw1.example.com
show hosts
show running-config | include ip domain|ip name-server|ip host|ip dns

If the direct IP ping succeeds but the hostname ping fails, the network path is probably working and the problem is likely related to the local host table, DNS settings, the DNS record, the suffix, or DNS filtering. A successful IP ping does not prove that DNS is working.

show hosts can display configured host entries, cached results, the configured domain name, name servers, and lookup status. The exact output varies by IOS release. Use show running-config to verify the commands actually stored in the active configuration.

Test both a short hostname and its FQDN when a suffix is configured:

ping core-sw1
ping core-sw1.example.com

If the FQDN works but the short name fails, inspect ip domain name and confirm that the expected suffix is being appended.

Troubleshoot Cisco IOS DNS

DNS failures can resemble routing or interface failures. Use a layered process: verify the interface and addressing, prove IP reachability, inspect DNS configuration, and then test the name.

Disabled lookup and command-line delays

When IOS receives text that is not a recognized command, it may interpret the text as a hostname and attempt DNS resolution. This can cause a noticeable pause, especially when DNS is unreachable.

configure terminal
no ip domain lookup
end

Disabling lookup is convenient on an isolated lab device or while troubleshooting. It also means hostname-based commands will not resolve through external DNS. Re-enable it when the device is intended to use DNS:

configure terminal
ip domain lookup
end

DNS Transport and Security

DNS commonly uses UDP port 53 for ordinary queries. TCP port 53 is also used in situations such as larger responses and some DNS server operations. A policy that permits only one transport can cause intermittent or incomplete DNS behavior.

• Use trusted DNS servers and document their addresses.
• Protect the management plane with appropriate ACLs and reachability controls.
• Permit DNS traffic only between approved clients and approved DNS servers where practical.
• Review local ip host records periodically and remove obsolete entries.
• Do not expose a basic IOS DNS service broadly unless its limitations and access controls are understood.
• Save intended changes to startup configuration and avoid saving temporary troubleshooting settings accidentally.

Configuration Management

After confirming the configuration, save it so the settings survive a reload:

copy running-config startup-config

Remove obsolete name servers, local records, or DNS server capability explicitly:

configure terminal
no ip name-server 192.0.2.53
no ip host core-sw1
no ip dns server
end

Use the exact configured address or host entry when removing a setting. Then inspect the running configuration again to confirm that only the intended DNS settings remain.

Practical Configuration Example

In this example, a router has reachable DNS servers at 192.0.2.53 and 198.51.100.53. Its organization uses example.com as the domain suffix.

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

show hosts
ping core-sw1
ping core-sw1.example.com
ping 192.0.2.10
copy running-config startup-config

The first ping tests short-name expansion and resolution. The second tests the complete name directly. The third bypasses name resolution and tests only IP connectivity. Comparing these results helps identify whether the fault is DNS-related or network-related.

Exam-Relevant Notes

• ip name-server configures the DNS server that an IOS device uses; it does not enable DNS server functionality.
• ip domain lookup enables hostname resolution, while no ip domain lookup prevents IOS from attempting DNS lookups.
• ip domain name supplies the default domain suffix for short names.
• ip host creates a static local hostname mapping and does not require external DNS.
• A successful ping by IP address does not prove that DNS resolution works.
• When DNS server IP reachability fails, investigate interfaces, routes, gateways, ACLs, and firewalls before investigating records.
• An IOS DNS server, where supported, is a limited service and is not equivalent to enterprise DNS infrastructure.