In this video, we're going to discuss
how to troubleshoot DNS and NTP issues.
First, let's focus on DNS.
Remember, DNS is used to match the domain names
with the corresponding IP addresses
that are used by a server.
This allows us to use memorable domain names
while our computers can access the information
using those IP addresses.
If your network clients are unable
to resolve their domain names to IP addresses,
such as figuring out that diontraining.com is supposed
to point to 45.79.184.180 for example,
then you most likely have a DNS issue.
So first, you need to determine if the issue is occurring
on a single network client,
or is it a larger wide-scale DNS issue on your network.
If it's only affecting one client,
then it's most likely going to be an issue
with that client's TCP/IP settings.
By running the IP, ifconfig or IP commands,
you can determine the IP address of the assigned DNS server.
Once you have that IP, you should verify connectivity
between your client and that DNS server.
If there's no connectivity between them,
then you need to troubleshoot the connection
at layer one, layer two, or layer three of the OSI model
to fix this DNS issue,
because your client simply can't reach the DNS server.
If your client can reach the DNS server,
but there's still a DNS issue, then you need
to either flush the DNS cache on the client
or change the configuration to allow the client
to use a different DNS server,
something like Google's DNS servers located
at 8.8.8.8 and 8.8.4.4.
On the other hand, if a client doesn't seem
to be having an issue with their configuration,
it may be your DNS server itself is not properly responding.
In this case, you're going to troubleshoot your DNS server.
Now, this is usually going to be an issue specifically
for people who run their own websites
and control their own DNS records.
In these cases, you need to verify that your A records
and your CNAME records were properly created.
With an A record,
you need to ensure the domain name is typed in properly
and the IP address has been entered correctly.
A simple typo in either of these two parts of the A record
will cause users to not be able to locate your servers,
and they won't be able to access them
using your domain name.
For your CNAME or canonical name records, you need to ensure
that the domain name used as the source and destination
are both spelled properly.
Otherwise, you can be redirecting users to the wrong server
or to someplace that doesn't exist.
To verify your A name and CNAME records,
you can use the nslookup command.
Another common issue with DNS records is the time to live
or TTL might be set incorrectly.
If the time to live is set too high,
the old DNS records will remain cached
until the time to live expires.
So if you have a time to live of 86,400 seconds,
your DNS server records won't expire
or be refreshed by a DNS cache
until at least one day has elapsed.
In general, I like to keep my time to live
on my DNS server records at a pretty short interval,
something like 300 seconds, which is about five minutes.
This avoids any caching issues
if I'm making frequent changes
to my networks or my websites.
Now, another issue with DNS that occurs is one
of high latency.
If your DNS records are hosted far away from your users,
that's going to take more time and more delay
for them to access those records
when they're looking up a particular domain.
This is known as DNS latency.
To reduce DNS latency
and improve the overall network performance for your users,
you should use DNS servers
that are located closer to your users, such as one
that you host yourself within your DMZ or screen subnet,
or one hosted by your internet service provider directly.
Next, we're going to discuss NTP or the Network Time Protocol,
and there's some issues around this as well.
Remember, NTP is a protocol that allows the synchronization
of system clocks between different layers
of a hierarchical semi-layered system of time sources.
This is important
because many of our distributed applications
such as network authentication,
they're going to rely on proper synchronization of time
between your client and a server,
and our networks use NTP to do all of that.
In general, issues with NTP are caused
by the NTP packets not being received,
NTP packets may not be processed,
or the NTP packets have errors or packet loss.
If the NTP packets are not being received,
this needs to be trouble shot to determine the root cause.
You need to begin at the physical layer
and ensure your clients and servers are properly connected
and cabled to your network.
Then if the NTP server is on your local area network,
you need to verify it's communicating
between the client and the server,
using their MAC addresses properly.
If the NTP server is locate outside the local area network,
you need to verify that the client can communicate
to that server using layer three IP addresses
for that server.
Now, in general, if NTP packets are not being received,
this is more of a general network communication issue
at layer one, layer two, layer three,
or possibly a DNS server issue, if you're referring
to that NTP server using its domain name
and not its IP address.
Now, if the NTP packets are being received
but they're not being processed properly,
you need to look at the network client or the NTP server
to ensure they're operating the NTP service
to read and process those NTP packets
that are being sent and received by these devices.
If the NTP process or service doesn't act
on the NTP packets being received,
there's going to be network communication issues
with other services, things like HTTPS
and network authentication processes.
Now, if the NTP packets are processed but there's errors
or packet loss in them, there's going to be a loss
of time synchronization that can occur.
The loss of synchronization might occur if dispersion
or a delayed value for a server goes really high.
High values indicate that packets are taking way too long
to get to the client from the server
in reference to the root of the clock.
So the local machine cannot trust the accuracy
of the time present in the packet because it doesn't know
how long it took the packet to get there.
If there's a saturated link
or buffering is occurring along the way,
the packets can get delayed as they come to the NTP client.
Now, the timestamp contained within a subsequent NTP packet
can occasionally vary a lot,
and the local client cannot really adjust for that variance.
So if you're seeing errors or lost packets with NTP,
that's going to cause a lot of loss to synchronization for you,
and you need to ensure there's no saturation
in your network connections
and that your network connectivity is adequate
to be able to send the NTP packets in a timely manner.