DNS is the domain name system.
And it's one of the most popular protocols on the internet
because its job is to translate those human readable
names that we use for things like web services
into an IP address that can be used by our computers.
This is a process that occurs every time you type
something into your browser, for example,
www.professormesser.com has to have
some type of IP address associated with it.
And it's the domain name system that provides that translation.
DNS is also configured as a hierarchy,
which makes it very easy to organize things
on the internet.
And it is a very distributed database.
There are many, many different DNS servers.
For example, there are 13 root server clusters,
which are the primary root servers for everything
on the internet.
And although this standard provides
for 13 of these servers, there are actually
over 1,000 servers providing redundancy
across the entire internet.
This allows us to have top level domains,
or TLDs, that may be generic such as the dot com,
dot org, or dot net addresses we may be familiar with.
But there are also country codes that can
be used as top level domains.
Things like dot US, dot CA, and dot UK
are associated with individual countries.
Here's an example of how this hierarchy works with DNS.
We start at the very top and we may
have a dot com address, a dot net, a dot edu, or others.
In my example, I have professormesser.com.
So we start with the dot com the hierarchy just under the dot
com has the Professor Messer.
I could also have other servers beyond that.
For example, I have a web server, which
is www.professormesser.com.
I could have mail.professormesser.com.
And I could even internally have an east and west.
And within the east and west, I can
have other servers within those particular areas as well,
creating a hierarchy that tells me
exactly what servers are associated
with a particular area.
Visually, my fully qualified domain names, or FQDNs,
might look something like this.
We have the entire domain of www.professormesser.com.
Within professormesser.com, I have a web server,
www.professormesser.com.
And I might have a west and an east side
of professormesser.com.
And within the west, I have a device
called ethan.west.professormesser.com
And in the east, I have katie.east.professormesser.com
So you can see how this hierarchy allows
us to create these fully qualified domain names that
not only identify what a device is, but perhaps
where it's located as well.
Many times the DNS server that we're using
is one that is internal on our own network.
We would have it running on our own internal services.
Our local IT team manages and configures the device.
It may have information about internal devices, which
are very important on the inside of our network.
But we might not want to share that
with others on the outside.
Very often these are running on their own service.
They could be running on Windows Server.
It could be on a Linux device.
But it would be a service that runs internally
on our own equipment.
There might also be an external DNS that
is provided by a third party.
We may contract with or pay for a third party
to have someone else manage the DNS for us.
For example, you may be running your systems
on Google DNS, Quad9, or one of the many other DNS
services available.
Behind the scenes, the process of resolving an IP address
to the name that we provide can use
a number of different forms.
One of them is a recursive process.
And the other is an iterative process.
With the recursive query, we send our single request
to what is usually a local DNS server.
The local DNS server then sends out
requests to try to find what the IP address might
be for the request that we've sent.
Once that name resolution is completed,
it then reports back to us on what it may have found.
It also is keeping a very large cache of these results.
So if the next person makes this request
to this recursive query, it can respond back immediately
without having to go through the process again.
If we're performing an iterative DNS query,
then we're making all of these queries
ourselves directly to all of these different DNS servers.
And there's no central pool that is cached.
Instead the cache is local on our machine.
Here's what a recursive query might look like.
We have our local machine, which is identified as a resolver.
We have a local name server that we're going
to use to provide this query.
And out on the internet there might
be root servers, a dot com name server,
and perhaps even my own local professormesser.com server.
Let's say that I wanted to look up www.professormesser.com.
This request is sent to my local name server.
That local name server then starts making queries
on our behalf to other servers.
For example, it may request that information from a root server.
The root server may not have that information,
but it may tell our local name server
that you need to talk to the dot com server
to find out where that might be.
That local name server would then
talk to the dot com server, which then says,
you need to communicate to the professormesser.com DNS server.
And finally, the local name server will make that request.
My local name server sends back what the answer might be.
And that answer is sent to the resolver.
At that point, that request is cached locally
on the local name server.
And now if someone else makes the same request,
that local name server will provide the answer
directly back without having to go through this entire process.
With an iterative query, our local device
has to do all of the work itself.
So the resolver may start communicating to the local name
server to see if it happens to know
what www.professormesser.com might be.
And it says, no it doesn't.
You need to talk to the root server.
We talk to the root server and the root server says,
you need to talk to the dot com.
We talk to dot com.
The dot com server says you need to talk directly
to the Professor Messer server.
And then finally, we find the correct DNS server
and we bring that information back to our original resolver.
At that point, the local cache of this device is updated.
And if this local machine needs to make exactly the same query,
it doesn't have to go through this entire process again.
It could simply look at the local cache on this device.
Another important consideration when
you're making these DNS queries is the authority of the answer
that you're getting.
If you're making a request of a server
and you're getting a response from the cache of that DNS
server, you may notice that your request comes back
as a non-authoritative answer.
This means the answer we received
did not come from the source files of the particular zone
that we're querying and probably came
from cached information that was available.
Doesn't necessarily mean that the information we've received
is wrong.
But if any changes were made to the original server,
those changes may not be represented in the answer
that we received.
That's why all of these answers that we receive from a DNS
server have a timer.
That timer is ticking down.
We call this the time to live.
And when information is received from a DNS server,
that time to live is put next to the IP address in our cache.
If that time to live gets all the way down to zero,
then the next time we need to find that IP address,
we'll have to go through the entire name resolution process
again.
This could also cause problems for you if time to live
is set to some very large number.
That means that your cache will sit locally
on your machine for days or even weeks at a time.
And if changes are made to the original DNS server and the IP
configuration, your device may not know of those changes.
If that occurs, you may have to manually clear your cache
on your device so that an updated series of queries
can occur.
Here are the results of a dig command
that I performed for www.professormesser.com.
This request went out to a server
to try to find the IP address of that particular fully qualified
domain name and I got three answers back from my local DNS
server, which was 9.9.9.9.
That's the quad nine DNS server.
Those three IP addresses I received back
for www.professormesser.com can all
be used to access my server.
And each one of them has a value of 300 associated with them.
This is the time to live.
That means once you've received this answer
for www.professormesser.com, it should stay alive in your cache
for 300 seconds, or five minutes.
After that five minute time period,
you'd have to re-query a DNS server
and update the cache for another five minute period.
Most of the time, we're performing forward lookups
to a DNS server.
That means that we're providing the DNS server with a fully
qualified domain name and the DNS server's
providing us with the IP address that resolves for that fully
qualified domain name.
You can also reverse this process.
You can provide the DNS server with an IP address
and the DNS server will tell you the DNS name,
or fully qualified domain name, associated with that IP
address.
We refer to that query as a reverse DNS query.
Here's a forward look up I did in dig.
I performed a forward look up to www.professormesser.com.
And in the answers I received IP addresses
associated with that fully qualified domain name.
Let's take one of these IP addresses
that I received for that forward lookup
and let's perform a reverse lookup.
So I'll perform a dig-x for the reverse lookup
and specify the IP address that we
received in that earlier query.
You'll notice that the answer that comes back
is not professormesser.com but is instead
a server at cloudflare.com That's
because I use Cloudflare in front of my servers to provide
access to my web services.
And that means every time you're connecting to my web server,
you're first connecting to Cloudflare, which then connects
to a load balancer, which then connects to the Professor
Messer web server to finally give you
the information that you're looking for.