Lỗi phân giải DNS: 8 kịch bản, 4 nhóm bệnh và cách chẩn đoán, xử lý

Cả phòng gõ tên website nội bộ không vào được, nhưng ping thẳng IP thì thông suốt — chín trên mười lần, thủ phạm là phân giải DNS. Bài viết hệ thống hóa 8 kịch bản lỗi DNS theo 4 nhóm bệnh từ một bài lab thực chiến, kèm cách chẩn đoán bằng dig/nslookup và phòng ngừa cho mạng doanh nghiệp.

Tại sao lỗi DNS khiến cả hệ thống "tê liệt"?

DNS (Domain Name System — hệ thống phân giải tên miền) chuyển tên miền dễ nhớ thành địa chỉ IP để máy tính kết nối; gần như mọi kết nối — web, email, ứng dụng nội bộ — đều bắt đầu bằng một truy vấn DNS. Khi DNS lỗi, triệu chứng rất đa dạng: "không vào được web", "app báo lỗi kết nối" — đội hỗ trợ dễ sửa nhầm hướng trong khi gốc rễ chỉ là một truy vấn không được trả lời đúng. Vì thế các bài lab thực chiến chia lỗi DNS thành các "nhóm bệnh" có dấu hiệu riêng để khoanh vùng trong vài giây.

8 kịch bản, 4 nhóm bệnh

Bài lab gốc gom 8 ca lỗi vào 4 nhóm, phân loại theo bên đang "nói dối": máy chủ không trả lời, máy chủ trả lời "không có dữ liệu", máy chủ trả lời sai, hay chính máy khách chen ngang. Mỗi ca có dấu hiệu riêng khi chạy dig — công cụ truy vấn DNS chuẩn trên Linux/macOS.

Nhóm bệnh	Kịch bản lỗi	Dấu hiệu điển hình
1. Server không đáp	Timeout (hết thời gian chờ); máy chủ từ chối truy vấn; upstream (máy cấp trên) bị chặn	dig không nhận được phản hồi, hoặc nhận thông báo từ chối/lỗi truy vấn
2. Server đáp "không có"	NXDOMAIN — máy chủ trả lời rằng tên miền không tồn tại	Status: NXDOMAIN
3. Server đáp sai	Bản ghi vẫn trỏ về IP cũ sau khi chuyển máy chủ	Trả lời rất nhanh, có answer — nhưng IP không đúng
4. Client chen ngang	File /etc/hosts ghi đè; bộ đệm (cache) máy khách giữ IP cũ	dig trả kết quả đúng nhưng ứng dụng vẫn kết nối sai

Nhóm 1: Server không đáp

Máy chủ DNS im lặng hoặc khước từ. Ba biến thể: timeout — gói truy vấn đi mất (thường do firewall hoặc service không chạy); bị từ chối (refused) — máy chủ sống nhưng khước từ phục vụ, thường do cấu hình chỉ cho phép vài dải mạng; upstream bị chặn — máy chủ nội bộ không hỏi được máy chủ cấp trên (forwarder), nên mọi tên công cộng đều lỗi.

Nhóm 2: Server đáp "không có" — NXDOMAIN

Máy chủ phản hồi rõ ràng, nhưng nội dung là "không tồn tại" (NXDOMAIN — non-existent domain). Nguyên nhân: tên gõ sai chính tả, bản ghi chưa tạo trên zone nội bộ, hoặc vừa tạo nhưng chưa nhân bản đồng bộ (propagation) tới máy chủ đang trả lời.

Nhóm 3: Server đáp sai — bản ghi trỏ IP cũ

Nhóm nguy hiểm nhất vì hệ thống có vẻ hoạt động bình thường: truy vấn được trả lời nhanh gọn, có IP — nhưng là IP cũ sau khi dịch vụ chuyển sang máy chủ khác. Người dùng có nơi vào trang mới, có nơi vào trang cũ, có nơi không vào được gì.

Nhóm 4: Client chen ngang — /etc/hosts và bộ đệm

Ngay cả khi DNS hoàn toàn đúng, máy khách vẫn có thể tự "phá": file /etc/hosts (file ánh xạ tên thành IP cục bộ, được tra cứu trước DNS) còn dòng ghi cũ; hoặc bộ đệm DNS của hệ điều hành/trình duyệt (DNS cache) giữ kết quả cũ. Hay gặp sau các đợt chuyển IP: máy kỹ thuật viên thấy đúng, máy người dùng vẫn truy cập địa chỉ cũ.

Chẩn đoán từng nhóm trong vài giây

Quy trình khoanh vùng bắt đầu từ dấu hiệu trong câu trả lời của dig (hoặc nslookup trên Windows):

1. Đọc dòng status của dig ten-mien.vn: - Không phản hồi sau thời gian chờ → nhóm 1 (timeout): kiểm tra firewall và service DNS. - status: REFUSED → nhóm 1 (từ chối): rà lại cấu hình cho phép truy vấn (allow-recursion, ACL). - status: SERVFAIL → nhóm 1 (upstream): máy chủ nhận truy vấn nhưng không phân giải được — kiểm tra forwarder. - status: NXDOMAIN → nhóm 2: kiểm tra chính tả tên miền và zone/bản ghi tương ứng. - status: NOERROR kèm answer → so sánh IP trả về với IP thực của dịch vụ để bắt nhóm 3.
2. So sánh giữa các máy chủ DNS: chạy dig @8.8.8.8 ten-mien.vn và dig @1.1.1.1 ten-mien.vn, đối chiếu với DNS nội bộ. Khác nhau giữa các máy chủ → nhóm 2–3 phía máy chủ; giống nhau nhưng ứng dụng vẫn sai → nhóm 4 phía client.
3. Kiểm tra upstream từ máy chủ DNS: truy vấn thẳng máy chủ định danh có thẩm quyền để xác nhận dữ liệu gốc còn đúng hay đã cũ.
4. Kiểm tra client: đọc file /etc/hosts, xóa bộ đệm DNS (ipconfig /flushdns trên Windows, flush systemd-resolved/nscd trên Linux, xóa DNS cache trình duyệt), rồi thử lại.

Ghi nhớ câu chốt của bài lab: "dig chạy tốt không có nghĩa là DNS đúng." Nhóm 3 và 4 đều cho dig chạy "tốt" — server trả lời nhanh, có kết quả — nhưng kết quả sai hoặc bị ứng dụng bỏ qua, và đó chính là những ca khó nhất.

Lab thực hành với Docker Compose và dnsmasq

Điểm đáng học: cả 8 ca được dựng bằng Docker Compose (công cụ điều phối nhiều container) với dnsmasq — máy chủ DNS thật thay vì mô phỏng. Người học phải tự cấu hình bản ghi sai, tự chặn upstream, tự ghi đè /etc/hosts… rồi tự chẩn đoán bằng dig. Kiểu học "tự gây ra bệnh rồi tự chữa" cho hiểu sâu hơn đọc lý thuyết — mô hình tốt để đào tạo đội quản trị mạng.

Phòng ngừa cho mạng doanh nghiệp

Xử lý giỏi không bằng khỏi xảy ra; một số biện pháp chuẩn cho hạ tầng DNS doanh nghiệp:

• Chạy ít nhất hai máy chủ DNS nội bộ độc lập để một máy sự cố không làm tê liệt toàn bộ truy cập.
• Cấu hình forwarder dự phòng cho DNS nội bộ — khi upstream chính bị chặn, máy chủ tự chuyển sang đường khác.
• Giám sát chủ động: dò định kỳ các tên miền quan trọng từ nhiều vị trí trong mạng; cảnh báo sớm khi phản hồi chậm hoặc kết quả đổi bất thường.
• Hạ TTL trước các đợt chuyển IP: đặt thời gian sống bản ghi ngắn trong giai đoạn chuyển đổi để bộ đệm cũ hết hạn nhanh, rồi nâng lại sau khi ổn định.
• Quản lý tập trung file hosts: không sửa tay /etc/hosts trên máy trạm; mọi ánh xạ tùy chỉnh đưa vào DNS nội bộ và quản lý như cấu hình chính thức.
• Vận hành chuẩn hóa: tài liệu hóa quy trình xử lý sự cố DNS theo 4 nhóm bệnh trên để kỹ thuật viên trực ca xử lý được ngay cả lúc nửa đêm.

Khi nào cần đội hỗ trợ IT chuyên trách?

Với doanh nghiệp thiếu nhân sự mạng chuyên sâu, lỗi DNS thuộc nhóm sự cố "tốn giờ nhất để dò": triệu chứng lan khắp mọi ứng dụng nhưng không ứng dụng nào thực sự lỗi. Wotech cung cấp dịch vụ hỗ trợ IT và hạ tầng mạng doanh nghiệp — thiết kế, vận hành DNS nội bộ, giám sát hạ tầng, xử lý sự cố theo quy trình — giúp bạn không phải tự "làm bác sĩ" cho những căn bệnh mạng khó chẩn đoán.

Kết luận

Tám kịch bản lỗi DNS gói trong bốn nhóm bệnh — server không đáp, server đáp "không có", server đáp sai, client chen ngang — mỗi nhóm một dấu hiệu riêng qua dig. Nắm được bảng này, đội kỹ thuật chuyển từ dò mò sang khoanh vùng có hệ thống: đọc status, so sánh máy chủ, kiểm upstream, rồi tới client. Ở tầm vận hành, dự phòng và giám sát DNS luôn rẻ hơn một ngày toàn công ty "mất mạng".

Nguồn: tổng hợp từ chia sẻ kỹ thuật trên Facebook, biên tập bởi Wotech Electronics.

Doanh nghiệp của bạn đang gặp sự cố mạng nghi do DNS hoặc muốn chuẩn hóa hạ tầng mạng nội bộ? Liên hệ Wotech để được khảo sát, giám sát và hỗ trợ kỹ thuật chuyên nghiệp.