DNS: The Internet’s Phonebook

DNS: The Internet’s Phonebook

When you’re connected to the internet and
you are listening to music, playing online games or browsing the web, there are many
standard protocols running behind the scenes, to make sure that your computer can indeed
communicate with these services. There is for instance the Internet Protocol
or IP that is responsible for delivering messages from one computer to another. These messages are also called packets and
just like postal packages, they always have a sender, a receiver and a payload. But instead of street names and postal codes,
the internet uses IP addresses and they look something like this. Without them, computers can’t communicate
with each, which means no computer networks and no internet. So if you open up YouTube, your computer actually
sends a message to YouTube’s IP address, asking for the data that it needs to show
the webpage. “But wait a minute”, you say. “When I want to open YouTube I just enter
youtube.com into my browser. I don’t need the IP address. How does my computer know the address then?” Glad you asked! This issue was solved in the early days of
the internet (ARPANET) when the Stanford Research Institute created a text file called “hosts.txt”. This file translated names like youtube.com,
into the IP addresses that computers need to communicate. The file was then installed on all the computers
connected to the ARPANET so they could “translate” a domain name into an IP address. However, as the internet kept growing, so
did the demand for these domain names. The small team that was managing the hosts
file was quickly overwhelmed and so in 1983 a specification was published to automate
this task and DNS or the “Domain Name System” was born. DNS is basically a big phonebook for the internet,
matching domain names like google.com to an IP address. This phonebook is hosted on DNS servers that
are distributed across the world. So let’s take a look at what happens when
you want to go to www.google.com. For starters, your operating system splits
the domain name into multiple parts, also called labels that are separated by dots. So in this case we have three labels: “www”,
“google” and “com”. They create a hierarchy that has to be read
from right to left. The right-most label is called the top-level
domain, in this case “com”. We can then say that “google” is a subdomain
of “com” and “www” is a subdomain of “google”. To resolve the IP address of google.com, your
computer reaches out to a root name server and asks the question: “What’s the IP
address for “www.google.com”? Root name servers never give a direct answer,
instead they refer you to a server that is more likely to be able to help you. In this case that’ll be the nameserver in
charge of the “dot com” top level domain. Your computer now asks the same question to
the “com” name server and this one is likely to refer you to yet another name server. In this case it will redirect you to a name
server that Google itself hosts. This one is very likely to be able to tell
what IP address is connected to www.google.com. This mechanism, along with the hierarchy of
domain names makes DNS very scalable. Because after all, each name server only stores
a small set of IP addresses. The “com” name servers don’t know anything
about websites that are hosted on the “org” domain for instance. The phonebook analogy holds up here as well:
my phone number is listed in the Belgian phone book but not in the US one. But there are however two drawbacks to this. First of all: it puts a lot of pressure on
the root name servers as they will be contacted every time someone wants to connect to a website
or service. And secondly: devices need to be able to follow
a referral, which it will get from root servers and perhaps other name servers. Both these problems are solved by “recursive
resolvers”. These are special DNS servers that will take
care of the entire resolving process. Instead of having your devices contact multiple
name servers, they just contact a recursive resolver which does it all for them. The recursive resolver will go through all
the hoops required, making the process much simpler for our devices. They are often hosted by internet service
providers and more recently are also hosted by companies like Google and Cloudflare. Most home routers pull double duty and serve
as a recursive resolver as well. So how do our devices know what resolver to
use? Well by default they will use the one that
is configured by the network administrator. In a home network that is your ISP and they’ll
likely configure their own resolvers but you can always choose another one. Some recursive resolvers are faster than others,
so switching to a resolver hosted by Google or Cloudflare could give you a slight speed
bump. To speed up DNS even further, recursive resolvers
also have a cache which stores the IP address of domain names that are most frequently being
requested. When you go to google.com on your phone, the
recursive resolver on your router will look up Google’s IP address and once it figures
that out, stores it in its cache for future reference. If another device on your network wants to
resolve google.com as well, your router can instantly give an answer, without having to
go through all the hoops of contacting multiple name servers. Caching can greatly increase the speed of
DNS queries but it can also be poisonous. Changes to the IP address of a domain name
aren’t immediately reflected across the world because the old address is still stored
in the cache of many recursive resolvers. To combat this issue, domain owners can define
how long an IP address may be cached. This is called the TTL or time-to-live and
is expressed in seconds. If a cache record is older than the given
TTL, the resolver must delete it after which it has to use the traditional resolving process
again. But some recursive resolvers don’t adhere
to this TTL and keep records in their cache for a longer time to reduce the load. This practice is problematic for website owners
wanting to change the IP addresses linked to their domain names. But that’s a minor hiccup. It’s clear that DNS is a major cornerstone
of the way we use the internet today. It also has some cool alternative use cases. You can for instance use a custom DNS server
to block advertisements or to protect yourself from domains that spread malware. Sounds complicated but you can easily do it
by installing PiHole on a Raspberry Pi and plugging it into your home network. PiHole acts as a recursive DNS resolver for
all your devices and when a device wants to resolve ads.google.com for instance, the PiHole
will return a local IP address and essentially stop the advertisement from loading. Genius! So that’s a quick overview of the Domain
Name System. It’s a very open system and undeniably a
protocol that makes the web accessible and easy to use for everyone. Replacing hard to remember IP addresses with
easy to remember domain names. That was it for this video! Let me know what you thought about it in the
comments below. If you liked the video, give it a thumbs up
and consider getting subscribed to my channel. Thank you so much for watching and till next

Daniel Ostrander

Related Posts

12 thoughts on “DNS: The Internet’s Phonebook

  1. Ravindra Nagrecha says:

    First like and comment!

  2. New Mateo says:

    I love this stuff. great video!

  3. Swed neck says:

    Maybe you could cover handshake as a follow-up? It aims to replace the root name servers with a blockchain.

  4. Magesh Mani says:

    clear and crisp!

  5. Magesh Mani says:

    1:58 😀

  6. Filip Ć tamcar says:

    Maybe make video about decentralized DNS projects (ENS, Namecoin…).

  7. Excore says:

    I love these kind of videos.

  8. spotifysucksballs says:

    dub dub dub dot dub dub dot com dub

  9. Arnis says:

    Oh this is why thepiratebay plays with .endings

  10. Hamed Sepehr says:

    Pretty good as always, but the music… I think that music was not a good idea.

  11. Richard HolguĂ­n says:

    Great video

  12. Terry White says:

    What an absolutely brilliant and clear explanation. Thank you for sharing your knowledge.

Leave a Reply

Your email address will not be published. Required fields are marked *