First, we need to understand what DNS (Domain Name System) really is and how it works. In short it is a naming method for computers, services, and other resources connecting to the internet or one’s private network. The purpose of DNS is to translate a domain name for example a website’s name such a www.somedomain.com into an ip address. People would not want to memorize an ip address every time they wished to access a particular website. DNS (Domain Name System) provides a worldwide convention of mapping these names to a specific server’s IP Address and has been doing this since its infancy of 1985. Domain Administrators may create CNAME records to map subdomains to the same server as the root domain with a different path or to an entirely different ip at another server anywhere in the world. To keep the internet organized there are two namespaces in place which are: domain name hierarchy and the ip address spaces.
Thus, we can easily see how vital it is to have both of these namespaces always running efficiently. If one types a domain name and the server could not translate it by looking up where the ip address is the request would never do anything but display a page can not be found error. This also means that every picture, video, uploaded or email sent would never make it to its destination if it did not know how to deliver it.
Taking a very basic look at this the request starts at your stub resolver in your computer after which intern requests for more information from a more advanced DNS (Domain Name Server). Next the resolution process sends recursive calls to multiple authoritative name servers to store the DNS information within its database. The name servers not only have to direct web traffic but also several other types of traffic such a MX records to mail server, etc. The DNS (Domain Name Server) is then translated and sent to the respective server after first checking what type of traffic it is respectively. Keep in mind that it may have to go through yet another translation if there is subdomain and then rerouted within that server or to a server anywhere else in the world.
Often times organizations don’t always run their own name servers and thus outsource to a third-party organization such as registrars, webhosting companies, network and service providers, etc. Now since DNS was first designed in 1980 when the internet was much smaller than today internet security was not a top priority. When a resolver who is sending recursive queries to an authoritative name server resolver has no system in place to verify whether the query sent was authentic. The resolver only has the ability to verify whether the source has originated from the same ip address. Depending on only the source ip address as a response is not a secure authentication method because DNS (Domain Name Server) packets from this address can easily be altered or changed. DNS resolvers that were originally designed are not able to detect packets that may have been tampered or changed without validity upon receipt. Bad Actors can send additional packets over appearing to originate from the authoritative server when they are not. Meaning that these bad actors can deliberately send people to malicious websites instead of the intended without the user knowing until it’s too late.
Now thanks to a recent discovery that was pioneered in 1990 called DNSSEC (Domain Name Server Security Extension) developed by the IETF (Internet Engineering Task Force) which is the organization responsible for setting and maintaining the DNS Standards, we have a solution.
With the implementation of this new extension DNS queries happen very similarly except that a private key is stored in the user’s zone on the authoritative name server. When using this implementation it is not the DNS (Domain Name Server) that calls and responses that are encrypted but only the data contained within the DNS (Domain Name Server) by the zone owner. DNSSEC checks to see that the by obtaining the zone public key and only if it can verify the DNS record was signed with the private key will it allow the query to resolved. If the resolver determines that it is not a match it thinks an attack is being made gives the user an error.
If this sounds complicated it’s not. First the DNS (Domain Name Server) will have a few additional record types RSIG: Containing the cryptography signature, DNSKEY: which has the public signing key, DS: this is where the hash of a DNSKEY record, NSEC & NSEC3: Responsible for the explicit denial-of-existence of a DNS (Domain Name Server) Record. Lastly there is record type called CDNSKEY and CDS which are responsible for updating the child record to a hash of that with the parent record to signify entry to this point is allowed.
Bad Actors will only exist in our world and in order to have a national world-wide internet security government, organizations, small company’s and large corporations must all start implementing this extension. Configuring your resolver to use DNSSEC can be accomplished my modifying only a few lines of code to your resolver. The good thing is that since 2010 many TLD (Top Level Domain) Resolvers have already been signed.
The most important thing to understand with (DNSSEC) Domain Name System Security Extension is that communication between RRSIG, DNSKEY and DS Records in that they add a layer of authentication to the existing DNS (Domain Name Server).