Demystifying DNS
One fine evening sitting in front of your laptop you decide to binge watch a tv series on Netflix and go to Google Chrome to type www.netflix.com and hit Enter. And there it is! But between the hit of the Enter key and rendering of the web page, there is a lot happening behind the curtains. Let's unravel it.
Domain Name Registrars
Before distributing domain names under the TLD (Top level domain like .com), a company (for example GoDaddy.com, namecheap.com, name.com) must get accredited by ICANN (Internet Corporation for Assigned Names and Numbers).
Many companies that are not accredited by ICANN offer domain registration services — some are reselling names obtained from accredited registrars. ICANN recommends that you deal directly with an accredited registrar.
To get the complete list of Accredited Registrars: https://www.icann.org/registrar-reports/accredited-list.html
To get yourselves familiar with some terminologies, refer to this great article:
Domain Name System
Domain names are there in the first place because we can’t remember the long IP addresses consisting of numbers just for accessing our favourite websites. DNS provides it service of mapping a domain name to IP Address. This process of resolving a domain name to IP address involves many queries and hence Caching is used in almost every step to speed up the process.
- It starts from your web browser(Chrome), it checks its browser cache if it has the IP address for “www.netflix.com”. If it does have this info stored in its own cache the IP address is returned and the page renders.
- If the IP address is not present in the browser cache then the Operating System (OS) checks if it has the required domain’s DNS Records(A, AAAA, CNAME, PTR, etc). You can check the cached DNS records in your system by running this command in your command prompt:
ipconfig /displaydns
Extras:
Time to live (TTL) are used for caching purpose and are set by an authoritative nameserver(we will come to this afterwards) for each resource record. This is the time after which the cache record is purged. Now a shorter TTL means the cache record will not live long and there will be more requests on authoritative nameservers. Longer TTL results in less frequent update of the DNS record cache and so if you update your servers, the IP address would not reflect until the TTL finishes and everyone would be redirected to wrong servers. Also, a longer TTL poses another problem, it makes the DNS cache vulnerable to DNS Cache Poisoning(Also known as DNS Spoofing).
DNS Cache Poisoning:
DNS cache poisoning is the act of adding false information in the DNS Cache by modifying the DNS records so that a wrong address is returned and the user is redirected to a phishing website. The local DNS server does not know which server is in charge of which domain and so it accepts the query answer as long as the reply matches the query and has a correct format.
Most DNS resolver libraries use UDP(User Datagram Protocol) instead of TCP which does not performs a ‘3-way handshake’ and hence there is no communication between the parties to verify the identity of the devices. UDP is thus vulnerable to forging and the attackers can send a message via UDP and pretend it’s a response from a legitimate server by forging the header data. So if the attacker beats the authoritative nameserver in replying to the query, wrong DNS records will be cached and malicious redirection of traffic will take place till TTL. But DNS also uses TCP(Transmission Control Protocol) in some cases where the exchange information is larger than 512 bytes. UDP messages are not larger than 512 bytes and are truncated when it exceeds the limit. For the smooth working, all the DNS servers hosting the same zone (Zone is a portion of domain namespace that is served by a DNS server) must keep each other updated of any changes. This is done by DNS zone transfer also known as AXFR Protocol. This protocol uses TCP connection for replicating DNS data over DNS servers to make sure the data is consistent. To read more on AXFR Protocol refer to: https://cr.yp.to/djbdns/axfr-notes.html
“Early this morning, servers providing domain name system (DNS) service to MyEtherWallet (MEW), the client-side software interface for interacting with the Ethereum blockchain, fell victim to a hack that utilised DNS cache poisoning (or spoofing) .
Some users logging into MyEtherWallet during this brief timeframe earlier today — hours at most — fell prey to a phishing scam that tricked users into surrendering their wallet keys before transferring their cryptocurrency into what can only be assumed to be the hacker(s) associated digital wallet. It’s being reported that the attacker made off with 215 Ether, the equivalent of $160,000 at the time of the transaction.” — ethnews.com
DNS uses UDP even when TCP is more reliable. Why? One of the reasons is that
UDP is much faster, TCP is slow as it requires 3-way handshake. The load on DNS servers is also an important factor. DNS servers (since they use UDP) don’t have to keep connections.
To read more on DNS Cache poisoning head to these 2 articles:
3. If the records are not present in the OS cache, sometimes there is another check in the router cache but this depends on the router.
Pre-requisites:
Recursive DNS servers → A DNS resolver which acts as a middleman between the client and a DNS nameserver. When it receives a DNS query it checks its cache, then sends the request to Root name servers, then TLD name servers, then finally retrieves the IP address from Authoritative name servers.
Root name servers → These servers extract the Top level domain from the user query and respond by directing the Recursive DNS servers to the TLD name servers depending on the extension of the domain (.com, .net etc.).
TLD name servers → These servers maintain information of all the domains under a specific domain extension such as .com, .org, .net etc. For example a .com TLD name server provides the IP addresses of the authoritative name servers of all .com websites.
Authoritative name servers → These servers provide the original and definitive answer to the queries i.e. DNS records and IP address for a given domain name.
4. Now the query is forwarded to the Recursive DNS servers/Recursive resolvers provided by your ISP (Internet Service Provider). You can check your current ISP using the below link. The Recursive DNS servers check whether the domain’s IP address is stored in its cache memory.
Extras:
You can even change your Recursive DNS servers to some of the best Public DNS Servers which provide fast DNS query results due to their caching servers and some also blocks access to phishing sites. Some of the top Public DNS Servers are Google’s 8.8.8.8, Quad9’s 9.9.9.9 and CloudFlare’s 1.1.1.1
You can configure your device network configuration to use them. Here is a good comparison between them:
5. If the DNS resolver is unable to recognize a domain, it forwards the query to Root Name Servers. There are 13 root name servers all over the world. They do not represent a single computer but rather a server cluster consisting of many computers. They help to find the IP address by directing the request to other appropriate and more specific servers.
6. Root name server checks if it has the IP address in its cache memory. If it doesn’t it forwards the query to a more specific server called TLD (Top Level Domain) servers. Root name server provides the IP address of the ‘.com’ TLD servers.
Extras:
TLDs are broadly classified into two categories:
1. generic top-level domains (gTLDs)
2. country code top-level domains (ccTLDs)
The entity responsible for the administration of these TLDs in the Domain Name System (DNS) is the Internet Assigned Numbers Authority (IANA) that is currently operated by the Internet Corporation for Assigned Names and Numbers (ICANN). You can see the full list of current TLDs at:
7. Next, the Recursive DNS servers query the TLD servers. TLD servers have IP addresses in their cache memory divided into groups based on what each URL ends with. For example, URLs ending with .com are in one group whereas URLs ending with .net are in another group and so on. If the domain’s IP address is not present then the ‘.com’ TLD server provides the IP address of ‘netflix.com’ Authoritative name server.
8. Authoritative name server surely has the IP address and it will definitely provide the IP address. The authoritative name servers contain every single IP address of every single website and it is updated every time someone buys a domain.
Extras:
Suppose you deploy your website on GCP/AWS etc. and you bought your domain ‘example.com’ from ‘name.com’ domain registrar. Now after deploying the website GCP will provide you with the DNS records (A, AAAA, PTR etc.) which you have to edit in your ‘name.com’ domain profile. That means the ‘name.com’ nameservers (ns1.name.com, ns2.name.com, ns3.name.com etc.) will be the Authoritative nameservers for ‘example.com’.
Now suppose you have deployed your website on DigitalOcean and you bought your domain ‘example.com’ from ‘name.com’ domain registrar. Now you can update the nameservers used by your domain registrar to DigitalOcean’s nameservers instead. So the DigitalOcean’s nameservers (ns1.digitalocean.com, ns2.digitalocean.com, ns3.digitalocean.com) will be the Authoritative nameservers for ‘example.com’. So now the query would be directed towards the DigitalOcean servers instead of ‘name.com’ servers.
9. Now the IP address/DNS records of ‘www.netflix.com’ is returned. On the way back it is saved in the cache memory of the DNS servers, OS cache, and the browser cache.
10. Chrome browser builds a TCP connection with the server and makes a HTTP request to the IP address. This connection is established using a process known as TCP/IP 3-way handshake. The server at the IP address of ‘www.netflix.com’ returns the web page which is then rendered in the browser!
You can see the DNS query trace using the dig command which is used to troubleshoot queries and responses from the DNS. It is installed by default on many operating systems, including Linux and Mac OS X.
dig +trace www.netflix.com
The basic flow is similar as given below but it depends on the cache memory.
‘.’ nameservers → ‘.com’ nameservers → ‘netflix.com’ nameservers → ‘www.netflix.com’ nameserversAnother awesome site to see the DNS resolution paths as a graph. Check it out:
The process of DNS query is recursive. If the domain name is under the authoritative server’s zones (Zone is a portion of the DNS tree stored on a DNS server) or cache then it answers the query else it queries other servers for the answer. This is done with the help of Forwarders and Root Hints. They both help DNS servers to resolve queries for which they are not authoritative.
Extras:
Root hints help DNS server to find the IP address of the DNS root server. Root hints are simply pointers to DNS servers that are higher in the DNS hierarchy. When the local DNS servers do not have the answer in its cache, it refers to the root hints (i.e list of names and IP addresses) to find the root servers.
DNS forwarders are servers on your network that are used to forward DNS queries for a separate DNS namespace from internal DNS clients to DNS servers that can resolve the query. When the local DNS servers do not have the answer in its cache, it forwards the query to another DNS server known as forwarders. These servers then continue the process as usual and act as the Recursive DNS servers.
You can access a site by typing in the IP address alone, for example, 216.58.196.174 (www.google.com). But you may have noticed that some sites do not open by typing in their IP address. That is because many websites use a Shared IP address. So, many websites may have a common IP address, in such cases, the request must contain the Host name also. In some cases, the website’s domain name might not be hosted directly at the root of the IP address i.e www.example.com could map to 198.12.24.34/~example or 198.12.24.43/www/. Others like Google, DuckDuckGo have Unique/Dedicated IP address hence you are able to open it directly. Companies usually own a range of IP addresses known as blocks for their domains.
That’s it!
More to read:
Any suggestions for improvements are welcome. Feel free to share this article if it helped :)
