In 1982, there were only 455 hosts on ARPANET, and already it was becoming an increasingly difficult task to address these hosts.
ARPANET (Advanced Research Projects Agency Network) was an early packet switching network and the first network to implement the protocol suite TCP/IP. Both technologies became the technical foundation of the Internet.
Originally, a central Network Information Center (NIC) was responsible for maintaining a file listing for every host on the network. The file was known as the hosts.txt file, similar to the /etc/hosts (in UNIX-based OSes) and %SystemRoot%\System32\drivers\etc\hosts (in Windows OSes) files. Every time there was a network change, the NIC had to FTP to every host on the network to update the host file[1]. Of course, this does not scale well.
Before the Internet, the general method of communication between computers was with a direct point-to-point dial up connection. For example, if you wanted to send me a file, you would have your modem call my modem, and we would transfer the file.
So, each computer has a file which lists the hosts it's aware of, their phone number, and a username and password on that host. You then craft a path, from your current machine to your destination, through hosts which each know how to connect to the next:
Enter DNS
In November 1983, IETF RFC 882 and 883 introduced the DNS system we still use today. In fact, have a look at a DNS Response from today. dig blog.cdemi.io returns:
;; ANSWER SECTION:
blog.cdemi.io. 300 IN A 104.28.22.20
The IN field in the DNS Response dates back to the era where there were several interoperating networks. Values of this could be IN (Internet), CH (Chaos) or HS (Hesoid). These were defined in RFC 6895.
Top Level Domains
Once DNS was invented, and since DNS is hierarchical, the next question was who is going to be at the root of the hierarchy? This root is signified with a single .. In fact, all domains end with a trailing ., even if you don't type it; it is assumed.
There is a set of root DNS servers which are responsible for, for example, turning .io into the .io nameservers, who will in turn answer how to get to cdemi.io. The root DNS zone of the internet is composed of thirteen DNS server clusters. There are 13 logical root name servers (named from a to m), because that's all that can fit in a single UDP packet. This does not mean that there are only 13 physical servers; each operator uses redundant computer equipment to provide reliable service even if failure of hardware or software occurs.
These Root DNS Servers operate in safes, inside locked cages. A clock sits on the safe to ensure the camera feed hasn't been looped. An attack on one of these servers could allow an attacker to redirect all of the Internet traffic for a portion of internet users. Unsurprisingly, the nameservers for top-level TLDs don't actually change all that often so clients can actually cache their results. In fact, a survey in 2003 shows that only 2% of all queries to the root servers were legitimate.
The TLD nameservers are administered by different companies and governments all around the world (Verisign manages .com[1:1]). The .mt domain is maintained by the NIC(Malta) which is a committee constituted by the University of Malta.
Attacks on DNS
The root nameservers are critical infrastructure components of the Internet, mapping domain names to IP addresses. Attacks against the root nameservers could, in theory, impact operation of the entire global Domain Name System, and thus all Internet services that use the global DNS, rather than just specific websites. However, in practice, the root nameserver infrastructure is highly resilient and distributed, using both the inherent features of DNS (result caching, retries, and multiple servers for the same zone with fallback if one or more fail), and, in recent years, a combination of anycast and load balancer techniques used to implement most of the thirteen nominal individual root servers as globally distributed clusters of servers in multiple data centers.
Nevertheless, DDoS attacks on the root zone are taken seriously as a risk by the operators of the root nameservers, and they continue to upgrade the capacity and DDoS mitigation capabilities of their infrastructure to resist any future attacks.
Another attack vector on DNS is the fact that DNS responses aren't traditionally cryptographically signed. If you were to MITM a DNS request, you could easily change the response to point to a different IP. Domain Name System Security Extensions (DNSSEC) modify DNS to add support for cryptographically signed responses. For example, this is the DNSSEC Authentication Chain for blog.cdemi.io:
To find out how to enable DNSSEC Verification in Windows' DNS Server, check out my other post: Enabling Windows' DNS Server to Validate DNSSEC