DNS and Split DNS on IOS

Domain Name System (DNS) is one of the most fundamental network services, without which Internet as we know it today would be meaningless. Generally speaking, the purpose of the DNS is to provide “mapping” between human readable domain names, like for example ipexpert.com and IP addresses, understood and used by computers and routers. Again, generally speaking, DNS services are provided by DNS servers. If you are using Cisco router with newer IOS, you may not need a server for a very basic DNS functionality. Sometimes, even a bit trickier configurations can be done using IOS. Let’s examine how.As it is always the case, just writing and talking about things makes no sense. We want to see things work. To do that, we’ll use a simple network configuration shown on the diagram below.

In this network, routers R2, R4 and R5 represent the internal network, using the 192.168.0.0/16 address space and the domain “ipexpert.com”. Router R6 represents the Internet and will be using the domain “example.com”. Our internal network is running OSPF and has full reachability. Connectivity with the Internet is done using simple default static route. Here is just a quick look at the routing tables of R4 and R6.

R4:

R4#show ip route ospf
O    192.168.25.0/24 [110/128] via 192.168.24.2, 00:29:27, Serial0/0/0.402
     192.168.0.0/32 is subnetted, 3 subnets
O       192.168.0.2 [110/65] via 192.168.24.2, 00:29:57, Serial0/0/0.402
O       192.168.0.5 [110/129] via 192.168.24.2, 00:29:17, Serial0/0/0.402
O*E2 0.0.0.0/0 [110/1] via 192.168.24.2, 00:11:50, Serial0/0/0.402

R6:

R6#show ip route | begin ^Gateway
Gateway of last resort is not set

     172.16.0.0/16 is variably subnetted, 2 subnets, 2 masks
C       172.16.26.0/24 is directly connected, Serial0/1/0.26
C       172.16.0.6/32 is directly connected, Loopback0
S    192.168.0.0/16 is directly connected, Serial0/1/0.26

Let’s say that the goal in our configuration is to have R5 act as the DNS server for “ipexpert.com” domain. All internal hosts should be able to resolve router names in the domain using services provided by R5.

One part of the configuration is obvious. We should configure R2, R4 and R5 to use DNS services to resolve names and configure them to be in “ipexpert.com” domain. Easily done.

R2, R4 and R5:

ip domain-name ipexpert.com
ip domain-lookup
ip name-server 192.168.0.5

The next step of the configuration is to configure R5 to act as the primary (authoritative) DNS for our internal domain. If you are using 12.4T IOS, this is again, something that can be easily done.

R5:

ip dns server
ip dns primary ipexpert.com soa r5.ipexpert.com training.ipexpert.com

The first line of this configuration may be obvious – we’re simply enabling DNS server functionality on R5. The second one may need a bit of an explanation. In that line, we are enabling authoritative DNS for domain “ipexpert.com, with SOA (Start Of Authority) record that indicates the primary DNS server as “r5.ipexpert.com” and contact person as training@ipexpert.com. Now, R5 will answer DNS queries from other hosts. However, it doesn’t have any information to respond with. We need to populate the DNS table. Again, this is a very easy task. Let’s populate the table for Loopback0 addresses of R2, R4 and R5.

R5:

ip host R2.ipexpert.com 192.168.0.2
ip host R4.ipexpert.com 192.168.0.2
ip host R5.ipexpert.com 192.168.0.2

Let’s see if our configuration works. We will test from R4.

R4:

R4#show hosts
Default domain is ipexpert.com
Name/address lookup uses domain service
Name servers are 192.168.0.5

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)

R4#ping r2

Translating "r2"...domain server (192.168.0.5) [OK]

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.0.2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/2/4 ms

R4#show hosts
Default domain is ipexpert.com
Name/address lookup uses domain service
Name servers are 192.168.0.5

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)
r2.ipexpert.com           None  (temp, OK)  0   IP    192.168.0.2

Now, we see that our lookup has worked. This was an easy part.

What if we wanted to be able to look-up names external to our domain – those that exist on the Internet? In our case, the domain “example.com”, configured on R6, as below.

R6:

ip domain-name example.com
ip domain-lookup
ip name-server 172.16.0.6
!
ip dns server
ip dns primary example.com soa r6.example.com test.example.com
!
ip host R6.example.com 172.16.0.6

We could, of course configure our R5 to use R6 as the name server and forward the requests to R6. This is an easy configuration, shown below.

R5:

ip name-server 172.16.0.6

If we try to ping R6 by it’s name from R4, we’ll be successful:

R4:

R4#ping r6.example.com

Translating "r6.example.com"...domain server (192.168.0.5) [OK]

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 172.16.0.6, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 4/5/8 ms

At first glance, we are successful and we can move on – job well done.

There is a minor issue though… In a geographically disperse environment and modern-day Internet, where most major content providers deliver content based on geo-location, using this approach may not be as optimal. Imagine for example that R4 was in California and R5 in Michigan. When R4 tries to access R6 by name, it will query R5 for the address and R5 will query R6. R6 is unaware that the original request is coming from R4 and may optimize its response based on the IP address of R5 and not R4. Take a look at this process on R6 when I try to ping it by name from R4.

R6:

R6#debug domain
Domain Name System debugging is on

  DNS: Incoming UDP query (id#41402)
  DNS: Type 1 DNS query (id#41402) for host 'r6.example.com' from 192.168.25.5(62872)
  DNS: Servicing request using view default
  DNS: Reply to client 192.168.25.5/62872 query A
  DNS: Finished processing query (id#41402) in 0.000 secs
  DNS: Sending response to 192.168.25.5/62872, len 48

We can clearly see that the request is coming from R5 and not R4. How can we solve this problem?

The solution lies in so-called split DNS. This approach creates multiple DNS “views”, which are used based on different criteria. In our case, criterion is simple – if a DNS query for “ipexpert.com” comes, use 192.168.0.5 as DNS, otherwise, use external DNS server, 172.16.0.6. The question that needs answering is where to configure this.

Theoretically speaking, we can configure this anywhere in the network – on clients, on routers or DNS server itself. Configuring this kind of functionality on clients does not scale, configuring it on gateways makes sense and configuring on DNS servers may cause additional load on them. In our case, I will use 2nd approach and configure this functionality on R2.

What I am going to do is configure R2 to process incoming DNS queries from R4 and forward them to either R5 or R6 based on the domain name being asked. To make this work though, I will need to change the configuration on R4 to use R2 as the DNS server. Let’s take a look, starting with the easy bit.

R4:

no ip name-server 192.168.0.5
ip name-server 192.168.0.2

After this, I need to enable DNS server functionality on R2 and create views. I will have two DNS views – one default, that will process everything except “ipexpert.com” domain. The other view, which I will call INTERNAL, will be used to answer only queries for our internal domain. Let’s take a look.

R2:

ip dns server
!
no ip name-server 192.168.0.5
ip name-server 172.16.0.6
!
ip dns view INTERNAL
 domain name-server 192.168.0.5
!
ip dns name-list 1 permit .*.ipexpert.com
!
ip dns view-list OurView
 view INTERNAL 10
  restrict name-group 1
 view default 99
!
interface Serial0/1/0.204
 ip dns view-group OurView
!

It is important to not that the actual query will not be redirected by R2, rather the router will act as a forwarding DNS, meaning that it will generate a new query towards the appropriate DNS server, wither internal or external. This means that the same problem with geo-location as described before may still exist, but if we assume that gateways are in the same site as hosts, this is a non-issue.

Let’s test with the same ping as before.

R6:

  DNS: Incoming UDP query (id#5575)
  DNS: Type 1 DNS query (id#5575) for host 'r6.example.com' from 172.16.26.2(59824)
  DNS: Servicing request using view default
  DNS: Reply to client 172.16.26.2/59824 query A
  DNS: Finished processing query (id#5575) in 0.004 secs
  DNS: Sending response to 172.16.26.2/59824, len 48

We can now see that the DNS request came from R2. Does our split DNS work? Let’s enable the same debug on R5 and ping R5 by name from R4.

R5:

R5#debug domain
Domain Name System debugging is on

  DNS: Incoming UDP query (id#30360)
  DNS: Type 1 DNS query (id#30360) for host 'r5.ipexpert.com' from 192.168.25.2(56007)
  DNS: Servicing request using view default
  DNS: Reply to client 192.168.25.2/56007 query A
  DNS: Finished processing query (id#30360) in 0.000 secs
  DNS: Sending response to 192.168.25.2/56007, len 49

It worked like a charm.

Happy studies!

–
Marko Milivojevic – CCIE #18427
Senior Technical Instructor – IPexpert
Join our Online Study List

DNS and Split DNS on IOS, 4.2 out of 5 based on 5 ratings

Tags: CCIE Routing & Switching, CCIE Service Provider, dns, split-dns