You have to think of and understand the Internet’s Domain Name Service -DNS- as a System.
The DNS is the system which, in its primary function, converts Internet domain names that you type into URL bars, or hyperlinks that you click on a web page into numeric IPv4 and/or IPv6 addresses. In a sense, the DNS system is the phone book of the Internet (for those who don’t know, a phone book was a list of numbers and names). You can imagine this database looks something like this:
| IP Address | URL/Name |
| 165.227.86.21 | cellstream.com |
| 2604:a880:400:d0::850:9001 | cellstream.com |
| 138.197.71.240 | netscionline.com |
| 2604:a880:800:a1::7e4:8001 | netscionline.com |
To understand how this works, let’s start with your computer – we will call it the client. You type in some URL into your web browser and hit <Enter>. Here is an example:
Your computer needs to translate the Fully Qualified Domain Name part into an IP address.
The first thing your system does is it looks at its local DNS Resolver Cache. If you have visited that same site in the last 24 hours, it will be there, and job done, we can set up a TCP connection to that server and then do an HTTP GET.
To display or clear the DNS resolver cache in Windows, see the examples below:
Now, let’s say the answer is not in the local DNS resolver cache. Your system sends out a DNS request to your local ISP’s Recursive Resolver: If the answer is in the cache on that system, a response is received and your local cache is updated. Now you can connect to the target web site”
Great. But want if there is nothing at the local ISP Resolver? This is where life gets interesting.
First, the ISP resolver send a message to one of 13 DNS Root server addresses. More on the Root Servers below. These are Anycast Addresses, and represent many many actual physical servers:
Contrary to what many will tell you, the Root Server response does not contain the answer (as it once used to many years ago). Today what happens is the Root Server provides which Top Level Domain (TLD) server to reach out to:
Next, the ISP recursive server queries the TLD server. This server then provides an Authoritative Name Server – again, not the answer itself:
Now we can ask the Authoritative Server and we get an answer! This is then passed back to the Client and both their caches are updated:
Now we can go ahead and communicate to the target web server:
Job done!
Manually Adding Entries to the DNS Cache
You can certainly do this, and in the event of a DNS system issue, you can continue to reach the systems you add. Simply open the following file with any editor in Administrator mode: C:\Windows\System32\drivers\etc\hosts
This file has no extension. By default everything is commented out. Just add IP Address – TAB – Name and even if you flush your DNS Resolver Cache, these entries will always be there! Below is the deault resolver cache file:
DNS Security
The DNS has always been and will always be an attack target. Without the DNS translation, the Internet (for most) stops working.
There is a long history of attacks (not all are shown):
- September 6, 1996: Panix, the third-oldest ISP in the world, was the target of what is thought to be the first DoS attack using a SYN flood attack which brought down its services for several days while hardware vendors, notably Cisco, figured out a proper defense
- February 6&7, 2007: A BOTNET attacks four of the 13 root servers (F, G, L and M), three .info servers, and a set no one’s probably heard of: Fast flux DNS spammy something-or-other. Details on the 2007 attack can be found here: https://www.dns-oarc.net/files/dnsops-2007/Kristoff-Feb07-attacks.pdf
- About 4500-5000 bots on Microsoft Windows boxes
- About 65% from South Korea
- About 19% from the United States
- About 3.5% from Canada
- About 2.5% from China
- The rest from various places
- The Controller • HTTP-based, located in the USA • Bots located it via DNS (there was a backup name) • Was still doing DDoS attacks up until late May
- October 21, 2016: the Dyn attack was a series of distributed denial-of-service attacks (DDoS attacks), targeting systems operated by DNS provider Dyn.
- May 20, 2020: the NXNSAttack, is a DDoS attack and leverages a flaw in the DNS delegation mechanism to force DNS resolvers to generate more DNS queries to authoritative servers of attacker’s choice, potentially causing a botnet-scale disruption to online services. Details on the May 2020 attack can be found here: https://thehackernews.com/2020/05/dns-server-ddos-attack.html
There have also been DNS Hijacking attacks:
- In 2010, we saw DNSCHANGER, a piece of malware that ran on a victim’s machine and changed their DNS server via Windows API calls
- In 2014, we saw an evolution of this principle in the form of SOHO malware that sent many requests trying default passwords for many brands of routers on 192.168.0.0, 192.168.1.1, 10.0.0.1, etc. attempting to find the victim’s router and change its DNS server
Anycast was the technology that began to modify the DNS architecture. Anycast has made the DNS system much more robust.
DNSSEC (Domain Name System Security Extensions), is intended to secure DNS by adding a cryptographic layer to DNS information. The root zone of the Internet was signed for DNSSEC in July 2010 and the .com Top Level Domain (TLD) was finally signed for DNSSEC in April 2011.
The Root Servers
There are 13 root server addresses in the Internet DNS. The root servers are controlled by ICAN and IANA, and operated by different organizations (to see source go to https://www.iana.org/domains/root/servers):
| HOSTNAME | IP ADDRESSES | MANAGER |
| a.root-servers.net | 198.41.0.4, 2001:503:ba3e::2:30 | VeriSign, Inc. |
| b.root-servers.net | 192.228.79.201, 2001:500:200::b | University of Southern California (ISI) |
| c.root-servers.net | 192.33.4.12, 2001:500:2::c | Cogent Communications |
| d.root-servers.net | 199.7.91.13, 2001:500:2d::d | University of Maryland |
| e.root-servers.net | 192.203.230.10, 2001:500:a8::e | NASA (Ames Research Center) |
| f.root-servers.net | 192.5.5.241, 2001:500:2f::f | Internet Systems Consortium, Inc. |
| g.root-servers.net | 192.112.36.4, 2001:500:12::d0d | US Department of Defense (NIC) |
| h.root-servers.net | 198.97.190.53, 2001:500:1::53 | US Army (Research Lab) |
| i.root-servers.net | 192.36.148.17, 2001:7fe::53 | Netnod |
| j.root-servers.net | 192.58.128.30, 2001:503:c27::2:30 | VeriSign, Inc. |
| k.root-servers.net | 193.0.14.129, 2001:7fd::1 | RIPE NCC |
| l.root-servers.net | 199.7.83.42, 2001:500:9f::42 | ICANN |
| m.root-servers.net | 202.12.27.33, 2001:dc3::35 | WIDE Project |
Why are there 13 servers?
The answer is history, protocols and mathematics. When the DNS system was designed, the size limit of DNS responses using the User Datagram Protocol (UDP) was set to 512 bytes (look at Section 2.3.4 of RFC 1035). Starting with a packet size requirement of 576 bytes, if you work backwards, you have a 20 byte IPv4 header followed by an 8-byte UDP header, then the UDP payload could be up to 548 octets long (576-20-8=548). If you also allow for up to 40 bytes of IP options, then in order to ensure UDP packet acceptance under all circumstances the maximal UDP payload size should be 508 octets. The DNS use of a maximum payload of 512 bytes is not completely inconsistent with the math, but it is off by 4 bytes.
This 512-byte size limit of DNS packets still holds today, in that a query is supposed to be answered by a response with a DNS payload no greater than 512 octets long. If the actual response would be greater than 512 octets, then the DNS server is supposed to truncate the response to fit within 512 octets, and mark this partial response as truncated.
Now let’s say you are getting the root server information to begin your database (called a DNS priming query), you will receive a DNS response packet no longer that 512 bytes of payload. Therefore only 13 IPv4 addresses and server names will fit!
What about IPv6, you may be thinking. The answer there is that you will get a partial set of answers with no indication of what is missing. For example you might get a fist packet of 508 bytes that contains IPv6 addresses for A through J, with the remainder IPv4 addresses arriving in a second packet. Some root servers will answer differently. If you wanted everything, you need a 1097 byte payload (see RFC 6891).
Where are these servers?
First, there are not just 13. That used to be the case, but thanks to Anycast technology, we now have hundreds of servers sharing the 13 addresses. You can view these servers at root-servers.org:
On that same web page (at the bottom), you can select any one of the 13 organizations and view the details of their servers:
If you just wanted to get a text list of all 13 root servers and addresses, navigate in a web browser to: https://www.internic.net/domain/named.root
Another fun thing to do is run ‘dig’ (stands for Domain Information Groper) on your MAC or Linux computer.
- (Note 1: you used to be able to download dig for your Windows machine but now there is a more complete solution called “bind” – see this web site for more information)
- (Note 2: another DNS tool is called ‘nslookup’, which also runs on the MAC but has been deprecated on Linux, look towards the end of this article for information on nslookup)
We see the 13 root servers being shown.
Let’s dissect the output from the dig command. The format of a dig response has five sections:
- The HEADER contains summary and status information, which we look at in more detail later.
- The next four sections contain information in standard Resource Record (RR) format as they may appear in a zone file.
- The QUESTION SECTION reflects the question or query received by the responding server. In the above case, the dig command was interpreted to be “get me the NS RRs for the root”.
- The ANSWER SECTION may be empty if our question was not answered or may contain one or more RRs, which are the answer to our query. In the example above, it contains the NS RRs for the root servers (a.root-servers.net to m.root-servers.net). Note especially the infamous dot on the left hand side of each result line in this section, which is the short form for the root.
- The AUTHORITY SECTION normally contains one or more NS RRs for servers that are authoritative for the domain in question. In the above case, it is not present simply because the ANSWER SECTION already contains this information.
- The ADDITIONAL SECTION contains any information the responding server thinks may be useful and has available. In this example, and in most cases, it contains the A (Address) RRs of the authoritative name servers that our local name server has used.
The really interesting stuff is in the HEADER. The first thing to check is the status. In this case, NOERR means the command was successful (see the Dig Header Values sidebar for a complete list). The flags in this case are qr, indicating we received a query response that seems pretty reasonable; rd, indicating our dig message requested recursive services; and ra, signifying that this server supports recursive service (again, see the Dig Header Values sidebar for a complete list of possible flags). The HEADER also contains the id, which uniquely identifies this request/response pair and finally summarizes how many RRs we have in each section.
Here is a list of value references (keep in mind that Wireshark will annotate all of these items):
- id: the 16-bit message ID supplied by the requester (the questioner) and reflected back unchanged by the responder (answerer). Identifies the transaction. Range 0 to 65535.
- Flags may be one or more of the following values:
- AA (Authoritative Answer): set if the response was received from a zone master or slave.
- TC: (TrunCation): length greater than permitted, set on all truncated messages except the last one.
- RD (Recursion Desired): set in a query and copied into the response if recursion is supported.
- RA (Recursion Available): valid in a response and, if set, denotes recursive query support is available.
- AD (Authenticated Data), DNSSEC only: indicates that the data was reliably authenticated.
- CD (Checking Disabled), DNSSEC only: disables checking at the receiving server.
- Status field response code:
- 0 = NOERR: no error.
- 1 = FORMERR: format error—the server was unable to interpret the query.
- 2 = SERVFAIL: name server problem or lack of information. Often also returned with the same meaning as REFUSED.
- 3= NXDOMAIN Name does not exist: meaningful only from an authoritative name server.
- 4 = NOTIMPL: not implemented.
- 5 = REFUSED: typically for policy reasons, for example, a zone transfer request.
The last few lines of the dig response yield useful performance information. The SERVER line particularly confirms the address and name of the server from which the results were obtained.
Let’s continue the journey by trying one of the root servers:
Note in the header the ra flag is not set, meaning recursion is not available—normal in the root and TLD servers. Further, the aa flag is not set, which means this is not an authoritative response. At first, this may seem strange; this is, after all, a root server. The root is the parent of .com (the next name in the hierarchy), but a parent’s NS RR’s (the point of delegation) are never authoritative; only the child can give an authoritative response for its NS RR’s. This has important implications as we will see later. In summary, we have no answer (ANSWER 0) and no error (status NOERR), but there are AUTHORITY (13) entries. This identifies the response as a referral. The root cannot supply the answer but has helpfully referred us to the next level in the hierarchy—in this case, the .com gTLD servers, whose names are given in the AUTHORITY SECTION and some IP addresses in the ADDITIONAL SECTION, including an IPv6 address, which is common.
I am following the b. Server branch of the DNS system, so let’s keep going.
I won’t discuss possible abnormalities as that is a separate train of thought.
In the response above we see in the header the aa flag is again not set, but we see two authoritative name servers in the AUTHORITY SECTION. We further note that while the request or question was for www.netscionline.com, the actual database entry is for just netscionline.com. We further see this server is located at Digital Ocean (a datacenter service provider). In the ADDITIONAL SECTION we learn the IP addresses in both IPv4 and IPv6 format.
What we have learned so far is there are several hundred root servers scattered around the world, on all six populated continents. They are all reachable using just 13 numeric Anycast IP addresses – one per operating organization, except for Verisign, which has two. Most of those addresses are assigned to multiple servers scattered around the world, so DNS queries sent to those addresses get fast responses from local servers. Because there are only 13 root server IP addresses, only 13 root servers can be seen from any single location at any given time. Different servers (using the same IP addresses) will be seen from different locations.
The root servers contain the information that makes up the root zone – a complete list of root zones can be found here: https://www.iana.org/domains/root/db, which is the global list of top level domains – a complete list of Top Level Domains can be found here: https://data.iana.org/TLD/tlds-alpha-by-domain.txt.
The root zone contains:
- generic top level domains – such as .com, .net, and .org –
- country code top level domains – two-letter codes for each country, such as .se for Sweden or .no for Norway
- internationalized top level domains – generally equivalents of country code top level domain names written in the countries’ local character sets
For each of those top level domains, the root zone contains the numeric addresses of name servers which serve the top level domain’s contents, and the root servers respond with these addresses when asked about a top level domain.
Additional Reference: https://en.wikipedia.org/wiki/Root_name_server
What Happens when you type ‘www.netscionline.com’ in your web browser?
It is an interesting question that may have a variety of answers. So let’s put out a couple of possibilities:
- Your system looks up it’s DNS primary server configuration, and send a DNS query to the system – it is a resolver. If the resolver has the database in its caches it will provide an authoritative response and job done!
- Your system looks up it’s DNS primary server configuration, and send a DNS query to the system – it is a resolver. If the resolver does not have the database in its caches it will use the database entry it has for the next level and ask that server, which may have the entry, and it will respond.
- Your system looks up it’s DNS primary server configuration, and send a DNS query to the system – it is a resolver. If the resolver does not have the database in its caches it will use the database entry it has for the next level and ask that server, which, if also does not have the database entry will again use it’s database to access the next level, which will likely be one of the top level domain servers.
Those are three most likely events. Of course, the request could get passed all the way back to the root servers. However, it is highly unlikely.
You can check to see which event occurs by using the command line or terminal of your local machine.
Example Of Command Line/Terminal Query
In Microsoft, you can test and query DNS operation with nslookup. There is a more complete article on that here.
On MAC OS X the program is called dig.
Here, I have opened a terminal window and typed ‘dig www.netscionline.com’:
Before I executed the command, I started Wireshark to capture packets. I have filtered for DNS packets and I see the DNS query:
And the response:
Dissecting the DNS Packet Structure and Contents with Wireshark
From a standpoint of the protocol stack, I always consider the DNS protocol to operate at Layer 5, and that it is in turn carried inside TCP or UDP at Layer 4. Most DNS queries/requests and replies will occur over UDP. In either the TCP or UDP case, the well known port for DNS is port 53. The beginning point for any packet analysis has to be an understanding of what is good. So let’s look at some normal DNS queries/requests and responses. Before we do, be sure to grab our DNS Profile here.
Assuming you have the DNS profile you can either start a capture on your computer using Wireshark and then open three or four web page tabs and navigate to three or four web sites, or you can download the capture we did and follow along.
We begin with a normal request in packet #1 in our capture (note packet #1 is selected):
An interesting capability of our DNS profile is that if you click the DNS Q/R button – only the selected packet’s Query/Response pair will be shown!
DNS Packet Structure and Contents
Before we go any further, all DNS packets use a similar structure composed of:
- Questions
- Answer Resource Records
- Authority Resource Records
- Additional Resource Records
There can be more than one of these items per DNS packet and so you will always see a list of these four topics and the count of how many of each are contained in a given DNS packet:
Each and every DNS packet also contains a Transaction ID:
You can filter based on transaction ID’s using the display filter feature of Wireshark. We have this in the Display Filter pick list, just replace the number with the actual transaction ID number you want to find.
Flags have a number of fields where bits are set on or off to indicate the particular item. Flags are more extended in response messages. Let’s start with the query flags:
- The first flag is the query/response flag, indicating the packet is one or the other. By filtering on this field you can look at all queries or all responses. We have placed these filters in the Display Filter pick list.
- The second flag is the Opcode and it is actually 4 bits – it is usually set to zero.
- The third flag is the truncated – usually queries are not truncated. Responses can be, and if this is set in a response, the querier should try TCP to get a complete response. This is not very common.
- The fourth flag is Recursion. Recursion allows the DNS server to ask further up the DNS hierarchy if it does not have an answer to the query on the clients behalf. If recursion is not permitted, then the query is considered iterative, meaning the DNS server receiving the query will reply with another DNS server address to ask, not the actual answer desired.
- The fifth flag is reserved – and must be zero.
- The sixth flag is the authenticated bit that specifies whether non-authenticated data is acceptable of not. Usually this is set to zero meaning it is unacceptable.
Here is a response flag set:
The main differences are shown:
- The Authoritative bit: indicates whether the response is from an authoritative server or not.
- Recursion Available bit: simply indicates whether the server supports recursion.
- Reply Code bits: usually zero for no errors. However the defined possible error codes are as follows:
-
Code Meaning 0 No error condition 1 Format error – the query could not be interpreted 2 Server Failure – the server could not process the query due to a problem with the name server 3 Name Error – the domain name does not exist 4 Not implemented 5 Refused – the name server refuses to perform the function due to policy restriction
Lastly, in the Queries and Answers areas, there are basically three items: the name, the type, and the class:
The variable length name filed is the name being resolved. Remember that resolution occurs right to left.
The type field is from a list found here: http://www.iana.org/assignments/dsn-parameters but here is brief list:
| Type | Description |
| A | Host IPv4 Address |
| AAAA | Host IPv6 Address |
| NS | Authoritative Name Server |
| CNAME | Canonical Name for an alias |
| SOA | Start of Zone Authority |
| PTR | Pointer Record |
| HINFO | Host Information |
| MX | Mail Exchange |
Referring back to the packet 1 screen shot above, and now expanding the DNS protocol area of the first packet, here is what we see in the screen show above:
- Source IP address is 192.168.1.112
- Destination Address is 209.18.47.62
- We have DNS in UDP using destination port 53.
- We see that the Wireshark Expert has located the associated response to be found in packet #3.
- The flags in the DNS protocol indicate a standard query with recursion required.
- Then under queries we see we are looking for mycloud.rackspace.com, Type A which means a host IPv4 address.
Let’s look at the response packet, packet #3:
Expanding the DNS protocol area of the third packet, here is what we see in the screen show above:
- Source IP address is 209.18.47.62
- Destination Address is 192.168.1.112 (these have swapped from the query)
- We have DNS in UDP using source port 53.
- We see that the Wireshark Expert has located the associated query/request to be found in packet #1.
- The flags in the DNS protocol indicate a standard query response with recursion desired and available.
- Then under queries we see we a copy of the original request, Type A which means IPv4 address.
- Under Answers we see an address 104.130.207.5 being provided as a host address.
The web browser we were using was Chrome. So it elected to try IPv4 first. In packet 2 we see a similar request, this time with the Type AAAA which is an IPv6 query:
Wireshark indicates we get a response to this query in packet #4.
Using ‘nslookup’ on a Windows platform
Whether you are in Windows, MAC, or Linux, open a command shell or terminal window. We will use the Windows command line interface.
Click on Start> or Windows button and type ‘cmd’
You should get a choice for the command prompt – select it. Once open it will look something like this:
At the > prompt enter the following command: nslookup www.cellstream.com
The response should look like this, although your output may be different depending on your resolver:
The resolver that was the DNS server to respond is shown on the first line. This is either the primary of the secondary DNS server. The second line is it’s IP address on the public Internet.
Next the output says “Non-authoritative answer” followed by a name and one or more IP addresses. What this means is that the DNS server that answered is not the one that actually has the name record. Instead the DNS server that answered is a resolver.
Also, note that you got IPv4 addresses which is a “A” record type. The reason you may get multiple IP addresses is that the destination could be behind load balancers that connect to multiple servers, or other reasons.
The prior two steps were using nslookup in what is called non-interactive mode. Let’s use nslookup in interactive mode:
Enter ‘nslookup’ at the next prompt and hit enter:
Notice the “>” prompt! This is interactive mode, and the nslookup program is now awaiting input. This means we can configure more specific options regarding DNS.
First let’s specify the record type we want to query. Let’s see if www.cellstream.com has an IPv6 address. That would be a ‘AAAA’ record type.
In the terminal window at the ‘>’ prompt type: set type=aaaa and hit enter:
The ‘>’ prompt is now waiting for your next command.
At this second > prompt enter: www.cellstream.com and hit enter:
You should see that there is no IPv6 address for the web site!
Now let’s see if the site has a mail server. You should be back at the ‘>’ prompt. Enter the following: set type=mx and then hit enter.
Then enter cellstream.com :
You should have an answer similar to what is highlighted in yellow above. Looks like this site filters for spam! Nice.
Now if you wanted to know the IP addresses of the mail exchangers, you could set the type back to ‘a’ and then look them up as well.
What if we wanted to change what DNS server we are using?
This is easy. First let’s set the DNS server to 8.8.8.8 (this is the Google DNS).
At the ‘>’ prompt type server 8.8.8.8, then hit enter.
At the next prompt enter set type=a then hit enter.
Then enter www.cellstream.com and hit enter. You should see something like this:
It appears Google’s DNS gave us some more specific information and that this web site is protected by SiteLock.
I hope you find this article and its content helpful. Comments are welcomed below. If you would like to see more articles like this, please support us by clicking the patron link where you will receive free bonus access to courses and more, or simply buying us a cup of coffee!, and all comments are welcome!