DNS view-groups don't work on subinterfaces

Working on an implementation of a split DNS design, I encountered an interesting bug in Cisco IOS: the ip dns view-group command works only on interfaces, but not on subinterfaces. As it’s a pure IP feature, there obviously no reason why it shouldn’t work on anything that has an IP address; obviously someone forgot to insert the correct entry in the parser tables.

Here’s a sample configuration session taken from a 7200-series router running IOS release 12.4(15)T5:

c7200(config)#ip dns view-list Test
c7200(cfg-dns-view-list)#interface Serial 1/0
c7200(config-if)#ip dns view-group Test
c7200(config-if)#encapsulation frame-relay
c7200(config-if)#interface Serial 1/0.1 point
c7200(config-subif)#ip dns view-group Test
                        ^
% Invalid input detected at '^' marker.

DNS views work with EEM

If you've tried to use DNS view/view-list configuration commands in EEM applets, the applets failed as the EEM did not recognize DNS-specific configuration prompts (you could work around this problem with the prompt option of the action cli command). This bug was fixed in 12.4(15)T5, now you can configure DNS views from EEM.

Private domain names

I'm positive the IP prefixes reserved for private use by RFC 1918 are well-known to anyone building private IP networks. Likewise, you should be familiar with reserved AS numbers documented in RFC 1930 if you're building private networks running BGP. But if you know there are reserved DNS domains that can be used to write sample configurations and test code, you're smarter than I was a few weeks ago.

I was writing the June IP Corner article and needed to set up DNS servers within the lab. I used example.com as the domain name and decided to check what would happen if you'd visit the actual www.example.com web site (try it out). It politely referenced me to RFC 2606, which documents the reserved domain names you can use.

As a rule, you should use private IP addresses, AS numbers and domain names in all technical documentation you're producing (unless, of course, you're describing an actual network). If you're forced to use public addresses or AS numbers (for example, to illustrate how the neighbor remote-private-as command works), you should clearly state that the AS numbers are imaginary.

Setup DNS server in your lab

If you do a lot of telnetting in your lab, you could set up an internal DNS server to be able to use router names instead of IP addresses.

Select a router that will act as the DNS server and configure it on all other routers in your lab. For example, if your DNS server has IP address 10.0.0.1, use the following configuration commands:

ip domain-lookup
ip name-server 10.0.0.1

On the DNS server, disable DNS lookup and DNS forwarding (it has nowhere else to go) and define all the routers as IP host names:

no ip domain lookup
!
ip dns view default
 no dns forwarding
!
ip dns server
!
ip host Core-1 10.0.0.1
ip host Core-2 10.0.0.2
ip host POP 192.168.2.1
ip host Ext 192.168.1.5
ip name-server 10.0.0.1

If you also define IP addresses for the WAN links, for example:

ip host serial-1-0.X1 10.0.1.6
ip host serial-1-0.Core-1 10.0.1.1

… you'll get correct hop-by-hop information from the traceroute command:

POP#trace Ext
Translating "Ext"...domain server (10.0.0.1) [OK]
Type escape sequence to abort.
Tracing the route to Ext (192.168.1.5)
  1 serial-1-0.Core-1 (10.0.1.1) 36 msec 24 msec 16 msec
  2 serial-1-0.X1 (10.0.1.6) 24 msec 28 msec 4 msec
  3 Ext (192.168.1.5) 20 msec * 24 msec

Configure DNS servers through IPCP

After I've fixed the default routing in my home office, I've stumbled across another problem: the two ISPs I'm using for my primary and backup link have DNS servers that reply solely to the DNS requests sent from their own IP address range:

When the traffic is switched from the primary to the backup ISP, I therefore also need to switch the DNS servers. Fortunately, this is quite easy to do on a router; you just need to configure ppp ipcp dns request on the dialer interface and the router starts asking for the DNS server address as part of the IPCP negotiation.
The negotiation process can be debugged with the debug ppp negotiation command; it's a bit more complex than usual in my case since the access server has no secondary DNS (only the primary DNS is configured):

Se1/0 IPCP: O CONFREQ [Closed] id 1 len 22
Se1/0 IPCP:    Address 0.0.0.0 (0x030600000000)
Se1/0 IPCP:    PrimaryDNS 0.0.0.0 (0x810600000000)
Se1/0 IPCP:    SecondaryDNS 0.0.0.0 (0x830600000000)
Se1/0 PPP: Process pending ncp packets
Se1/0 IPCP: Redirect packet to Se1/0
Se1/0 IPCP: I CONFREQ [REQsent] id 1 len 10
Se1/0 IPCP:    Address 10.0.0.33 (0x03060A000021)
Se1/0 IPCP: O CONFACK [REQsent] id 1 len 10
Se1/0 IPCP:    Address 10.0.0.33 (0x03060A000021)
Se1/0 IPCP: I CONFREJ [ACKsent] id 1 len 10
Se1/0 IPCP:    SecondaryDNS 0.0.0.0 (0x830600000000)
Se1/0 IPCP: O CONFREQ [ACKsent] id 2 len 16
Se1/0 IPCP:    Address 0.0.0.0 (0x030600000000)
Se1/0 IPCP:    PrimaryDNS 0.0.0.0 (0x810600000000)
Se1/0 IPCP: I CONFNAK [ACKsent] id 2 len 16
Se1/0 IPCP:    Address 10.0.0.34 (0x03060A000022)
Se1/0 IPCP:    PrimaryDNS 10.0.0.10 (0x81060A00000A)
Se1/0 IPCP: O CONFREQ [ACKsent] id 3 len 16
Se1/0 IPCP:    Address 10.0.0.34 (0x03060A000022)
Se1/0 IPCP:    PrimaryDNS 10.0.0.10 (0x81060A00000A)
Se1/0 IPCP: I CONFACK [ACKsent] id 3 len 16
Se1/0 IPCP:    Address 10.0.0.34 (0x03060A000022)
Se1/0 IPCP:    PrimaryDNS 10.0.0.10 (0x81060A00000A)
Se1/0 IPCP: State is Open

The results can be inspected only with the show host command:

GW#show host
Default domain is not set
Name/address lookup uses domain service
Name servers are 10.0.0.10

The access server receiving the call requires no special configuration; the first IP address configured with the ip name-server command is used as the primary DNS and the second one as the secondary. Alternatively, you can configure a different set of DNS servers to pass to the client with the ppp ipcp dns primary-DNS-address secondary-DNS-address interface configuration command.

Unfortunately, the integration with LAN clients is not as seamless as with DHCP; to make the whole solution work, you have to configure the router as a forwarding DNS server and make the LAN clients use the router as the default gateway and DNS server with the DHCP pool configuration:

ip dns server
!
ip dhcp pool LAN
   import all
   network 192.168.0.0 255.255.255.240
   default-router 192.168.0.1
   dns-server 192.168.0.1

Kill browser ads with Cisco router's DNS server

As you might already know, you can use the /etc/hosts file (or its Windows equivalent) to kill unwanted browser ads - just list all the banner-serving sites in you hosts file and set their IP addresses to 127.0.0.1. In my June IP Corner article, Cisco Router: the Swiss Army Knife of Network Services (section Stop the browser ads and banners), I'm describing how you can do the same thing network-wide with a router acting as a DNS server.For those of you who would like to automate this approach and convert a hosts file into a router configuration, here's a short PERL script to do it:

#
# hostsToCisco.pl: converts hosts file into router configuration
#
# Stdin: hosts file
# Stdout: IOS configuration
#
our @line,$i;

while (<>) {
  @line = split(/\s+/,$_);
  next unless $line[0] eq "127.0.0.1";
  for ($i = 1; $i < $#line; $i++) {
    last if $line[$i] =~ /\#/;
    print "ip host $line[$i] 127.0.0.1\n"
  }
}

IP Corner article: Using DNS server on Cisco router

The regular readers of my blog might have wondered in the last few days why I'm focusing so much on the Cisco IOS embedded DNS server. The answer is very simple: I was doing research for my June IP Corner article, Cisco Router: the Swiss Army Knife of Network Services, where you'll find in-depth explanation of what Cisco IOS DNS server can and cannot do, as well as several usage scenarios (including a tip on how to stop unwanted browser ads).

The DNS configuration "challenges"

With the introduction of DNS views in IOS release 12.4(9)T, a number of additional DNS-related configuration commands were introduced. As IOS still supports all the older configuration commands (and the DHCP-acquired DNS servers), the results are not as obvious as one would hope. The IOS documentation is pretty explicit (a nice surprise :), but I still had a bit of a headache figuring it all out, so you might be in the same position.

Let's start with the DNS resolvers (the DNS name servers the router itself uses when it needs to change a name into an IP address or vice versa):

• You can configure the DNS resolvers with the ip name-server global configuration command or the domain name-server configuration command within the ip dns view default.
• Both lists are merged and combined with the IP addresses acquired from the DHCP reply messages to get the final list of the DNS resolvers. You can inspect the final list with the show ip dns view default command.
• The DNS name servers from the DHCP replies never appear in the router configuration.
• If the same IP address is specified with the ip name-server and domain name-server command, only the global (ip name-server) command will appear in the router configuration.

The rules for DNS forwarders (the DNS servers the router uses to answer incoming DNS queries) are a bit different:

• The DNS view the current DNS query should use is determined based on view-list assigned to incoming interface (with the ip dns view-group interface configuration command) or the global view-list (specified with the ip dns server view-group global configuration command).
• The incoming query is (sequentially) sent to the IP addresses configured as dns forwarders in the selected view. No other DNS servers are used.
• If the selected view has no dns forwarders, but contains domain name-servers, they are used as forwarders.
• If the selected view has no dns forwarders or domain name-servers, the query is forwarded as IP broadcast ... unless the selected view is the default view, in which case the first DNS server computed according to the the previous bullet list is used (only one DNS server is used in this case, even if you have configured multiple DNS servers with the ip name-server configuration command).

Unbundle DNS settings from DHCP client

In one of my previous posts I've been writing about the problems I had when the DHCP client on Cisco IOS was messing up the DNS name-servers I've configured manually with the ip name-server configuration command. As is quite usual in Cisco IOS, there's one more know to turn to fix this - the Configurable DHCP Client feature introduced in IOS release 12.3(8)T.

To stop the router's DHCP client from overwriting the static name-server settings, use the no ip dhcp client request dns-nameserver interface configuration command (you can also exclude a few other DHCP options).

DNS resolver in Cisco IOS is auto-configured with parameters from a DHCP reply

If you're using DHCP to get IP interface addresses on your router (using the ip address dhcp interface configuration command), the router will also inherit the DNS resolver settings included in the DHCP reply. Makes sense, but the implementation is "a bit" unexpected: if you configure the DNS name servers manually with the ip name-server address-list command, the ones matching the values in the DHCP reply packet are not included in the running configuration and thus not saved to NVRAM. Even worse, the statically-configured name-servers overwritten by a DHCP reply are lost if the DHCP-configured interface goes down.

To avoid total confusion, you thus have these options:

• Do not use DHCP to acquire IP interface addresses
• Make sure the DHCP server does not send DNS-related parameters (a bit hard if you're using DHCP with your ISP)
• Rely exclusively on DHCP to provide your router with the DNS name server addresses

Here is also an example of what can happen if you mix static configuration with DHCP. We'll start by configuring the name servers and verifying they are configured:

ro#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
ro(config)#ip name-server 192.168.2.1 192.168.2.2
ro(config)#^Z
ro#show run | include name-server
ip name-server 192.168.2.1 192.168.2.2

Next, we'll configure DHCP client on an interface and watch the DHCP debugging to see what's actually going on (only parts of debugging printout are included):

ro(config)#interface FastEthernet 0/0
ro(config-if)#ip address dhcp
...
DHCP: Received a BOOTREP pkt
DHCP: Scan: Message type: DHCP Ack
DHCP: Scan: Server ID Option: 192.168.2.1 = C0A80201
DHCP: Scan: Lease Time: 86400
DHCP: Scan: Renewal time: 43200
DHCP: Scan: Rebind time: 75600
DHCP: Scan: Host Name: ro.address.net
DHCP: Scan: Subnet Address Option: 255.255.255.240
DHCP: Scan: Router Option: 192.168.2.1
DHCP: Scan: Domain Name: address.net
DHCP: Scan: DNS Name Server Option: 192.168.2.2
...
DHCP: Applying DHCP options:
  Setting default_gateway to 192.168.2.1
  Adding default route 192.168.2.1
  Adding DNS server address 192.168.2.2
  Setting default domain to address.net
%DHCP-6-ADDRESS_ASSIGN: Interface FastEthernet0/0 assigned DHCP address 192.168.2.5, mask 255.255.255.240, hostname ro

The name server received in the DHCP reply (192.168.2.2) is now missing from the running configuration:

ro#show run | include name-server
ip name-server 192.168.2.1

Protecting the primary DNS server on your router

In a comment to my post describing how to make a router into a primary DNS server, one of the readers noted that you could easily overload a router doing that ... and he's obviously right.

Apart from having too many valid DNS requests for the zone the router is responsible for, the observed behavior could be spam-related. Just a few days ago when I've discussed the router-based DNS server with my security engineers, they've pointed out that a lot of spammers perform regular DNS attacks trying to poison the DNS cache of unpatched open caching DNS servers.

Obviously, a router is no match in raw CPU power to a high-end server, so even when running the authoritative server on the router, it might not be a bad idea to use a DNS server of your ISP as the secondary DNS and list only the ISP's DNS server in the NS records for your zone. This would deflect most of the traffic (as nobody would know your router is acting as a DNS server), but I would still apply an inbound access-list allowing only DNS queries from the secondary name server on the Internet-facing interface.

Alternatively, you could protect the router with Control Plane Policing and drop excessive DNS request packets, but that would affect the queries you should respond to as well.

DNS views are broken in release 12.4(11)T

The Split DNS functionality introduced in IOS release 12.4(9)T has survived a single maintenance cycle before being broken. While you can still configure the DNS views in 12.4(11)T2 (and they still work), the view names are missing from the router-generated configuration (show running, for example), making the configuration syntactically incorrect. The router will thus reboot without DNS views after you've saved the running configuration to NVRAM.

Use your Cisco router as a primary DNS server

In IOS release 12.3, most Cisco routers can act as primary DNS servers (formerly, this functionality was only available as part of DistributedDirector product), alleviating the need for a host-based DNS server in your perimeter network. To configure a router to act as primary
DNS server for a zone, use the ip dns primary command, for example:

ip dns server
ip dns primary website.com soa ns.website.com
admin@website.com 86400 3600 1209600 86400

Next, you need to define primary and secondary name servers for the domain.
Use the ip host ns command:

ip host website.com ns ns.website.com
ip host website.com ns ns.isp.com

You can also define mail routing for the domain with the ip host mx command:

ip host website.com mx 10 mail.website.com
ip host website.com mx 20 mail.isp.com

Finally, you need to define hosts within your domain (with the traditional form of the ip host command):

ip host ns.website.com 192.168.0.1 ! router's IP address
ip host www.website.com 192.168.1.1
ip host website.com 192.168.1.1 ! alternate for www.website.com
ip host mail.website.com 192.168.1.2

Using a router as a DNS proxy server

A Cisco router running IOS release 12.3 can act as a proxy DNS server - when you configure ip dns server and ip name-server ip-address, it starts forwarding any received DNS requests to the upstream name server.

The router does not act as a recursive server, it just propagates the requests. For example, if the client asks for A record for www.nil.com and the upstream DNS server responds with a NS record for the .com tree, the router will not perform recursive DNS lookups to get the answer (and the resolver code in most clients will fail). The upstream DNS server has to be willing to perform recursive lookups for you.

You can use this functionality (potentially in combination with other external proxies) to set up an environment where the clients do not need to access the Internet directly.