1 1 00:00:00,320 --> 00:00:02,730 DNS and NTP Issues. 2 2 00:00:02,730 --> 00:00:05,630 In this video, we're going to discuss how to troubleshoot DNS 3 3 00:00:05,630 --> 00:00:07,190 and NTP issues. 4 4 00:00:07,190 --> 00:00:09,520 First let's focus on DNS. 5 5 00:00:09,520 --> 00:00:12,120 Remember, DNS is used to match the domain names 6 6 00:00:12,120 --> 00:00:13,700 with the corresponding IP addresses 7 7 00:00:13,700 --> 00:00:15,110 that are used by a server. 8 8 00:00:15,110 --> 00:00:17,210 This allows us to use memorable domain names 9 9 00:00:17,210 --> 00:00:19,060 while our computers can access the information 10 10 00:00:19,060 --> 00:00:20,710 using those IP addresses. 11 11 00:00:20,710 --> 00:00:21,670 If your network clients 12 12 00:00:21,670 --> 00:00:24,540 are unable to resolve their domain names to IP addresses 13 13 00:00:24,540 --> 00:00:26,590 such as figuring out that diontraining.com 14 14 00:00:26,590 --> 00:00:31,330 is supposed to point to 45.79.184.180, for example, 15 15 00:00:31,330 --> 00:00:34,020 then you most likely have a DNS issue. 16 16 00:00:34,020 --> 00:00:35,620 So first you needed to determine 17 17 00:00:35,620 --> 00:00:37,960 if the issue is occurring on a single network client, 18 18 00:00:37,960 --> 00:00:40,900 or is it a larger wide-scale DNS issue 19 19 00:00:40,900 --> 00:00:42,070 on your network? 20 20 00:00:42,070 --> 00:00:43,740 If it's only affecting one client, 21 21 00:00:43,740 --> 00:00:45,190 then it's most likely going to be an issue 22 22 00:00:45,190 --> 00:00:47,670 with that client's TCP/IP settings. 23 23 00:00:47,670 --> 00:00:50,770 By running the IP, ifconfig or ip commands, 24 24 00:00:50,770 --> 00:00:54,260 you can determine the IP address of the assigned DNS server. 25 25 00:00:54,260 --> 00:00:55,560 Once you have that IP, 26 26 00:00:55,560 --> 00:00:57,630 you should verify connectivity between your client 27 27 00:00:57,630 --> 00:00:59,060 and that DNS server. 28 28 00:00:59,060 --> 00:01:00,970 If there's no connectivity between them, 29 29 00:01:00,970 --> 00:01:03,220 then you need to troubleshoot the connection at layer one 30 30 00:01:03,220 --> 00:01:05,650 layer two, or layer three of the OSI model 31 31 00:01:05,650 --> 00:01:07,250 to fix this DNS issue, 32 32 00:01:07,250 --> 00:01:10,090 because your client simply can't reach the DNS server. 33 33 00:01:10,090 --> 00:01:12,180 If your client can reach the DNS server, 34 34 00:01:12,180 --> 00:01:13,830 but there's still a DNS issue, 35 35 00:01:13,830 --> 00:01:16,600 then you need to either flush the DNS cache on the client 36 36 00:01:16,600 --> 00:01:18,920 or change the configuration to allow the client 37 37 00:01:18,920 --> 00:01:20,440 to use a different DNS server. 38 38 00:01:20,440 --> 00:01:22,200 Something like Google's DNS servers 39 39 00:01:22,200 --> 00:01:26,010 located at 8.8.8.8 and 8.8.4.4. 40 40 00:01:26,010 --> 00:01:26,843 On the other hand, 41 41 00:01:26,843 --> 00:01:28,510 if a client doesn't seem to be having an issue 42 42 00:01:28,510 --> 00:01:29,830 with their configuration, 43 43 00:01:29,830 --> 00:01:31,620 it may be your DNS server itself 44 44 00:01:31,620 --> 00:01:33,180 is not properly responding. 45 45 00:01:33,180 --> 00:01:36,100 In this case, you're going to troubleshoot your DNS server. 46 46 00:01:36,100 --> 00:01:37,650 Now, this is usually going to be an issue 47 47 00:01:37,650 --> 00:01:39,950 specifically for people who run their own websites 48 48 00:01:39,950 --> 00:01:42,150 and control their own DNS records. 49 49 00:01:42,150 --> 00:01:43,150 In these cases, 50 50 00:01:43,150 --> 00:01:44,850 you need to verify that your A records 51 51 00:01:44,850 --> 00:01:47,470 and your CNAME records were properly created. 52 52 00:01:47,470 --> 00:01:48,620 With an A record, 53 53 00:01:48,620 --> 00:01:51,100 you need to ensure the domain name is typed in properly, 54 54 00:01:51,100 --> 00:01:53,570 and the IP address has been entered correctly. 55 55 00:01:53,570 --> 00:01:56,230 A simple typo on either of these two parts of the A record 56 56 00:01:56,230 --> 00:01:58,980 will cause users to not be able to locate your servers 57 57 00:01:58,980 --> 00:02:00,370 and they won't be able to access them 58 58 00:02:00,370 --> 00:02:01,910 using your domain name. 59 59 00:02:01,910 --> 00:02:04,290 For your CNAME or Canonical Name records, 60 60 00:02:04,290 --> 00:02:06,050 you need to ensure that the domain name used 61 61 00:02:06,050 --> 00:02:09,230 as the source and destination are both spelled properly, 62 62 00:02:09,230 --> 00:02:12,090 otherwise, you can be redirecting users to the wrong server 63 63 00:02:12,090 --> 00:02:14,330 or to someplace that doesn't exist. 64 64 00:02:14,330 --> 00:02:16,520 To verify your ANAME and CNAME records, 65 65 00:02:16,520 --> 00:02:18,730 you can use the nslookup command. 66 66 00:02:18,730 --> 00:02:20,500 Another common issue at DNS records 67 67 00:02:20,500 --> 00:02:21,670 is the Time to Live 68 68 00:02:21,670 --> 00:02:24,290 or TTL might be set incorrectly. 69 69 00:02:24,290 --> 00:02:26,120 If the Time to Live is set too high, 70 70 00:02:26,120 --> 00:02:28,230 the old DNS records will remain cached 71 71 00:02:28,230 --> 00:02:30,090 until the Time to Live expires. 72 72 00:02:30,090 --> 00:02:33,980 So if you have a Time to Live of 86,400 seconds, 73 73 00:02:33,980 --> 00:02:36,230 your DNS server records won't expire 74 74 00:02:36,230 --> 00:02:38,010 or be refreshed by DNS cache 75 75 00:02:38,010 --> 00:02:40,290 until at least one day has elapsed. 76 76 00:02:40,290 --> 00:02:42,400 In general, I like to keep my Time to Live 77 77 00:02:42,400 --> 00:02:45,120 on my DNS server records at a pretty short interval, 78 78 00:02:45,120 --> 00:02:46,950 something like 300 seconds, 79 79 00:02:46,950 --> 00:02:48,490 which is about five minutes. 80 80 00:02:48,490 --> 00:02:50,130 This avoids any caching issues 81 81 00:02:50,130 --> 00:02:51,990 if I'm making frequent changes to my networks 82 82 00:02:51,990 --> 00:02:53,340 or my websites. 83 83 00:02:53,340 --> 00:02:55,340 Now another issue with DNS that occurs 84 84 00:02:55,340 --> 00:02:56,960 is one of high latency. 85 85 00:02:56,960 --> 00:02:59,900 If your DNS records are hosted far away from your users, 86 86 00:02:59,900 --> 00:03:01,890 that's going to take more time and more delay 87 87 00:03:01,890 --> 00:03:03,400 for them to access those records 88 88 00:03:03,400 --> 00:03:05,470 when they're looking up a particular domain. 89 89 00:03:05,470 --> 00:03:07,600 This is known as DNS Latency. 90 90 00:03:07,600 --> 00:03:08,990 To reduce DNS latency 91 91 00:03:08,990 --> 00:03:11,420 and improve the overall network performance for your users, 92 92 00:03:11,420 --> 00:03:12,820 you should use DNS servers 93 93 00:03:12,820 --> 00:03:14,620 that are located closer to your users, 94 94 00:03:14,620 --> 00:03:15,880 such as one that you host yourself 95 95 00:03:15,880 --> 00:03:17,740 within your DMZ or screened subnet, 96 96 00:03:17,740 --> 00:03:21,090 or one hosted by your internet service provider directly. 97 97 00:03:21,090 --> 00:03:23,240 Next, we're going to discuss NTP 98 98 00:03:23,240 --> 00:03:24,850 or the Network Time Protocol. 99 99 00:03:24,850 --> 00:03:26,910 And there's some issues around this as well. 100 100 00:03:26,910 --> 00:03:28,950 Remember, NTP is a protocol 101 101 00:03:28,950 --> 00:03:31,260 that allows the synchronization of system clocks 102 102 00:03:31,260 --> 00:03:33,080 between different layers of a hierarchal, 103 103 00:03:33,080 --> 00:03:35,420 semi-layered system of time sources. 104 104 00:03:35,420 --> 00:03:36,253 This is important 105 105 00:03:36,253 --> 00:03:38,220 because many of our distributed applications, 106 106 00:03:38,220 --> 00:03:39,900 such as network authentication, 107 107 00:03:39,900 --> 00:03:42,450 they're going to rely on proper synchronization of time 108 108 00:03:42,450 --> 00:03:43,990 between your client and a server, 109 109 00:03:43,990 --> 00:03:47,210 and our networks use NTP to do all of that. 110 110 00:03:47,210 --> 00:03:48,970 In general, issues with NTP 111 111 00:03:48,970 --> 00:03:51,570 are caused by the NTP packets not being received. 112 112 00:03:51,570 --> 00:03:53,850 NTP packets may not be processed, 113 113 00:03:53,850 --> 00:03:57,310 or the NTP packets have errors or packet loss. 114 114 00:03:57,310 --> 00:03:59,600 If the NTP packets are not being received, 115 115 00:03:59,600 --> 00:04:00,433 this needs to be troubleshot 116 116 00:04:00,433 --> 00:04:02,430 to determine the root cause. 117 117 00:04:02,430 --> 00:04:04,020 You need to begin at the physical layer 118 118 00:04:04,020 --> 00:04:06,310 and ensure your clients and servers are properly connected 119 119 00:04:06,310 --> 00:04:07,820 and cabled to your network. 120 120 00:04:07,820 --> 00:04:10,800 Then if the NTP server is on your Local Area Network, 121 121 00:04:10,800 --> 00:04:12,180 you need to verify it's communicating 122 122 00:04:12,180 --> 00:04:13,760 between the client and the server 123 123 00:04:13,760 --> 00:04:15,730 using their MAC addresses properly. 124 124 00:04:15,730 --> 00:04:18,600 If the NTP servers located outside the Local Area Network, 125 125 00:04:18,600 --> 00:04:20,520 you need to verify that the client can communicate 126 126 00:04:20,520 --> 00:04:23,340 to that server using layer three IP addresses 127 127 00:04:23,340 --> 00:04:24,640 for that server. 128 128 00:04:24,640 --> 00:04:27,910 Now in general, if NTP packets are not being received, 129 129 00:04:27,910 --> 00:04:30,350 this is more of a general network communication issue 130 130 00:04:30,350 --> 00:04:32,630 at layer one, layer two, layer three, 131 131 00:04:32,630 --> 00:04:34,840 or possibly a DNS server issue, 132 132 00:04:34,840 --> 00:04:36,840 if you're referring to that NTP server 133 133 00:04:36,840 --> 00:04:39,500 using its domain name and not its IP address. 134 134 00:04:39,500 --> 00:04:41,900 Now, if the NTP packets are being received, 135 135 00:04:41,900 --> 00:04:43,940 but they're not being processed properly, 136 136 00:04:43,940 --> 00:04:46,940 you need to look at the network client or the NTP server 137 137 00:04:46,940 --> 00:04:49,160 to ensure they're operating the NTP service 138 138 00:04:49,160 --> 00:04:51,460 to read and process those NTP packets 139 139 00:04:51,460 --> 00:04:53,880 that are being sent and received by these devices. 140 140 00:04:53,880 --> 00:04:55,900 If the NTP process or service 141 141 00:04:55,900 --> 00:04:58,500 doesn't act on the NTP packets being received, 142 142 00:04:58,500 --> 00:05:00,240 there's going to be network communication issues 143 143 00:05:00,240 --> 00:05:02,930 with other services, things like HTTPS 144 144 00:05:02,930 --> 00:05:05,120 and network authentication processes. 145 145 00:05:05,120 --> 00:05:07,310 Now, if the NTP packets are processed, 146 146 00:05:07,310 --> 00:05:09,560 but there's errors or packet loss in them, 147 147 00:05:09,560 --> 00:05:11,590 there's going to be a loss of time synchronization 148 148 00:05:11,590 --> 00:05:12,670 that can occur. 149 149 00:05:12,670 --> 00:05:14,620 The loss of synchronization might occur 150 150 00:05:14,620 --> 00:05:18,090 if dispersion or delayed value for server goes really high. 151 151 00:05:18,090 --> 00:05:20,960 High values indicate that packets are taking way too long 152 152 00:05:20,960 --> 00:05:22,810 to get to the client from the server 153 153 00:05:22,810 --> 00:05:24,550 in reference to the root of the clock. 154 154 00:05:24,550 --> 00:05:27,610 So the local machine cannot trust the accuracy of the time 155 155 00:05:27,610 --> 00:05:28,880 present in the packet 156 156 00:05:28,880 --> 00:05:30,060 because it doesn't know how long 157 157 00:05:30,060 --> 00:05:31,700 it took the packet to get there. 158 158 00:05:31,700 --> 00:05:32,930 If there's a saturated link 159 159 00:05:32,930 --> 00:05:34,730 or buffering is occurring along the way, 160 160 00:05:34,730 --> 00:05:35,870 the packets can get delayed 161 161 00:05:35,870 --> 00:05:37,820 as they come to the NTP client. 162 162 00:05:37,820 --> 00:05:41,030 Now, the timestamp contained within a subsequent NTP packet 163 163 00:05:41,030 --> 00:05:42,600 can occasionally vary a lot 164 164 00:05:42,600 --> 00:05:45,690 and the local client cannot really adjust for that variance. 165 165 00:05:45,690 --> 00:05:47,390 So if you're seeing errors 166 166 00:05:47,390 --> 00:05:49,120 or lost packets with NTP, 167 167 00:05:49,120 --> 00:05:51,600 that's going to cause a lot of loss of synchronization for you. 168 168 00:05:51,600 --> 00:05:53,570 And you need to ensure that there's no saturation 169 169 00:05:53,570 --> 00:05:54,850 in your network connections 170 170 00:05:54,850 --> 00:05:56,800 and that your network connectivity is adequate 171 171 00:05:56,800 --> 00:05:59,500 to be able to send the NTP packets in a timely manner. 172 172 00:06:00,388 --> 00:06:02,783 (gentle music)