What Is DNS?
The Domain Name System (DNS) is one of the foundations of the internet. Yet most people outside of networking probably don’t realize they use it every day to do their jobs, check their email or waste time on their smartphones.
At its most basic, DNS is a directory of names that match with numbers. The numbers, in this case are IP addresses, which computers use to communicate with each other.
Why Is DNS Important?
Most descriptions of DNS use the analogy of a phone book, which is fine for people over the age of 30 who know what a phone book is. If you know a person’s name but don’t know their telephone number, you can simply look it up in a phone book. DNS provides this same service to the internet.
When you visit https://dyn.com in a browser, your computer uses DNS to retrieve the website’s IP address of 50.16.85.103. Without DNS, you would only be able to visit any website by visiting its IP address directly, such as http://50.16.85.103.
So this is necessary because, although domain names are easy for people to remember, computers or machines, access websites based on IP addresses.
How Does It Work?
Information from all the domain name servers across the Internet are gathered together and housed at the Central Registry. Host companies and Internet Service Providers interact with the Central Registry on a regular schedule to get updated DNS information.
When you type in a web address, e.g., www.jimsbikes.com, your Internet Service Provider views the DNS associated with the domain name. Then translates it into a machine friendly IP address (for example 216.168.224.70 is the IP for jimsbikes.com). And after that directs your Internet connection to the correct website.
After you register a new domain name or when you update the DNS servers on your domain name, it usually takes about 12-36 hours for the domain name servers world-wide to be updated and able to access the information. This 36-hour period is referred to as propagation.
This image provides a high-level overview of how DNS works.
Let’s take an in-depth look at the process:
Step 1: Request information
The process begins when you ask your computer to resolve a hostname, such as visiting https://dyn.com. The first place your computer looks for the corresponding IP address is its local DNS cache. It stores information that your computer has recently retrieved.
If your computer doesn’t already know the answer, it needs to perform a DNS query to find out.
Step 2: Ask the recursive DNS servers
If the information is not stored locally, your computer queries (contacts) the recursive DNS servers (resolvers) from your internet service provider (ISP). These specialized computers perform the legwork of a DNS query on your behalf. Resolvers have their own caches, and given that many of the ISP’s customers are using the same resolvers. There is a reasonable chance that popular domains will already be cached. If this is the case for our example, dyn.com, the process usually ends here. And the information is returned to the user.
Just about every ISP runs their own resolvers, yet those aren’t necessarily what you could be using. Some companies and perhaps even technically sophisticated home users could run their own resolvers on site. Additionally, there are several very popular open resolvers available, including Google Public DNS, OpenDNS, Dyn Recursive DNS, and Quad9.
Step 3: Ask the root name servers
If the recursive servers don’t have the answer, they query the root name servers. A name server is a computer that answers questions about domain names, such as IP addresses. These 13 servers act as a kind of telephone switchboard for DNS. They don’t know the answer, but they can direct DNS queries to someone that knows where to find it.
Step 4: Ask the TLD name servers
The root name servers will look at the first part of our request. Reading from right to left — www.dyn.com — and in our case, direct our query to the top-level domain (TLD) name servers for .com. Each TLD, such as those for .com, .org, and .us, has its own set of name servers. It act like a receptionist for each TLD. These servers don’t have the information we need. But they can refer us directly to the servers that do have the information.
Step 5: Ask the authoritative DNS servers
The TLD name servers review the next part of our request — www.dyn.com — and direct our query to the name servers responsible for this specific domain. These authoritative name servers are responsible for knowing all the information about a specific domain, which is stored in DNS records. There are many types of records, which each contain a different kind of information.
In this example, we want to know the IP address for www.dyn.com. So we ask the authoritative name server for the address record (A record). Some authoritative name servers have intelligence that can analyze an incoming DNS query and return a response that is more performant for the user that originated the query.
Step 6: Retrieve the record
The recursive server retrieves the A record for dyn.com from the authoritative name servers. And it stores the record in its local cache. If anyone else requests the host record for dyn.com, the recursive server will already have the answer. It will not need to go through the lookup process again. All records have a time-to-live value, which is like an expiration date. After a while, the recursive server will need to ask for a new copy of the record to make sure the information doesn’t become out-of-date.
Step 7: Receive the answer
Armed with the answer, recursive server returns the A record back to your computer. Your computer stores the record in its cache. It reads the IP address from the record, then passes this information to your browser. The browser then opens a connection to the webserver and receives the website.
This entire process, from start to finish, takes only milliseconds to complete.
What is DNSSEC?
DNS Security Extensions is an effort to make the communication among the various levels of servers involved in DNS lookups more secure. Internet Corporation devised it for Assigned Names and Numbers (ICANN), the organization in charge of the DNS system.
ICANN became aware of weaknesses in the communication between the DNS top-level, second-level and third-level directory servers that could allow attackers to hijack lookups. That would allow the attackers to respond to requests for lookups to legitimate sites with the IP address for malicious sites. These sites could upload malware to users or carry out phishing and pharming attacks.
DNSSEC would address this by having each level of DNS server digitally sign its requests, which insures that the requests sent in by end users aren’t commandeered by attackers. This creates a chain of trust so that at each step in the lookup, the integrity of the request is validated.
In addition, DNSSec can determine if domain names exist. And if one doesn’t, it won’t let that fraudulent domain be delivered to innocent requesters seeking to have a domain name resolved.
As more domain names are created, and more devices continue to join the network via internet of things devices and other “smart” systems, and as more sites migrate to IPv6, maintaining a healthy DNS ecosystem will be required. The growth of big data and analytics also brings a greater need for DNS management.
How Does DNS Get Hijacked?
That moment when a name and a number match together is where hackers can intervene. There are a number of ways it can happen, but DNS hijacking is when your page request doesn’t go to the site you asked for, or it takes a detour through a hacker’s computer before it gets there. And you guessed it–there’s no obvious way to tell that it’s happening.
If this sounds far-fetched, keep in mind that hacking groups with connections to the Iranian government have been doing it with great success for a few years now, targeting companies, governments and universities with a wide array of sophisticated DNS hijacks. Other hackers deployed similar methods for years. Hackers hijacked Google’s DNS servers in 2014. And even ICANN’s domain names were hit by a DNS hijack in 2008.
Why Are So Few Businesses Adopting DNSSEC?
With hackers able to exploit this flaw for years, and organizations like ICANN sounding the alarm, why is DNSSEC adoption lagging?
- Low Information Environment: Virtually every article online describing DNS hijacking needs to explain what DNS is first. Complex tech issues often create priority gaps when cybersecurity experts fail to communicate why decision makers should commit resources to the implementation of DNSSEC.
- DNSSEC Requires Experts: It takes a qualified IT person to check DNS settings to identify a hijack, and an even more qualified person to implement DNSSEC to prevent it. The reluctance to implement stems from widespread obsolescence. Internal networks and corporate intranets often require extensive structural re-working to accommodate DNSSEC. A misconfiguration could effectively take an entire business offline, or worse, open it to a wide array of cyberattacks.
- No One’s Doing It: Getting executives to commit sufficient resources to cybersecurity is a struggle, and when everyone else isn’t following a protocol it’s even harder. DNSSEC depends on widespread compliance. Businesses still haven’t reached a tipping point where it’s viewed as a requirement.
Hackers and other bad actors on the world stage are constantly evolving. Cybersecurity should be front and center in every boardroom and government agency. All too often it is not. The fact that state actors have been stepping up DNS hijacks on businesses and government sites of late should be no surprise. The door’s been wide open for more than a decade.
