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
- 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):
|a.root-servers.net||188.8.131.52, 2001:503:ba3e::2:30||VeriSign, Inc.|
|b.root-servers.net||184.108.40.206, 2001:500:200::b||University of Southern California (ISI)|
|c.root-servers.net||220.127.116.11, 2001:500:2::c||Cogent Communications|
|d.root-servers.net||18.104.22.168, 2001:500:2d::d||University of Maryland|
|e.root-servers.net||22.214.171.124, 2001:500:a8::e||NASA (Ames Research Center)|
|f.root-servers.net||126.96.36.199, 2001:500:2f::f||Internet Systems Consortium, Inc.|
|g.root-servers.net||188.8.131.52, 2001:500:12::d0d||US Department of Defense (NIC)|
|h.root-servers.net||184.108.40.206, 2001:500:1::53||US Army (Research Lab)|
|j.root-servers.net||220.127.116.11, 2001:503:c27::2:30||VeriSign, Inc.|
|k.root-servers.net||18.104.22.168, 2001:7fd::1||RIPE NCC|
|m.root-servers.net||22.214.171.124, 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: