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:
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:
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:
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
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):
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:
(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.
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.
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.