11 giải pháp khắc phục sự cố DNS Resolution

1. Kiểm tra kết nối mạng

Trong rất nhiều trường hợp khi bạn mở trình duyệt Web và nhập một URL vào đó, nhưng URL thất bại chẳng thể truy cập được trang Web. Trường hợp này nguyên do bạn nghĩ đến trước mắt là vì lỗi DNS. Tuy nhiên thực tế thì trong tình huống này lý do cũng có thể có thể là do kết nối mạng của bạn.

Điều này càng đúng hơn nếu bạn sử dụng Laptop và kết nối mạng bằng Wifi. Với giao thức bảo mật không dây, key sẽ có “điều đình” lại hoặc cường độ tín hiệu của sóng vô tuyến sẽ bị yếu dần, dẫn đến kết nối mạng bị mất.

Nguyên nhân mất kết nối mạng có thể xảy ra trên bất kỳ loại mạng nào.

Nói cách khác, trước lúc đổ lỗi cho DNS, hãy bắt đầu khắc phục sự cố bằng cách kiểm tra “OSU Layer 1 – Physical” đầu tiên sau đó kiểm tra kết nối mạng của bạn.

Lưu ý về cách Access là Local and Internet . Nếu Access hiển thị là Local , đồng nghĩa với việc địa chỉ mạng của bạn không hợp thức (trong trường hợp này, bạn chỉ hiện hữu một APIPA riêng bắt đầu với địa chỉ 169.x.x.x).

Tiếp theo bạn cần đảm nói rằng bạn có 1 địa chỉ IP hợp thức trên hệ thống mạng. Bạn cũng có thể có thể kiểm tra địa chỉ IP của mình bằng cách vào View Status sau đó chọn Details , kiểm tra địa chỉ IP và xác nhận địa chỉ IP của DNS Server. Nếu địa điểm IP của bạn là 169.x.x.x cùng nghĩa với việc bạn chẳng thể kết nối Internet được.

2. Xác nhận địa điểm IP của DNS Server là “chuẩn” và đúng thứ tự

Sau khi bạn có địa điểm IP hợp lệ và cũng đều có thể kết nối được Internet, giờ đây bạn cũng đều có thể đi sâu vào các vấn đề bên trong DNS bằng cách xác nhận lại địa chỉ IP của DNS Server đã chuẩn và đúng thứ tự hay chưa.

Nếu quan sát trong hình thứ 2 ở trên bạn cũng có thể nhìn thấy địa điểm IP của IPv4 DNS Server. Lưu ý rằng địa điểm IP của IPv4 DNS Server IP lẫn cả về Local LAN / Subnet để bạn cũng đều có thể truy cập, thậm chí trong tình huống nếu cổng mặc định bị hỏng.

Đây là cách nó làm việc trên hầu hết các mạng doanh nghiệp. Mặc dù vậy, các máy chủ DNS của bạn không phải khi nào cũng nằm trên subnet. Trong thự tế, với hầu hết các ISP, các IP của DNS Server cho dù còn không nằm trên cùng subnet với cổng mặc định (default gateway).

Trong đa số các cấu hình router của gia đình hay các doanh nghiệp vừa và nhỏ (home/SMB) không có các máy server DNS riêng và các SMB router sẽ proxy (ủy nhiệm) DNS đến các máy chủ DNS thực. Trong trường hợp đó, địa điểm IP của DNS Server có thể cùng với địa chỉ IP Router của bạn.

Cuối cùng, bảo hiểm rằng DNS Server của bạn nằm đúng thứ tự. Trong tình huống bộc lộ trong hình 2, DNS Server nội bộ là 10.0.1.20. Nó được cấu hình để “forward” mọi thứ các tên miền mà nó không thể phân giải đến 10.0.1.1, địa chỉ router nội bộ. Router đó sẽ proxy DNS đến DNS Server của ISP. Chúng ta thể tra cứu các DNS Server đó trên router của mình, xem bộc lộ trong hình 3.

Đầu tiên, cần đáp ứng rằng DNS Server của bạn nằm ngay đúng thứ tự. Nếu tình huống bạn có 1 local DNS Server, giống như trên và đang tra cứu tên miền nội bộ (local DNS name), muốn PC client tra cứu local DNS name đó trong local DNS Server đầu tiên, trước Internet DNS Server. Khi đó, local DNS server của bạn cần nằm trước mắt trong các thiết lập DNS.

Thứ hai, bạn cũng có thể ping địa điểm IP của DNS Server của ISP. Theo cách này, chỉ cần các DNS server được liệt kê nằm ở trên router của mình, bạn có thể thẩm định rằng mình cũng có thể ping chúng thậm chí từ máy tính nội bộ của mình:

Lưu ý về thời gian đáp trả khi ping đến DNS Server của ISP. Quá trình này cũng đều có thể làm chậm các tra cứu DNS hoặc thậm chí còn cũng có thể có thể làm thất bại nếu nó mất quá lâu thời gian để DNS server đáp trả.

Lưu ý về thời gian đáp trả từ động thái ping của bạn đến DNS Server của ISP. Điều này còn có thể làm chậm các tra cứu DNS hoặc thậm chí còn cũng có thể làm thất bại nếu nó mất quá lâu thời gian để DNS server đáp trả.

3. Ping địa điểm IP của host mà bạn mong muốn (trường hợp nếu bạn biết)

Cách mau chóng để minh chứng lỗi là vì DNS chứ không phải do sự cố kết nối mạng đó là ping địa chỉ IP của Host mà bạn muốn truy cập đến. Nếu kết nối đến tên miền thất bại nhưng kết nối đến địa chỉ IP thành đạt cùng nghĩa với việc vấn đề của bạn nằm ở DNS.

Tuy nhiên nếu DNS Server của bạn không hoạt động thì rất khó có thể chỉ ra địa chỉ IP mà bạn đang kết nối đến là gì. Để thực hành test này, bạn cần thiết 1 lược đồ (diagram) mạng hoặc giống như nhiều Admin vẫn thực hiện, chỉ cần nhớ địa điểm IP của host.

Nếu làm việc, đợi cho tới khi DNS server khả dụng lần nữa, bạn có thể đặt một entry trong file hosts của mình để map IP đến hostname.

4. Tìm DNS server đang được dùng bằng nslookup

Bạn có thể sử dụng lệnh nslookup để tìm kiếm các thông tin về DNS resolution của mình. Một trong những cách dễ dàng là bạn cũng có thể sử dụng lệnh này để xem DNS server nào đang cung cấp cho bạn lời giải đáp và DNS server nào không.

Lưu ý trong hình 5, DNS server của ISP đã cung cấp cho chung ta tin tức “non-authoritative answer”, có nghĩa rằng nó không cấu hình miền nhưng vẫn có thể cung cấp hồi đáp.

Ngoài ra bạn cũng có thể sử dụng lệnh này để đối chiếu các hồi đáp từ các DNS server không giống nhau bằng phương pháp cung cấp DNS server nào sử dụng.

5. Kiểm tra hậu tố DNS

Nếu bạn đang tra cứu host nội bộ trên một DNS server mà máy tính của bạn là 1 thành viên nằm trong đó, lúc đó bạn cũng đều có thể kết nối đến một host, chẳng cần dùng FQDN (fully qualified DNS name) và hy vọng vào hậu tố của DNS có thể giúp bạn tìm ra vấn đề.

Cho ví dụ, nếu chúng ta kết nối đến “server1”, DNS server có thể có nhiều entry cho tên miền đó. Khi đó Network Adaptor của bạn sẽ được cấu hình với hậu tố DNS kết nối.

Chẳng hạn như thí dụ trong hình 2, DNS là wiredbraincoffee.com. Do đó bất cứ lúc nào bạn nhập vào một tên miền như server1, hậu tố DNS sẽ có bổ sung vào phần cuối của nó để hình thành server1.wiredbraincoffee.com.

Bạn nên xác nhận hậu tố DNS của mình là đúng.

6. Đảm bảo rằng các thiết lập DNS của bạn được cấu hình để “kéo” IP của DNS từ máy chủ DHCP

Cũng giống như khi bạn mong muốn Network Adaptor của mình “thu” được các địa chỉ IP của DNS Server từ DHCP Server. Nếu giám sát vào hình trên, bạn có thể nhìn thấy daptor này đã được ghi rõ các địa điểm IP của DNS Server.

Hình 6: Thẩm định các thiết lập của DNS Server

Bạn phải thay đổi “Obtain DNS server address automatically” theo thứ tự để hoàn thành được được IP mới của DNS server. Để thực hiện điều đó, bạn chỉ cần mở thẻ Properties của Network Adaptor, sau đó click vào Internet Protocol Version 4 (TCP/IPv4).

7. Giải phóng và “làm mới” địa điểm IP của DHCP Server (và cả tin tức DNS)

Dù Adaptor của bạn đã được thiết lập để kéo các tin tức DNS từ DHCP, tuy nhiên trong 1 số tình huống nó có thể diễn ra hiện tượng xung đột địa điểm IP hoặc nhận phải các thông tin DNS server cũ. Chính vì thế sau khi đã chọn lựa “thu nhận” địa chỉ IP và DNS tự động, bạn nên “giải phóng” địa điểm IP của mình và “renew – làm mới” nó.

Bạn cũng có thể có thể thi hành điều đó với Windows Diagnosis trong cấu hình Network của mình. Tuy nhiên cách nhanh đặc biệt là sử dụng Command prompt. Nếu bạn đã kích hoạt UAC, chạy lệnh cmd của Windows dưới quyền Amin:

IPCONFIG /RELEASE

IPCONFIG /RENEW

Sau đó, thực hành với lệnh IPCONFIG /ALL để xem các thông tin IP và DNS mới như thế nào.

8. Kiểm tra DNS Server và restart các công ty hoặc reboot nếu cần có

Rõ ràng, nếu DNS server bị treo hoặc bị hỏng, hoặc bị cấu hình sai, bạn sẽ không thể khắc phục điều ấy tại Client side. Tuy nhiên bạn có thể bypass máy chủ bị lỗi đó chứ không thể khắc phục được lỗi.

Theo cách đó, Admin – người nhận trách nhiệm cho DNS server sẽ phải kiểm tra tình trạng và cấu hình của DNS server để khắc phục vấn đề DNS.

9. Khởi động lại Router DNS công sở nhỏ hay gia đình

Như đã nhắc đến ở trên trong cách thứ hai và được hiển thị trong hình minh họa thứ 3, trên các router của gia đình và các văn phòng nhỏ, thiết lập DNS server thường được thực hành thông qua DHCP với DNS server thiết lập một địa chỉ IP của router và router sẽ proxy DNS đến DNS server của ISP.

Tuy vậy, máy tính nội bộ của bạn có thể có những tin tức mạng (gồm có các địa chỉ IP của DNS server), nhưng cũng có thể có tình huống router của bạn có thông tin sai. Để bảo đảm rằng router của bạn có những thông tin DNS server mới nhất, bạn cũng có thể có thể thi hành “giải phóng” một DHCP và “renew – làm mới” giao diện WAN của router với ISP. Hoặc cách đơn giản hơn cũng có thể là reboot router để nó nhận được những tin tức mới nhất.

10. Liên hệ với ISP

Tất cả chúng ta đều hiểu được việc liên lạc với một ISP để khắc phục một vấn đề về mạng sẽ nhức mỏi như thế nào. Tuy nhiên nếu máy tính của bạn vẫn gặp vấn đề về DNS resolution từ các máy server DNS của ISP thì bạn phải phải liên lạc với họ, và kia cũng chính là cách xử lý cuối cùng.

11. Kiểm tra DNS Resolution từ một hệ thống khách

Các công ty thường chạy DNS server của riêng mình và sử dụng nó để phân giải tên DNS thành địa chỉ IP Private, nhằm giúp cho người sử dụng đơn giản truy cập hệ thống hơn. Một thí dụ dễ dàng để hình dung là yêu cầu một người dùng hãy khởi động chương trình khách Remote Desktop của họ và kết nối với server1 thay vì kết nối với 192.168.70.243.

OpenVPN Access Server hỗ trợ đẩy một lệnh đến một máy khách OpenVPN đang kết nối để sử dụng một DNS server cụ thể. Trên thực tế nó hỗ trợ đẩy 2 DNS server, trong tình huống server đầu tiên không phản hồi. Điều này còn cũng đều có thể được cấu hình trong Admin UI (giao diện người dùng quản trị) thuộc phần VPN Settings. Access Server cũng bổ trợ gửi các chỉ dẫn bổ sung cho DNS Resolution Zones , có chức năng giống như 1 kiểu phân tách DNS, mà chỉ các truy vấn cho 1 vùng DNS cụ thể được gửi đến máy server VPN và DNS Default Suffix (Hậu tố mặc định DNS), cung cấp gợi ý cho Windows để 'tự động hoàn thành' tên máy server thành Fully Qualified Domain Name hoặc FQDN.

Thật không may, không phải mọi hệ điều hành đều hoạt động giống nhau, xét về DNS. Một số hệ thống sẽ thử mọi thứ các DNS server cùng một lát và chấp nhận server phản hồi đầu tiên. Những server khác sẽ được thể làm phân chia DNS, và những server khác thì không. Điều này có thể dẫn đến một số vấn đề nhất định. Hướng dẫn bên dưới cung cấp 1 cách kiểm tra xem liệu truy vấn DNS bạn đang thi hành từ thiết bị khách OpenVPN có đang thực hành thông qua VPN tunnel tới OpenVPN Access Server hay không. Và từ đó, tất nhiên, sẽ đến DNS server đích. Thông tin này có mức giá trị trong việc xác định phía máy khách có gặp vấn đề hay không, hoặc lỗi là vì máy chủ.

Bài viết sẽ giả định rằng bạn có 1 DNS server được cấu hình trong Admin UI của Access Server, thuộc phần VPN Settings. Giả định rằng bạn không sử dụng DNS Resolution Zones hoặc các trường DNS Default Suffix. Với cài đặt này, tất cả yêu cầu DNS sẽ được chuyển từ máy khách OpenVPN, thông qua OpenVPN Access Server và sau đó đến DNS server được chỉ định. Trong tỉ dụ ở bài viết này, ta đang đẩy Google Public DNS server 8.8.8.8 và các kết quả thử nghiệm cũng sẽ phản ánh điều ấy trong số kết quả đầu ra mẫu.

Hãy cài đặt chương trình OpenVPN trên hệ thống khách đã chọn. Trong ví dụ ở bài viết này, ta sẽ sử dụng một hệ thống máy khách Windows 10 Professional với OpenVPN Connect Client được cài đặt và kết nối với OpenVPN Access Server. Tiếp theo, mở một phiên giao diện điều khiển hoặc phiên SSH tới OpenVPN Access Server và nhận các đặc quyền root. Ta sẽ sử dụng công cụ tcpdump để quan sát hoạt động trên cổng 53 TCP và UDP, cổng mặc định nơi các truy vấn DNS được xử lý. Ta sẽ xóa bộ nhớ cache của trình phân giải DNS cục bộ ở phía máy khách, sau đó phân giải một số tên miền dễ dàng bằng phương pháp ping chúng theo tên.

Trong tình huống thí nghiệm này, chỉ có 1 số ít các máy khách được kết nối và hoạt động của các truy vấn DNS rất thấp, để bạn đọc có thể theo dấu dễ dàng. Nếu bạn đang thử nghiệm trên một hệ thống sản xuất và lệnh tcpdump cho quá nhiều đầu ra, bạn có thể nối thêm 1 bộ lọc grep theo địa điểm IP, để lọc truy vấn chỉ còn địa điểm IP của máy khách VPN cụ thể, để đọc và xác định kết quả truy vấn DNS dễ dàng hơn .

Trên Access Server, hãy chạy các lệnh sau:

   apt-get update apt-get install tcpdump   

Với TCPdump đã được cài đặt, hãy chạy nó với các tham số sau:

   tcpdump -eni any port 53   

Hoặc, nếu bạn mong muốn lọc nó theo địa điểm IP của máy khách VPN (điều chỉnh khi cần):

   tcpdump -eni any port 53 | grep "172.27.10.22"   

Sau lúc chạy lệnh này trong chế độ nền, hãy đi đến hệ điều hành máy khách VPN của bạn, và mở một command prompt. Trên Windows, ví dụ, bạn có thể chạy chương trình cmd để mở một DOS prompt kiểu cũ. Khi mở, sử dụng các lệnh sau để xóa bộ nhớ cache của trình phân giải DNS cục bộ, vì vậy nó sẽ không lấy kết quả từ bộ nhớ cục bộ của riêng nó, sau đó thực hiện truy vấn thực tế.

Xóa cache trình phân giải DNS cục bộ trên Windows:

   ipconfig /flushdns   

Phân giải một số tên miền:

   ping www.google.com ping www.openvpn.net ping www.facebook.com   

Mỗi tên miền trong các này sẽ đem lại kết quả trông giống như sau:

   Pinging www.google.com [216.58.212.228] with 32 bytes of data: Reply from 216.58.212.228: bytes=32 time=4ms TTL=56 Reply from 216.58.212.228: bytes=32 time=3ms TTL=56 Reply from 216.58.212.228: bytes=32 time=3ms TTL=56 Reply from 216.58.212.228: bytes=32 time=3ms TTL=56 Ping statistics for 216.58.212.228: Packets: Sent = 4, Received = 4, Lost = 0 (0% loss), Approximate round trip times in milli-seconds: Minimum = 3ms, Maximum = 4ms, Average = 3ms   

Trên OpenVPN Access Server, bạn sẽ thấy kết quả trông giống như sau:

   18:03:07.976553 In ethertype IPv4 (0x0800), length 76: 172.27.232.2.49531 >  8.8.8.8.53: 53268+ A? www.google.com. (32) 18:03:07.976579 Out 00:0c:29:c7:60:e9 ethertype IPv4 (0x0800), length 76: 192.168.47.133.49531 >  8.8.8.8.53: 53268+ A? www.google.com. (32) 18:03:07.981162 In 34:31:c4:8e:b5:67 ethertype IPv4 (0x0800), length 92: 8.8.8.8.53 >  192.168.47.133.49531: 53268 1/0/0 A 216.58.211.100 (48) 18:03:07.981181 Out ethertype IPv4 (0x0800), length 92: 8.8.8.8.53 >  172.27.232.2.49531: 53268 1/0/0 A 216.58.211.100 (48)   

Kết quả trên từ tcpdump cho hiểu được một yêu cầu DNS đã được trao từ máy khách VPN tại 172.27.232.2, và nó được chuyển hướng đến máy server DNS ở 8.8.8.8. Trong đó yêu cầu là tìm bản ghi A (địa chỉ IP) cho tên DNS www.google.com. Dòng đầu tiên cho biết yêu cầu này đang đến OpenVPN Access Server, từ máy khách VPN. Dòng thứ 2 cho thấy yêu cầu rời khỏi máy chủ truy cập thông qua giao diện mạng, với địa điểm MAC 00:0c:29:c7:60:e9. Trong thiết lập thí nghiệm ở bài viết này, này là giao diện mạng của Access Server đi vào Internet. Điều này còn có ý nghĩa là máy chủ DNS 8.8.8.8 có trên Internet. Dòng thứ ba cho biết kết quả DNS đã được nhận và dòng thứ tư cho biết kết quả này đã được chuyển tiếp trở lại máy khách VPN. Trong tình huống này, DNS resolution đang hoạt động.

Các lỗi và lý do phổ biến

Dưới đây là một số vấn đề thông dụng và nơi mà bạn cũng đều có thể tìm một biện pháp xử lý.

Ping request could not find domain (…).

Giải pháp : Vui lòng kiểm tra tên và thử lại.

Điều này còn cũng có thể có thể diễn ra khi máy chủ DNS mà hệ thống khách của bạn đang sử dụng bị cấu hình kém, chẳng thể truy cập được, hoặc nếu máy chủ DNS đang sử dụng không biết miền bạn đang cố phân giải là gì. Ví dụ với các máy server DNS cục bộ trong mạng của bạn, rất có thể là chúng chỉ biết các hệ thống máy tính cục bộ và không có kiến ​​thức về các tên trực tuyến như openvpn.net hay tương tự như vậy. Thông thường trong trường hợp này, bạn cũng đều có thể cấu hình máy chủ DNS để chuyển tiếp các truy vấn DNS đến một máy chủ DNS Public mà không biết lời giải đáp cho các truy vấn đó, để nó có thể trả lời cả 2 truy vấn cho tên cục bộ và tên công khai. Một bước hữu ích trong tình huống này cũng đều có thể là chạy lại tcpdump như miêu tả trong phần thí nghiệm DNS resolution từ phần hệ thống máy khách ở trên, và kiểm tra xem đầu ra của tcpdump là gì.

Nếu bạn thấy kết quả như sau:

   18:07:10.082330 In ethertype IPv4 (0x0800), length 94: 172.27.232.2.54519 >  8.8.8.8.53: 50281+ A? thisdomainreallydoesnotexist.com. (50) 18:07:10.082356 Out 00:0c:29:c7:60:e9 ethertype IPv4 (0x0800), length 94: 192.168.47.133.54519 >  8.8.8.8.53: 50281+ A? thisdomainreallydoesnotexist.com. (50) 18:07:10.082507 In ethertype IPv4 (0x0800), length 94: 172.27.232.2.57858 >  8.8.8.8.53: 65054+ AAAA? thisdomainreallydoesnotexist.com. (50) 18:07:10.082521 Out 00:0c:29:c7:60:e9 ethertype IPv4 (0x0800), length 94: 192.168.47.133.57858 >  8.8.8.8.53: 65054+ AAAA? thisdomainreallydoesnotexist.com. (50) 18:07:10.103610 In 34:31:c4:8e:b5:67 ethertype IPv4 (0x0800), length 167: 8.8.8.8.53 >  192.168.47.133.54519: 50281 NXDomain 0/1/0 (123) 18:07:10.103641 Out ethertype IPv4 (0x0800), length 167: 8.8.8.8.53 >  172.27.232.2.54519: 50281 NXDomain 0/1/0 (123)   

Cụ thể là mục NXDomain ở đây rất quan trọng. Nó có tức là DNS server này sẽ không biết tên miền mà ta đang cố gắng phân giải. Một DNS khác vẫn có thể biết tên domain, nhưng DNS này thì không. Tuy nhiên, trong ví dụ trên, ta đã chọn tên không tồn tại (hoặc tối thiểu là không khi ta chạy thí nghiệm – đương nhiên cũng có thể ai đó sẽ đăng ký tên này trong tương lai) một cách có chủ đích để chắc chắn lỗi sẽ xảy ra. Nếu bạn mắc phải sự cố này, bạn cũng có thể có thể thử sử dụng chương trình nslookup trên máy tính có quyền truy cập trực diện vào máy server DNS, và sử dụng nó để truy vấn trực diện vào máy chủ DNS cụ thể để xác nhận rằng nó biết domain đó.

Nếu bạn thấy kết quả như thế này, hãy tái diễn một vài lần:

   18:19:29.935439 Out 00:0c:29:c7:60:e9 ethertype IPv4 (0x0800), length 76: 192.168.47.133.60180 >  1.2.3.4.53: 16427+ AAAA? www.google.com. (32) 18:19:29.935479 In ethertype IPv4 (0x0800), length 76: 172.27.232.3.51334 >  1.2.3.4.53: 37513+ A? www.google.com. (32)   

Sau đó, những gì bạn cũng đều có thể thấy tại đây là một truy vấn tới từ máy khách VPN, đi qua Access Server, sau đó ra ngoài Internet, nhưng không có phản hồi. Thông thường, điều ấy có tức là máy chủ DNS này không thể truy cập được, hoặc đó không phải là máy chủ DNS. Trong ví dụ, người sáng tác đã chọn địa điểm IP 1.2.3.4, thứ chắc chắn chẳng cần là một máy chủ DNS. Rõ ràng truy vấn sẽ được tái diễn một vài lần nhưng cuối cùng sẽ thất bại.

Giải pháp rõ rệt ở đây là chọn một máy chủ DNS hoạt động, hoặc, để đảm nói rằng không có tường lửa nào đang chặn các truy vấn từ những máy khách VPN đến máy server DNS. Trong một số trường hợp, khi việc định tuyến được sử dụng để cung cấp cho máy khách VPN quyền truy cập vào máy server trên mạng riêng kết nối với Access Server, thì nguyên do là router bị thiếu. Trong tình huống này, các gói từ những máy khách VPN làm cho nó trở thành máy chủ DNS đích rất đáng tin cậy. Tuy nhiên, nó không thể phản hồi, vì nó nhận các gói từ một mạng con mà bản thân nó không biết phương pháp phản hồi. Điều đó cũng có thể có thể được xử lý bằng cách thi hành các tuyến tĩnh cho việc giao tiếp VPN khách trực tiếp, hoặc chuyển qua cho phép truy cập bằng NAT thay thế. Trong các tình huống khác, đặc biệt là trên các nền tảng Windows Server, Windows Firewall tích hợp có thể chặn truy vấn tới từ mạng con bên ngoài mạng cục bộ. Trong tình huống này, việc điều chỉnh tường lửa là luôn phải có để cấp phép máy chủ DNS nhận được truy vấn và phản hồi nó.

Tham khảo thêm 1 số bài viết dưới đây:

• Kiểm tra tốc độ Internet chẳng cần phần mềm

• 3 lý do “chính đáng” để đổi DNS Server

• Hướng dẫn thiết lập FTP Server cá nhân bằng FileZilla

Chúc các bạn thành công!

DNS,khắc phục sự cố,kết nối mạng,sự cố kết nối mạng,không kết nối được mạng,mạng bị sập,khắc phục lỗi DNS,DNS lỗi,DNS Server not responding,Không thể tìm thấy DNS Address máy chủ

Nội dung 11 giải pháp khắc phục sự cố DNS Resolution được tổng hợp sưu tầm biên tập bởi: Tin Học Trường Tín. Mọi ý kiến vui lòng gửi Liên Hệ cho truongtin.top để điều chỉnh. truongtin.top tks.