Cisco Router: the Swiss Army Knife of Network Services
by Ivan Pepelnjak
The cost optimization (usually in the cost-cutting direction) in the IT industry is affecting all segments of network design and implementation. For example, IP services like address allocation (Dynamic Host Configuration Protocol – DHCP) and name resolution (Domain Name System – DNS), which were previously distributed throughout the network, are now concentrated on central servers. As these services are vital for the proper operation of IP networks, your remote sites might lose even intra-site connectivity if their link to the core site fails.
Fortunately, you can reap the benefits of investing in Cisco routers: they can provide most network services locally, including DNS and DHCP service. In this article, we’ll focus on how you can use a Cisco router as a localized DNS server, including:
The basic principles of DNS server implementation on Cisco router;
Configuration of router-based DNS server with traditional configuration commands as well as with DNS views introduced in Cisco IOS release 12.4(9)T;
Monitoring and debugging of the router-based DNS server.
The article also covers three interesting applications:
Router acting as internal DNS server in a DMZ environment;
Tracing of DNS requests made by an application;
Blocking of browser ads and third-party banners.
Running DNS Proxy Server on a Remote Router
The simplest DNS deployment scenario is based on the ability of a Cisco router to act as a (introduced in IOS release 12.2): local clients send their DNS requests to the router, which forwards only those requests that are not yet in the local cache. Apart from a slight reduction in WAN bandwidth requirements (which is negligible in today’s gigabit world), the real benefit comes from the significant load reduction of the corporate DNS servers (Figure 1). For example, if a hundred clients on a remote site all start the same application, the load placed on the corporate DNS server is reduced hundredfold with the introduction of a caching DNS server close to the clients.
Note
The Cisco router cannot act as a , performing multiple requests to satisfy a client’s query. It can only propagate the client’s queries to upstream DNS servers and cache the results. In most cases, the end-hosts cannot perform the , thus the upstream DNS has to provide the .
Figure 1
Router as a proxy DNS server
To configure the DNS server on a Cisco router, you have to enter three simple global configuration commands:
DNS lookup has to be enabled with the ip domain-lookup command (enabled by default, but quite often disabled by the operator).
Upstream DNS server has to be defined with the ip name-server address command (You can also define multiple upstream DNS servers).
Optionally, the local domain suffix (like example.com) has to be defined on the router with the ip domain name suffix or ip domain list suffix configuration command.
The DNS server is started with the ip dns server command.
Note
The router will also accept DNS server addresses and the local domain suffix from incoming DHCP replies if you use ip address dhcp on a LAN interface.
After the DNS server has been configured on the router, you have to change the on the end-hosts. The best way to manage these settings is through the DHCP protocol, by which the clients will automatically update their DNS settings every time their IP address lease expires and has to be renegotiated. The relevant parts of DNS and DHCP service configuration on a Cisco router are shown in Listing 1.
Listing 1
Configuring DNS server in combination with a DHCP pool
ip domain name company.com
ip name-server 10.0.0.1
ip name-server 10.0.0.2
ip dns server
!
ip dhcp pool LAN
network 192.168.200.0 255.255.255.0
default-router 192.168.200.1
domain-name company.com
dns-server 192.168.200.1
!
interface Ethernet0
ip address 192.168.200.1 255.255.255.0
As you might expect, the DNS server running on a Cisco router is not completely equivalent to a well-implemented host-based DNS server. Some of the more notable shortcomings are:
Not all responses are cached. For example, the name server (NS) responses are not cached.
Some responses are not cached correctly: the mail exchange (MX) responses are stored in the cache, but expire immediately, making them completely useless.
Handling of multiple name servers is unreliable: Cisco IOS does not adapt to the availability of the name servers; it always starts the querying process with the first name-server specified. If the client resends the DNS query too soon (using the same query ID), the router even fails to switch over to the second name-server.
Configuration of multiple name servers is hard in environments where the router is a DHCP client. Sometimes one of the specified name servers is ignored, more so if they are specified in a single configuration command. Changing the name server configuration is a lottery, the only reliable way to change them is to issue the no ip name-server command first and then reenter the name server address.
Configuring the DNS Server with DNS Views
The DNS server functionality of Cisco IOS was an interesting side-effect of the Distributed Director implementation, which focused primarily on transforming an IOS-based device into an . The command line interface thus always relied on existing configuration commands, be it the ip host command to define DNS zones (more about that in the next section) or existing DNS resolver configuration commands to define the proxy DNS server behavior.
The situation changed dramatically for the better with the introduction of the (which I’ll describe in a later article) and the DNS view configuration object in IOS release 12.4(9)T. With the DNS views, you can bundle all DNS-related parameters in a group using configuration commands described in Table 1.
Table 1
DNS view configuration commands
|
Command
|
Description
|
|
ip dns view name
|
Selects the DNS view configuration mode.
|
|
Domain name string
|
Equivalent to the ip domain-name global configuration command.
|
|
domain retry number
|
Specifies the number of times the DNS request is sent to the first upstream name server before the second server in the list is contacted.
|
|
domain timeout number
|
Specifies the response timeout for queries sent to upstream name servers.
|
|
domain name-server ip address
|
Equivalent to the ip name-server global configuration command.
|
|
domain name-server interface name
|
Uses the DNS information specified in DHCP reply received on the specified interface (you have to use ip address dhcp on that interface).
|
|
dns forwarder ip-address
|
Specifies DNS forwarders (DNS servers used to resolve client queries).
|
|
no dns forwarding
|
Disables DNS forwarding.
|
|
logging
|
Logs all client DNS requests using this view.
|
The parameters configured in the default DNS view (selected with ip dns view default) are also used for router-wide DNS operation (including local name resolution requests and DNS queries received from any client). As these requests do not use the DNS view as such (just its parameters), the requests are not logged if the logging option is configured. To log DNS requests, you have to perform a few extra configuration steps:
After configuring the DNS view, configure an ip dns view-list that uses the configured view.
Attach the DNS view list to the inbound interface (the interface to which the clients are connected) with the ip dns view-group name interface configuration command.
You could also apply a DNS view list to all DNS operations performed by the router with the ip dns server view-group list-name global configuration command.
The complete configuration of the default DNS view and a DNS view list required to log DNS queries received from the LAN interface of a router is included in Listing 2.
Listing 2
DNS configuration using DNS views
ip dns view default
logging
domain timeout 2
domain retry 1
domain resolver source-interface FastEthernet0/0
domain round-robin
domain name-server 10.0.0.1
domain name-server 10.0.0.2
dns forwarder 10.0.0.1
dns forwarder 10.0.0.2
!
ip dns view-list default-list
view default 10
!
ip dns server
!
interface FastEthernet0/0
ip dns view-group default-list
Note
The Split DNS functionality is broken in IOS release 12.4(11)T; the router does not produce correct ip dns view name configuration commands in the running configuration. I would therefore strongly encourage you to wait until the next major IOS release before deploying this functionality.
Monitoring the IOS DNS Server
Prior to the IOS release 12.4(9)T, you could inspect the DNS cache on the router with the show hosts command, which would display the basic DNS resolver settings as well as the complete DNS cache (Listing 3).
Listing 3
Displaying the router’s DNS cache
router#show hosts
Default domain is nil.com
Name/address lookup uses domain service
Name servers are 10.0.0.1, 10.0.0.2
Codes: UN - unknown, EX - expired, OK - OK, ?? - revalidate
temp - temporary, perm - permanent
NA - Not Applicable None - Not defined
Host Port Flags Age Type Address(es)
ns1.cisco.com None (temp, OK) 4 IP 128.107.241.185
www.cisco.com None (temp, OK) 0 IP 198.133.219.25
syd-inbound-a.cisco.com None (temp, OK) 4 IP 64.104.252.248
rtp-inbound-a.cisco.com None (temp, OK) 4 IP 64.102.255.45
sj-inbound-f.cisco.com None (temp, OK) 4 IP 128.107.234.207
sj-inbound-d.cisco.com None (temp, OK) 4 IP 128.107.243.13
cisco.com NA (temp, EX) 0 MX 25 syd-inbound-a.cisco.com
10 sj-inbound-a.cisco.com
10 sj-inbound-b.cisco.com
10 sj-inbound-c.cisco.com
10 sj-inbound-d.cisco.com
10 sj-inbound-e.cisco.com
10 sj-inbound-f.cisco.com
15 rtp-inbound-a.cisco.com
20 ams-inbound-a.cisco.com
dmtns01.turner.com None (temp, OK) 4 IP 64.236.29.150
www.cnn.com None (temp, OK) 0 IP 64.236.91.23
64.236.91.24
64.236.16.20
64.236.16.52
64.236.24.12
64.236.29.120
64.236.91.21
64.236.91.22
The IOS release 12.4(9)T added the show ip dns view command, which displays all relevant DNS settings in a more operator-friendly manner (Listing 4).
Note
Remember: the settings specified in the default view are used for all DNS resolver services (unless overridden with the interface configuration command).
Listing 4
Displaying the default DNS resolver settings
router#show ip dns view default
DNS View default parameters:
Logging is on (view used 2 times)
DNS Resolver settings:
Domain lookup is enabled
Default domain name: nil.com
Domain search list:
Lookup timeout: 2 seconds
Lookup retries: 1
Domain name-servers:
10.0.0.1
10.0.0.2
DNS Server settings:
Forwarding of queries is enabled
Forwarder addresses:
10.0.0.1
To clear the DNS cache, you can use the clear host * privileged command (or the clear host hostname command if you only want to remove a specific cached entry from the DNS cache).
Last but definitely not least, you can use the ip host configuration command to pre-populate the DNS cache (even when the router is not an authoritative DNS server for the specified domain). You can specify the DNS name-to-address mappings (A records) with the traditional ip host name address-list configuration command, or you could use extensions to the ip host command to specify name servers (NS records), mail forwarding rules (MX records) or server location information (SRV records).
Note
The ip host name address command also configures (IN PTR record) in the in-addr.arpa. zone.
Using DNS to Solve Address Translation Issues
One of the most common usages of the router-based DNS server is the efficient implementation of the design. Many small organizations use no DNS internally and rely on external DNS service to provide the name-to-address mapping for their public servers (usually a web server), as shown in Figure 2.
Note
There’s no need to have an internal DNS in Windows-only environment, as the Windows workstations find each other using .
Figure 2
Typical firewall/DMZ/DNS setup of a small organization
Using the setup from Figure 2 in a Network Address Translation (NAT) environment (which is very common today) can lead to interesting connectivity problems: the organization’s workstations cannot reach their public web server. Since there is no internal DNS, the workstations have to use external DNS server to get the IP address of their web server. The returned address is the public IP address assigned to the organization, while the workstations should get to the public web server using its private IP address, as the workstation and the public web server reside on inside NAT interfaces (see Figure 3 for more details).
Figure 3
Address mismatch when using an external DNS server from the internal LAN
You can solve the problem illustrated in Figure 3 with a very smart application of two-way NAT (Dual NAT), but it’s much easier to deploy DNS server on the firewall router which would respond to local DNS queries with the local address of the public web server (configured with the ip host command) as shown in Figure 4.
Note
As the firewall router will also act as a proxy DNS server and generate DNS requests toward an external DNS server, you need to modify the inbound access list on the outside interface to allow return DNS traffic (or inspect the router-generated traffic).
Figure 4
DNS operation with internal DNS server on the firewall router
The relevant parts (DHCP, DNS and NAT) of the router configuration (not including the firewall features or IP access lists) are shown in Listing 5.
Listing 5
DNS, DHCP and NAT configuration of a firewall router
hostname fw
!
ip dhcp pool LAN
network 10.0.0.0 255.255.255.0
domain-name xyz.com
default-router 10.0.0.1
dns-server 10.0.0.1
!
ip dhcp pool DMZ
network 192.168.0.0 255.255.255.240
default-router 192.168.0.1
domain-name xyz.com
dns-server 192.168.0.1
!
!
ip domain name xyz.com
ip host www.xyz.com 192.168.0.2
!
interface FastEthernet0/0
description inside LAN
ip address 10.0.0.1 255.255.255.0
ip nat inside
!
interface FastEthernet0/1
description DMZ LAN
ip address 192.168.0.1 255.255.255.0
ip nat inside
!
!
interface Serial0/0/0
description Link to the Internet
ip address negotiated
ip nat outside
!
ip route 0.0.0.0 0.0.0.0 Serial0/0/0
!
ip dns view default
domain name-server 172.18.1.1
domain name xyz.com
domain timeout 2
dns forwarder 172.18.1.1
ip dns server
!
ip nat inside source static tcp 192.168.0.2 80 interface Serial0/0/0 80
ip nat inside source route-map NAT interface Serial0/0/0 overload
!
route-map NAT permit 10
Trace the DNS Requests with a Router-Based Proxy Server
Sometimes, you need to debug the DNS requests made by an application running on an IP host. For example, to identify the instant messenger traffic with the match protocol msnmsgr protocol-map or match protocol ymsgr protocol-map commands in zone-based firewall configuration, you need to know the names of the relay hosts used by MSN Messenger or Yahoo Messenger to list them as server names in a parameter-map. The easiest way to find these host names is to trace the DNS requests made after the instant messenger application is started and a Cisco router can help you if you don’t have a packet tracer handy.
Since the introduction of the DNS server functionality in Cisco IOS, you could trace all DNS requests with the debug domain command. Obviously, this approach would only work in a tightly controlled lab environment; debugging all DNS requests in a production network would quickly overwhelm the router and generate too much output to be useful. It’s much better to use the logging option available in DNS view configuration (introduced in 12.4(9)T), more so as you can limit the applicability of a logging view to specific source IP addresses with the restrict option within the ip dns view-list definition. The configuration commands needed to define a logging view and limit its usage to a single workstation are included in the Listing 6.
Note
DNS views inherit parameters from the default view. It’s thus unnecessary to specify the upstream name servers in the TraceRequests view, as it will inherit the settings from the default view. However, the hostnames defined for the default view (see the previous section) are not used in the TraceRequests view.
Listing 6
Tracing DNS requests from host 10.0.0.2
ip dns view TraceRequests
logging
!
ip dns view default
domain timeout 2
domain name-server 172.18.0.2
dns forwarding
dns forwarder 172.18.0.2
!
ip dns view-list default
view TraceRequests 10
restrict source access-group TraceDNSRequests
view default 20
!
ip dns server view-group default
ip dns server
!
ip access-list standard TraceDNSRequests
permit 10.0.0.2
The configuration from Listing 6 logs all DNS requests made by the host 10.0.0.2. When starting the Yahoo Messenger on that host, you’ll get the results very similar to the ones in Listing 7, giving you the host names to include in your firewall protocol-map.
Listing 7
DNS requests triggered by Yahoo Messenger
%DNS-6-LOG_ACCESS: DNS View default used for client 10.0.0.3/1196, querying A 'scs.msg.yahoo.com'
%DNS-6-LOG_ACCESS: DNS View default used for client 10.0.0.3/1196, querying A 'insider.msg.yahoo.com'
%DNS-6-LOG_ACCESS: DNS View default used for client 10.0.0.3/1196, querying A 'sip.yahoo.com'
%DNS-6-LOG_ACCESS: DNS View default used for client 10.0.0.3/1025, querying A 'us.js2.yimg.com'
%DNS-6-LOG_ACCESS: DNS View default used for client 10.0.0.3/1196, querying A 'stun.voice.yahoo.com'
%DNS-6-LOG_ACCESS: DNS View default used for client 10.0.0.3/1025, querying A 'relay.voice.yahoo.com'
%DNS-6-LOG_ACCESS: DNS View default used for client 10.0.0.3/1025, querying A 'address.yahoo.com'
%DNS-6-LOG_ACCESS: DNS View default used for client 10.0.0.3/1196, querying A 'pgq.yahoo.com'
%DNS-6-LOG_ACCESS: DNS View default used for client 10.0.0.3/1199, querying A 'update.messenger.yahoo.com'
… rest deleted …
Stop the Browser Ads and Banners
As you’ve seen in the section Using DNS to Solve Address Translation Issues, you can pre-populate the DNS cache in the IOS, making your view of the Internet a bit different from the “global” perspective. You can use this functionality to get rid of most of the ads and banners that clutter the web.
Note
It’s easiest to target the banners produced by third-party marketers. To catch the banners served by the web site you’re looking at, you need in-depth analysis of HTTP requests available with zone-based firewall configuration.
To stop the annoying commercials attached to the web sites you’re visiting, you need to identify the third-party web site that’s serving them. You might inspect the HTML source code of the web page you’re visiting or you could use the DNS request tracing described in the previous section. After you’ve identified the host name of the web server you want to block, simply include an ip host command in the router configuration that changes the IP address of the offending web server to something that will not serve the banners (for example, router’s own IP address or the host loopback address 127.0.0.1). For example, if you’ve identified the ad.tripleclick.net as the offending web server, use the ip host ad.tripleclick.net 127.0.0.1 configuration command to block it.
Note
This technique is very similar to the (or equivalent) file on your workstation to block the unwanted web servers, with the added benefit that it works on a network-wide basis.
Summary
The DNS server functionality is available in every Cisco IOS router delivered in the last few years … and it’s only a single configuration command away. You can use the router as a proxy DNS server to reduce the load on your corporate DNS server, to fix the addressing problems introduced by combining Network Address Translation with an external DNS server or to trace the DNS requests made by an application.
More to explore: