To use the Internet, we use a very handy service called Domain Name System or DNS for short. It’s like a simple phone book but for computers. It makes it so that we don’t need to remember a particular IP address, just the corresponding hostname of a computer. When we start using IPv6, DNS will become more important.
In this article, we’ll see DNS in action and how to simulate the operation of real domain servers. DNS is more complex than the following examples show, but these should be enough to understand the basics.
DNS is a simple directory service; it provides IP addresses related to domain names and vice versa. For example, the www.yahoo.com name is related to the IP address of 22.214.171.124. The ‘com’ is the so called TLD (top-level domain) part of the name, ‘yahoo’ is the second-level domain (SLD) and ‘www’ is the name of a machine in this domain. DNS names can be more complex also.
The names are hierarchical, and so are the DNS servers. The database behind the service is distributed among them throughout the world, just see http://www.root-servers.org/. On the top of the hierarchy are 13 root servers (of course not individual machines, but server farms instead). These know the reachability information of the TLD servers, which in turn know the reachability of the SLD servers and so on.
The so-called authoritative servers know the exact information about a name/address correlation in a zone. A root server won’t know the answer to the query about a particular address or name, it’s just relays the query towards a more authoritative server. But when a query is successfully answered, DNS servers can cache the data so that next time they can answer directly to the client.
The DNS database consists of Resource Records or RRs, which are located in zone files on the servers. Each server is responsible for a zone which is a part of the whole DNS tree. Zone files start with the SOA (Start of Authority) record, which contains the parameters of the zone: the primary name server, the email of the administrator, the serial number to track the modifications and the timing parameters for the synchronization of the other DNS servers (there are a minimum of two independent DNS servers for any given zone). The NS record gives the name of the primary DNS server of the zone. The MX (Mail eXchanger) record tells the name of the mail server of the domain. The A record gives the address pair of a domain name. In IPv6 this is the AAAA record, but the purpose is the same.
There’s a command line utility with the same name in Windows and Linux too, which can be used to test and query the DNS. This is nslookup, which has an interactive mode also. First try this in a real computer then continue with a Packet Tracer lab. I’ll use the Windows version, but the Linux version is very similar.
Launch a CLI window, and type in the following:
The output shows the local DNS server address, in this case 192.168.0.1. This is my home router’s address and of course it’s not a real DNS server, it’s just a caching-only one. After this the “non-authoritative answer” means that the answer didn’t come directly from the DNS server of cisco.com, but from my own DNS server instead. We can see that this web server can be reached by IPv6 and has some aliases as well.
Now try the interactive mode of nslookup by just entering the command and pressing Enter. If we enter a domain name, it works the same as entering it on the command line, but in this mode we have a lot more possibilities. Enter help and we can see a lot of subcommands. For example, we can change the server we query with the server ip_address command, or change the type of the query.
Let’s simulate a situation where we have a caching-only name server and want to know the IP address of a host. In this case the server needs to know just one thing: where to find a root name server, because using this information we can find the authoritative server recursively. But where do we get the IP address of a root server?
Nslookup can help: enter the keyword root, and it selects a.root-servers.net as the default server. Now query another site, for example the homepage of my good old university: www.bme.hu. This time we get a list containing the servers that supply the “hu” zone (more precisely, the “hu.” zone, because the starting point is always the root zone, identified by “.”, but we don’t need to indicate it in this case). Change the active server to one of them, for example to server 126.96.36.199 then repeat the query. Now we’ll get the list of the name servers for the “bme.hu” zone. Set 188.8.131.52 as the server and query again, and it should now tell us the IP address required: 184.108.40.206.
So, by using the data that came from the servers along the way, we can find the information we need and we can cache it for future reference. You may have noticed that the answers for our queries included the IPv6 addresses as well, it’s important because soon we have to move on to IPv6 addressing and DNS must be prepared for this.
Finally we try to answer the following question: what is the IP address of the mail server responsible for the cisco.com domain? In other words, what server do we need to connect when we want to send an email destined to firstname.lastname@example.org? In order to do this we need to set the query type to MX in nslookup, because the MX record will tell us the mail server’s name in a particular domain. So let’s do the following:
Firstly, in this case I’ve set my DNS server to one of Google’s public servers: it has an address which is very easy to remember. Then I’ve set the query type to MX. It can be done more easily, as it can be seen later: we don’t have to write, for example, ‘querytype=mx’, just enter ‘q=mx’. After entering the domain name we get the answer, but in this case we need another query to know the IP addresses. Before this we need to set back the query type to A as address so we can gather more information from DNS as it can be seen at first sight.
Now let’s see what can be simulated in Packet Tracer. We’ll use a topology in which there’s a root DNS server, one of the authoritative servers of the ‘.com’ zone, one of the DNS servers of ‘.cisco.com’ and the DNS server of a fictive ISP. A client site is configured to reach the Internet through the ISP router, and we can examine the packet flow of DNS queries. The base version of the PT file contains just the IP addressing, while the second one has fully configured DNS servers. I recommend using the former to build the DNS configuration after we discuss the details. The topology is the following:
Let’s start with a simple query on PC1. Start the Command Prompt application and enter nslookup www.cisco.com. Maybe that the first lookup doesn’t succeed; if so, try to ping the DNS servers from PC1, then try again. The answer will be non-authoritative and tells the IP address of the site. Which DNS server answered this query? The configured one: dns.isp.com, our caching-only server at 220.127.116.11. Let’s examine its DNS configuration on Services / DNS tab:
It can be seen that this server doesn’t have the required data, but it knows about the root DNS server and the .com DNS server. In reality, it’s enough for a caching-only server to know about the root server, but Packet Tracer doesn’t handle the ‘.’ zone perfectly, so we have to do this little trick. Now it can be deducted that our server queried the other servers for the missing information, provided it for us and cached it for future reference. Let’s click the DNS cache button and see this:
Next time this server can answer immediately without querying the others. In a real lab we can use other DNS utilities as well, which can tell the time required for a given query (for example, try dig – Domain Internet Groper). The first in this case takes more time than any subsequent one, because the answer from the local cache is much faster than a recursive query.
Before we continue, some words about the DNS configuration data on Resource Records page section of dns.isp.com. We can see NS and A records. Because this is a caching-only server, it needs to know the name of a root server and its IP address. The NS record tells the name, the A record tells the address. Unfortunately PT doesn’t support the ordering of the records, but it’s still easy to understand.
Before we move on, let’s clear the DNS cache on all the DNS servers by clicking the DNS Cache button in the DNS service configuration window, then Clear Cache. Now enter simulation mode and set the event filters so that only DNS remains visible. Make the previous query again and look at the packet generated by PC1.
The interesting portion of it is in Layer 4: we can see that DNS uses UDP by default (we need to mention that it can use TCP too, but UDP is more common). The destination port is 53 which is reserved for DNS, so if you have a firewall and want DNS to operate you need to open that port. Transmit the packet by clicking Capture / Forward a few times until it reaches the configured DNS server. It’s not a big surprise that it won’t answer immediately, but try to collect information from other servers. In this example it starts with com.root but in reality it would start at the root server, at the top of the hierarchy, but as I mentioned PT doesn’t handle this.
So click for a few times and we can see that com.root doesn’t know the answer either, so in turn it asks for dns.cisco.com, which is the authoritative server for the required domain name. It must know the IP address of the given domain name – if it doesn’t, the name doesn’t exist. The answer goes back to com.root, and then back to dns.isp.com, and finally PC1 will get it and put it in its DNS cache. On a real Windows PC we can observe that by issuing the ipconfig /displaydns command, and we can also delete the content also, by issuing the ipconfig /flushdns command.
Next is to examine a bit of the resource records of a given server, namely on dns.cisco.com, because it has more common configuration than the root servers, for example. The configuration starts with the SOA (Start Of Authority) record. Click on it and examine the settings. The Name field contains the name of the domain: it should be cisco.com precisely, because this is an absolute name. The Primary Server Name contains the name of the primary or master DNS server for the domain. The administrator configures the domain data here, and the other (secondary or slave) servers synchronize their database to it through a process called zone transfer.
The synchronization is periodic, and the Refresh Time parameter tells, in seconds, when to connect to the master server. If the connection fails, the secondary servers must try again, which is specified by the Retry Time parameter. If the master still isn’t reachable after the Expiry Time elapses, the secondary servers will not be authoritative servers anymore. The Minimum TTL value specifies the time in which the data of the SOA record can be cached on the client side. Its purpose is to reduce the number of DNS queries. Finally, the Mail Box parameter is the email address of the main DNS administrator, but we cannot use the @ here, as it is reserved for other purposes in the zone file, so we consider the first dot as the separator.
The NS and A records are lot more simple and we already met them. PT supports one more RR: with the CNAME record we can define aliases for a domain name. For example, www.cisco.com can be reached under the name of ftp.cisco.com also if we put ftp.cisco.com into the Name and www.cisco.com into the Host Name field.
DNS has a lot more information to know, but unfortunately for now Packet Tracer only supports the basic things we saw in this article. Still, this is a good starting point to be a DNS expert.