-In this video, we get introduced to DNS in Linux
for the absolute beginners.
We will discuss the basic concepts
and view some commands that will help us explore DNS configuration on hosts,
specifically Linux hosts.
At the end of this section, you will go through a practice test
where you're given a set of challenges related to DNS
and are asked to solve them on a live, practical,
hands-on lab environment right in your browser.
We have two computers,
A and B, both part of the same network.
They've been assigned with IP addresses
192.168.1.10 and 1.11.
You're able to ping one computer from the other
using the other computer's IP address.
You know that system B has database services on them,
so instead of having to remember the IP address of system B,
you decide to give it a name, DB.
Going forward, you would like to ping system B
using the name DB instead of its IP address.
If you try to ping DB now,
you would see that host A is unaware of a host named DB.
How do you fix that?
Basically, you want to tell system A
that system B at IP address 192.168.1.11 has a name DB.
I want to tell system A that when I say DB,
I mean the IP 192.168.1.11.
You can do that by adding an entry into the /etc/hosts file on system A.
Mention the IP address
and the name you want your host to see system B as.
We told system A that the IP at 192.168.1.11 is a host named DB.
Pings to DB now get sent to the correct IP and are successful.
There is an important point to note here.
We told system A that the IP at 192.168.1.11 is a host named DB.
Host A takes that for granted.
Whatever we put in the /etc/hosts file
is the source of truth for host A,
but that may not be the truth.
Host A does not check to make sure if system B's actual name is DB.
For instance, running a hostname command on system B
reveals that it is named host two,
but host A doesn't care,
it goes by what's in the host file.
You can even fool system A to believing that system B is Google.
Just add an entry into the host file with an IP mapping to www.google.com,
then ping Google and you will get a response from system B.
We have two names pointing to the same system,
one as DB and another as Google.
We can use either names to reach system B.
You can have as many names as you want
for as many servers as you want in the /etc/hosts file.
Every time we reference another host by its name from host A
through a ping command, or SSH command,
or through any of the applications or tools within the system,
it looks into its /etc/hosts file to find out the IP address of that host.
Translating hostname to IP address this way
is known as name resolution.
Within a small network of few systems,
you can easily get away with the entries in the /etc/hosts file.
On each system,
I specify which are the other systems in the environment.
That's how it was done in the past
until the environment grew,
and these files got filled with too many entries,
and managing these became too hard.
If one of the servers' IP changed,
you would need to modify the entries in all of these hosts,
and that's where we decided to move all these entries into a single server
who will manage it centrally.
We call that our DNS server.
Then we point all hosts to look up that server
if they need to resolve the hostname
to an IP address instead of its own /etc/hosts files.
How do we do that?
How do we point our host to a DNS server?
Our DNS server has the IP 192.168.1.100.
Every host has a DNS resolution configuration file
at /etc/resolv.conf.
You add an entry into it specifying the address of the DNS server.
We say name server and point it to 192.168.1.100,
and that should be it.
Once this is configured on all of your hosts,
every time a host comes up across a hostname
that it does not know about,
it looks it up from the DNS server.
If the IP of any of the host was to change,
simply update the DNS server
and all hosts should resolve the new IP address going forward.
You no longer need any entries in the /etc/hosts file in any of the hosts
but that does not mean you can't have entries in hosts file,
you still can.
For example,
say you were to provision a test server for your own needs.
You don't think others would need to resolve the server by its name,
so it may not be added to the DNS server.
In that case, you can add an entry into your host,
/etc/hosts file,
to resolve this server.
You can now resolve the server,
however, no other system will be able to do that.
A system is able to use hostname to IP mapping
from the /etc/hosts file locally,
as well as from a remote DNS server.
What if you have an entry in both places,
one in your /etc/hosts file and another in DNS?
I have an entry in my local file set to 192.168.1.115
and someone added an entry for the same host
to 192.168.1.116 on the DNS server.
In that case, the host first looks in the local /etc/hosts file
and then looks at the name server.
If it finds the entry in the local /etc/hosts file,
it uses that.
If not, it looks for that host in the DNS server.
That order can be changed.
The order is defined by an entry in the file /etc/nsswitch.conf,
the line with the host entry.
As you can see, the order is first files, and then followed by DNS.
Files refers to /etc/hosts file
and DNS refers to the DNS server.
For every hostname,
the host first looks into the /etc/hosts file
and if it cannot find it there, it then looks at the DNS server.
This order can be modified by editing this entry in the file.
As per this order,
our host would resolve the test server to 192.168.1.115.
What if you try to ping a server that is not in either list?
For example, I try and ping www.facebook.com.
I don't have facebook.com in my /etc/hosts file
and I don't have it in my DNS server either.
In that case, it will fail.
You can add another entry into your resolv.conf file
to point to a name server that knows Facebook.
For example, 8.8.8.8
is a common well-known public name server available on the internet
hosted by Google that knows about all websites on the internet.
You can have multiple name servers like this configured on your host,
but then you will have to configure that on all your hosts into your network.
You already have a name server
within your network configured on all the hosts.
In that case, you can configure the DNS server itself
to forward any unknown hostnames
to the public name server on the internet.
You should now be able to ping external sites such as facebook.com.
Until now, we have been just trying to read systems with their names
like web, DB, NFS, et cetera,
but we just tried to ping Facebook www.facebook.com.
What is this name with a www and .com at the end?
It's called a domain name
and it is how IPs translate to names
that we can remember on the public internet
just like how we did for our host.
The reason they are in this format separated by dots
is to group like things together.
The last portion of the domain name, the .coms, the .nets,
.edu, .org, et cetera,
are the top-level domains
that represent the intent of the website,
.com for commercial or general-purpose,
.net for network,
.edu for educational organizations,
and .org for nonprofit organizations.
Let's look at one in particular.
In Google's case, the dot is the root,
that's where everything starts.
.com is a top-level domain.
Google is the domain name assigned to Google
and www is a subdomain.
The subdomains help in further grouping things together under Google.
For example, Google's map service is available at maps.google.com,
so maps is a subdomain.
Google's storage service is available at drive.google.com.
Mobile apps are available at apps.google.com.
Google's email service are available at mail.google.com.
You can further divide each of these into as many subdomains
based on your needs,
so you'll begin to see a tree structure forming.
When you try to reach any of these domain names,
say apps.google.com from within your organization,
your request first hits your organization's internal DNS server.
It doesn't know who apps or Google is,
so it forwards your request to the internet.
On the internet, the IP address of the server serving apps.google.com
may be resolved with the help of multiple DNS servers.
A root DNS server looks at your request
and points you to a DNS server serving .coms.
A .com DNS server looks at your request and forwards you to Google,
and Google's DNS server provides you the IP of the server
serving the apps applications.
In order to speed up all future results,
your organization's DNS server
may choose to cache this IP for a period of time.
Typically, few seconds up to a few minutes.
That way, it doesn't have to go through the whole process again each time.
That was out in the public.
What about your organization?
Your organization can have a similar structure too.
For example, your organization could be called as mycompany.com
and have multiple sub-domains for each purpose.
The www for external-facing website,
mail.my company.com for accessing your organization's mail,
drive for accessing storage,
pay.company.com for accessing the payroll application,
HR for accessing HR application, et cetera.
All of these are configured
in your organization's internal DNS server.
The reason we discussed all of these
is to understand another entry in the /etc/resolv.conf.
Remember, this is the file
where we configure the DNS server to be used for our host.
With that, we were able to resolve servers in your organization
with just their names like web.
We have now introduced more standard domain names
like web.mycompany.com
or db.mycompany.com, et cetera.
When you ping web, you can no longer get a response.
Of course, this is because we are trying to ping web,
but there is no record by the name web on my DNS server.
Instead, it is web.mycompany.com
so you have to use web.mycompany.com.
I can understand if someone outside of the company
wants to access our web server,
he would have to use web.mycompany.com.
Within our company, your own company,
you want to simply address the webserver by its first name, web,
just like how you address other members in your family
simply by their first names,
which is not the case when someone outside your family
addresses them using their full names.
What do you do to configure web to resolve my web.mycompany.com?
You want to say when I say web,
I mean web.mycompany.com.
For that, you make an entry into your host
/etc/resolv.conf file called search
and specify the domain name you want to append.
Next time you try to ping web,
you will see it actually tries web.mycompany.com.
Your host is intelligent enough to exclude the search domain
if you specified a domain in your query like this.
You may also provide additional search domains like this.
It would mean when I say web,
I mean web.mycompany.com or web.prod.mycompany.com.
Your host will try searching all of these domain name
when you look for a hostname.
Finally, a word about record types.
How are the records stored in the DNS server?
We know that it stores IP to hostnames.
That's known as A records.
Storing IPv6 to hostnames is known as AAAA records.
Mapping one name to another name is called CNAME records.
For example, you may have multiple aliases for the same application.
Like a food delivery service
may also be reached at eat or hungry.
That's where a CNAME record is used,
name to name mapping.
There are many more,
but that's all we're going to look at for now.
Ping may not always be the right tool to test DNS resolution.
There are a few other tools as well, such as nslookup.
You can use nslookup to query a hostname from a DNS server.
Remember, nslookup does not consider the entries in the local /etc/hosts file.
If you add an entry into the local /etc/hosts file
for your web application,
and if you try to do an nslookup for that web application,
it is not going to find it.
The entry for your web application has to be present
in your DNS server.
nslookup only queries the DNS server.
The same goes with dig.
Dig is another useful tool to test DNS name resolution.
It returns more details in a similar form
as is stored on the server.
In the upcoming practice exercises section,
you will practice viewing, configuring, and troubleshooting DNS
in a lab environment on actual systems
through some fun and challenging exercises.
That's it for this lecture.
In the next lecture,
we look at how to set up an actual DNS server
on a system where we will use core DNS as our DNS solution.
Thank you so much for watching
and don't forget to subscribe to my channel for more videos like this.