Course Development Director in Content
In this hands-on lab, we will walk though troubleshooting DNS resolution issues on the provided host.
Setting a Static IP
A business unit is complaining that their job server is unable to connect to
linuxacademy.com. This is breaking integrations for multiple reporting applications.
Get logged in
Use the credentials and server IP in the hands-on lab overview page to log into our lab server. Once we're in, we can get moving.
Verify the Issue and Check
We'll first need to verify that the issue exists by attempting the
curl the header of
[cloud_user@host]$ curl -I linuxacademy.com
Next, we'll have to verify that nothing is missing in
nsswitch.conf, and we should pay attention to the ordering of the
hosts value. If we edit
/etc/nsswitch.conf, we'll see that something is missing:
hosts: files myhostname
That line should go like this:
hosts: files dns myhostname
We'll want to make sure there aren't any entries in this file that would cause issues:
[cloud_user@host]$ cat /etc/hosts
In there, we see a line
The server we're logged into is probably not supposed to be linuxacademy.com, so let's erase that line and save the file.
If we run our
curl command again, our terminal hangs. Something is still wrong. Kill the curl with
Ctrl + C and let's see what else might fix the problem.
Determine If the DNS Host is Listening on TCP Port 53
Where is our
[cloud_user@host]$ cat /etc/resolv.conf
Let's see if the nameserver listed in there is listening on TCP port 53. We'll know by running this:
[cloud_user@host]$ telnet 10.0.1.1 53
We're getting no response.
Check Resolution Using the 10.0.0.2 DNS Host
There's another possible DNS server kicking around, on 10.0.0.2. Now that we've verified that the host listed in
/etc/resolv.conf isn't available on TCP port 53, check if resolution is working on the DNS host
[cloud_user@host]$ dig @10.0.0.2 linuxacademy.com
Hey, we're getting a response. This one looks good.
Change the Configuration to Use the 10.0.0.2 Host
We can do this with network manager, or by editing
/etc/resolv.conf. If we restart networking, this is the IP that will be used via DHCP. Let's go the network manager route and then restart the network. Afterward, we'll see what
resolv.conf looks like, and try the dig command again:
[cloud_user@host]$ nmcli con mod System eth0 ipv4.dns 10.0.0.2 [cloud_user@host]$ systemctl restart network [cloud_user@host]$ cat /etc/resolv.conf [cloud_user@host]$ dig linuxacademy.com
The new nameserver should be in
resolv.conf, and the
dig command should have printed a bunch of domain server related information.
It looks like we fixed it. We had to look in a few different spots, but DNS is working on this machine now. Congratulations!