Jump to content

DNS Value and Vulnerability

From ICANNWiki
Revision as of 10:50, 6 August 2019 by Larsonreever (talk | contribs) (removed dead links - cited reference to redirect vulnerability for more in depth reading.)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)

The Value and Vulnerability of DNS

The Domain Name System (DNS) has proven to be an invaluable method for quickly navigating around the Internet. By organizing the structure into zones, the DNS hierarchy allows for the efficient locating of desired destination sites on the Internet. Such structure allows for a defined methodology for how each zone is queried to return the IP address of the desired destination host. The structure is designed so that if the higher zones do not have the specific IP address of the desired destination, the structure is designed to provide navigation through the structure until the desired destination has been identified.

The Root File: At the top of the DNS structure is the root file. The root file contains the basic information for each Top Level Domain (TLD) that exists on the Internet. Such TLDs include .com, .org and .net to name a few. This list also includes code that reflect countries and regions who have a distinct presence on the Internet, such as .SG for Singapore, .UA for the Ukraine, .NZ for New Zealand and .EU for the European Union, also to name a few. Redundant instances of the root file are located throughout the globe for purposes of redundancy and resiliency.

How DNS Works: The operation of DNS remains a mystery for the majority of those using the Internet today. Each name server encountered along the way is known as a recursive name server as it’s job is to provide your browser with an address of a suggested name server that will be one step closer in obtaining the specific IP address of the desired destination site. In this case the name server that yields the actual IP address is known as the authoritative name server. Here is a brief example of how the Internet works. For purposes of this example we will be locating the destination site of CommunityDNS, or http://www.communitydns.net.

  1. You, the user, enters www.communitydns.net in the address bar of your browser.
  2. Your browser sends a request to the DNS server of your respective ISP.
  3. Your ISP’s DNS server does not have a destination IP address for communitydns.net so then informs your browser to query the root servers at the top of the global DNS hierarchy. Your ISP has a list of all of the root servers around the globe and rotates through this list to determine which root server your browser will ultimately send its request to. Your request could go to a root server nearest you or half way around the world.
  4. Your browser sends its request for www.communitydns.net to the root server. Since the root servers only know the destination of TLDs your browser is returned the address of the registry name servers that are responsible for the .net TLD. In this case Verisign is the registry for the .net TLD.
  5. The .net name servers will see that “CommunityDNS” belongs to a specific network provider, thus returning to the browser the IP address of the next name server along the path.
  6. The name server for CommunityDNS’ network provider will provide the information to reach CommunityDNS’ name server. Because multiple addresses may fall under the “communitydns.net” naming structure, such as “communtitydns.net”, “blog.communitydns.net” and “lab.communitydns.net”, being directed to CommunityDNS’ name server will allow for identifying the specific IP address for www.communitydns.net.
  7. Your browser’s query of CommunityDNS’ name server will then yield an “authoritative”, or final response with the specific IP address of www.communitydns.net.
  8. With your browser now having the specific destination IP address a connection is made directly with www.communitydns.net.

The process is simple, straight forward and elegant. However, “Simple, straight forward and elegant” does not mean it is without flaw.

Vulnerability: As with any case, the old saying of “The chain is only as strong as its weakest link” applies here. Also, the more links there are in the chain the greater opportunity, or opportunities for failure. In this case the vulnerability rests with people trying to hijack unsuspected users by redirecting them to a site for criminal activity. This is a kind of redirect hack which is widely seen in WordPress sites. For example, you wish to conduct an online transaction at a site you are familiar with, whether your bank or an online retail site. Criminals will want to hijack your session so that you wind up on their site instead of the one you originally intended to visit. Such hijacking could result in you innocently handing over your bank login or credit card information to criminals. From a national security perspective criminals could attempt to hijack the code of a given country, such as anything destined with the .na, or Namibia, TLD.

Exploiting the vulnerability: Criminals hijack sessions by targeting recursive, or non-authoritative name servers and poisoning the cache that resides within a specific recursive name server. In the earlier example eight distinct steps were identified from when a user first enters a destination in their browser to when the browser actually connects to the destination site. Four of the seven steps deal with redirecting, or bouncing your browser from one recursive name server to another, all narrowing in on the desired destination. In this case the name servers that redirected queries were:

  1. Your ISP’s name server
  2. The root servers
  3. The TLD name servers
  4. The name servers of the destination server’s network provider

Within each of the above four possible vulnerabilities it is possible for each name server to store within its cache the address of recently queried destination sites. The temporary caching of such destination addresses reduce the number of query attempts, thus making for faster connections. In this case criminal behavior works to take advantage of this feature by poisoning the cache with the insertion of a false destination site address. What that means is anyone who has a query for the same destination site that lands on the name server with the poisoned cache will have their request hijacked to the site prepared for some form of online crime.

Mitigating vulnerability: To mitigate vulnerability, thus ensuring resilience to such attacks there are technologies in place, such as CommunityDNS’ AnyCast network, that not only helps mitigate vulnerabilities due to attacks to the DNS structure, it serves to isolate and identify the source of such attacks. AnyCast servers, if placed within ISPs, within registries, within hosting providers, or within the primary path for specific country TLDs, will not only cache all destination addresses that have been added to the AnyCast service, the servers will also detect initial attempts of attacks to various name servers with the goal of cache poisoning. The AnyCast network will identify such attack attempts allowing itself to “ACT” as the newly affected name server, thus saving attacks from hitting the desired name server. While the AnyCast server under attack limits access to the Internet and begins searching for the actual violator, the intended targeted name server, along with the rest of the name servers around the globe are spared the affects of this attack.

So while the global DNS hierarchy is designed for a logical method for navigating the Internet, vulnerabilities exist that can impact your firm’s brand, business stability as well as the global economic presence countries are building by using the Internet. Having a strong business resiliency plan will help mitigate threats posed to your customers, your company and your country.


Retrieved from "https://icannwiki.org/index.php?title=DNS_Value_and_Vulnerability&oldid=1218625"