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 outboundaccess-list 100 permit udp any eq 53 220.127.116.11 0.0.0.255 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 18.104.22.168 eq 53
Our DNS service is running on a host with IP address 22.214.171.124.
Allow for large DNS lookups, queries and xfers.access-list 100 permit tcp any eq 53 126.96.36.199 0.0.0.255 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
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 192.168.2.1
ip host R2 192.168.2.2
If we configured an IOS DNS client to point at R1 for hostname lookup (using ip name-server 192.168.2.1
) it would resolve using the hostnames we just configured.
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 email@example.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?
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
Right so we've put the hostname in the server...can the client lookup properly now?
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!