DNS, it's been around for as long as I care to remember (and I can remember a lot) and we all need it to make a human readable IP address into a human recognisable names like www.google.com. When you type a web server name into your browser you don't see it happening but your computer is using DNS to convert that name (e.g. http://www.defaultrouteuk.com) into an IP address...the rest is electricity (and a bit of luck).

DNS or the Domain Name Service is a collection of hierarchical 'databases' (they are flat files usually) which work on devolved authority from the root name servers responsible for that top level domains like .com, .net etc. When your machine needs to resolve the IP address for a web server it uses the DNS service to do that. Devolved what? Well there are a number of root name servers and each one looks after the 'root' of the DNS 'tree'. Examples of the root are .com and .net. When you need to lookup the hostname www.google.com you first whiz off to the root name server responsible for .com who then tells you to ask at 'google'. You then ask 'google' who tells you the IP address for 'www'.

So, if we are network engineers what do we care about DNS? Well of course sometimes it's nice not to have to remember IP addresses all the time. It is also essential to use DNS in things like NBAR access-lists. Allowing you to lookup hostnames using DNS is a good thing. When you telnet to or from a device then the device may need to perform a DNS lookup either on your incoming connection (for logging or some access-list requirement) or else for the outgoing connection (for example when you wish to connect to routerX using it's hostname). I tell you one time that you wished you turned lookup off though...when you fat finger a hostname and have to wait a long time to get your prompt back (unless you Ctrl+6+x of course). So we need to allow DNS lookups from our IOS device but also you also need to consider DNS lookup requests for hosts behind your filtering routers.

DNS as a protocol

What port and protocols do we need to consider to allow the lookup? Well, just like most things in networking, it depends.

DNS as a service function runs on both TCP and UDP protocols but is listening on port 53. A client lookup will use UDP to initiate the lookup but will use a client port greater than 1023 and destination port of 53. If the response to the query is very large then the server (daemon) will send the information back to the client using TCP. Very large queries are most commonly seen for server to server DNS transfer (XFER) requests so if you are running multiple DNS servers acting as primary, secondary, tertiary etc then TCP will be used to move information around.

Right, the nuts and bolts of it all for the network engineer then. What would the various DNS request types look like in an access-list...here are a few scenarios.

Outbound DNS lookup from hosts behind a filter router
Inbound DNS lookup from Internet hosts to our DNS server(s)
DNS large request support between servers and clients

OK so we need to use an extended or named access-list because we are going to need to support ports (remember the standard ACL has no support for ports). The scenario will work on applying an INBOUND ACL to the  Internet facing interface.

Now I have seen other resources talking of placing the acl 'outbound' on the inside (private) side of the router...I guess I don't have strong feelings one way or the other on the placement however I would say that I tend to err on the side of caution and try to drop bad or unwanted traffic as soon as I see it rather than allow it to traverse the router and consume resources. Up to you.

Outbound access-list permitting DNS lookup outbound

access-list 100 permit udp any eq 53 gt 1023

This acl is applied inbound on the outside interface. We are looking therefore at a source of 'any' because we have no idea of the source of the traffic (the DNS server responsible for that domain). The source port however is known as UDP port 53. The destination for a client lookup using for example nslookup or dig would be a udp port of 1024 or higher.

Inbound access-list permitting DNS ;ookup from our DNS server for our domain.

access-list 100 permit udp any gt 1023 eq 53

Our DNS service is running on a host with IP address

Allow for large DNS lookups, queries and xfers.

access-list 100 permit tcp any eq 53 gt 1023

The access-list, again applied inbound on the public facing interface, will allow for TCP DNS traffic from any host to our private network hosts.

Clearly we all need DNS and in the modern firewalls and application aware routers we can be excused for not knowing the basics...but here they are. Using more modern access-lists using techniques such as NBAR or reflexive can remove a lot of the security flaws with standard and extensive access-lists, so our access-list examples are NOT the complete answer, just a demonstration. 

By the way - that annoying wait you get when you fat finger a telnet command? Normally you would sit there with a dead console waiting while the lookup times out...or you just hit Ctrl+6+x and it'll crash out...then you do that again...then again to kill it. You can simply disable DNS lookups all together and save the issue....this command is for you:

router(config)# no ip domain-lookup

Have you ever thought about using IOS as a DNS server? Well you can, but like DHCP server in IOS what you can do is not necessarily what you should do.

First enable the DNS server daemon (listener)

R1(config)#ip dns server

Now enable lookup (remember this is on by default so unless you disabled it you won't need to do this)

R1#(config) ip domain-lookup

OK so now lets put some hosts into our 'database'.

ip host R1
ip host R2

If we configured an IOS DNS client to point at R1 for hostname lookup (using ip name-server it would resolve using the hostnames we just configured.

IOS dns client lookup

So far we've just shown how to perform hostname lookups but what if we wanted more DNS information like domain names? Well IOS doesn't disappoint...

R1(config)#ip dns primary defaultrouteuk.com soa R1.defaultrouteuk.com defaultrouteuk.com support@defaultrouteuk.com 300 60 3600 86400

Here we've configured the domain of 'defaultrouteuk.com'. The 'Start of Authority' record shows we've delegated authority for lookup to R1. Now we'll setup the client to lookup hosts inside that domain...

R2(config)#ip domain-name defaultrouteuk.com

OK so a ping now for the domain?

Screen shot 2011-08-17 at 02.05.30

Ok so we see that pinging R1 doesn't work anymore because we're not in that domain anymore on the client. Pinging the hostname R1.defaultrouteuk.com fails too, because the server doesn't have a hostname record for that...oh man

Screen shot 2011-08-17 at 02.05.21

Right so we've put the hostname in the server...can the client lookup properly now?

Screen shot 2011-08-17 at 02.05.42

Awesome! It'll even work if we ping R1 too because we'll lookup inside that 'defaultrouteuk.com' domain from the client (remember we used the 'ip domain-name' command?)

So like I said before IOS DNS server is a 'fix' but it's NOT a solution to DNS for you and you should use a dedicated DNS server for the job like BIND or Windows (shudder) Server (wretch). Certainly it will work for hosts but it's unworkable to manually put in lots of records. It won't support things like record type beyond A and SOA records so MX, PTR, TXT etc are not going to be available to you.

Good luck with your studies!
View Comments
© 2011 defaultrouteuk.com

Cisco, IOS, CCNA, CCNP, CCIE are trademarks of Cisco Systems Inc.
JunOS, JNCIA, JNCIP, JNCIE are registered trademark of Juniper Networks Inc.