Chẩn đoán lỗi phân giải DNS: Hướng dẫn thực tế cho quản trị hệ thống và duy trì vận hành

DNS là xương sống thầm lặng của công việc quản trị CNTT hàng ngày và duy trì hệ thống vận hành. Khi DNS gặp sự cố, ứng dụng停滞, chứng chỉ thất bại và người dùng thấy các thông báo lỗi khó hiểu. Một cách tiếp cận kỷ luật giúp bạn truy vết lộ trình từ máy khách, qua trình phân giải, đến các bản ghi chủ quyền và cuối cùng là các phụ thuộc upstream. Bài viết này giải thích lộ trình đó và chỉ dẫn cách khắc phục sự cố phân giải DNS trên các lớp máy khách và máy chủ bằng các bước kiểm tra lặp lại được, cách sửa an toàn và khả năng quan sát có thể duy trì lâu dài.

Hiểu lộ trình phân giải trước khi thay đổi bất cứ thứ gì

Khi một ứng dụng yêu cầu một tên, hệ điều hành máy khách kiểm tra các gợi ý cục bộ, sau đó hỏi trình phân giải đã cấu hình. Trình phân giải đó có thể là máy chủ chuyển tiếp nội bộ, dịch vụ đệ quy công khai hoặc cả hai. Trình phân giải duyệt qua các bộ nhớ đệm, kiểm tra gợi ý gốc, hỏi các máy chủ cấp cao nhất của miền tương ứng và đến các máy chủ chủ quyền của vùng. Chỉ khi đó nó mới trả về câu trả lời. Sự cố có thể xảy ra ở bất kỳ chặng nào và triệu chứng thường giống nhau: tên không phân giải được.

Trước khi thay đổi cài đặt, hãy ghi lại chính xác tên bị lỗi, chủ máy khách, trình phân giải đang dùng và thời điểm xảy ra sự cố. Bối cảnh này giúp bạn tránh suy đoán và so sánh các lộ trình khỏe mạnh với lộ trình hỏng.

Bắt đầu từ máy khách và xác minh các điều cơ bản

Hãy bắt đầu với những dữ kiện đơn giản nhất. Xác nhận máy khách có địa chỉ IP dùng được, mặt nạ mạng con chính xác và cổng mặc định hoạt động. Kiểm tra hệ thống có trỏ đến trình phân giải dự định hay không. Trên Linux, xem xét /etc/resolv.conf và bất kỳ cấu hình systemd resolved hoặc NetworkManager nào. Trên Windows, dùng Get-DnsClientServerAddress và ipconfig /all. Trên macOS, dùng scutil –dns. Nhiều sự cố bắt nguồn từ bộ điều hợp cấu hình sai, VPN split tunnel cũ hoặc container hoàn toàn không có cấu hình DNS.

Xóa bộ nhớ đệm máy khách sau khi xác nhận cấu hình. Trên Windows, chạy ipconfig /flushdns. Trên Linux với systemd resolved, chạy resolvectl flush-caches. Trên macOS, chạy sudo dscacheutil -flushcache và sudo killall -HUP mDNSResponder. Một mục bộ nhớ đệm âm cũ có thể chặn vùng vừa sửa không phân giải được.

Dùng các truy vấn có mục tiêu để cô lập vấn đề. Thử truy vấn trực tiếp đến trình phân giải đã cấu hình, sau đó đến trình phân giải công khai nổi tiếng, sau đó đến chính máy chủ chủ quyền nếu có thể. Ví dụ, dùng dig hoặc nslookup để yêu cầu chính xác loại bản ghi mà ứng dụng cần. So sánh các câu trả lời. Nếu tên phân giải được qua trình phân giải công khai nhưng không qua trình phân giải nội bộ, hãy tập trung vào chuyển tiếp nội bộ, quy tắc split horizon hoặc quy tắc firewall giữa trình phân giải và internet.

Kiểm tra trình phân giải và lớp bộ nhớ đệm

Các trình phân giải thường che giấu nguyên nhân thực sự. Nếu bạn chạy trình phân giải đệ quy nội bộ, hãy kiểm tra xem nó có thể kết nối internet hoặc các forwarder hay không. Xác minh UDP và TCP cổng 53 được phép đi ra ngoài và firewall hoặc NAT không làm hỏng định tuyến phản hồi. Nếu trình phân giải dùng DNS over TLS hoặc DNS over HTTPS, hãy xác nhận chứng chỉ hợp lệ và thời gian trên trình phân giải chính xác. Sai lệch thời gian làm hỏng bắt tay TLS và khiến xác thực DNSSEC thất bại.

Rà soát nhật ký tìm các mục SERVFAIL, REFUSED và timeout. Nếu bạn thấy SERVFAIL thường xuyên, hãy kiểm tra xác thực DNSSEC. Dùng dig với +dnssec và +cd để so sánh phản hồi đã xác thực và chưa xác thực. Nếu xác thực thất bại, hãy kiểm tra trình phân giải có thời gian chính xác, có thể kết nối vùng cha và vùng con và có các trust anchor cần thiết. Nếu bạn vận hành DNS split horizon, hãy đảm bảo máy khách nội bộ không bao giờ để lộ tên nội bộ cho trình phân giải công khai và quy tắc split khớp chính xác với các mạng nguồn.

Đo độ trễ và tỷ lệ lỗi từ trình phân giải. Xuất các chỉ số trình phân giải sang hệ thống giám sát, bao gồm truy vấn mỗi giây, tỷ lệ trúng bộ nhớ đệm, thời gian phản hồi trung bình và mã lỗi. Sự sụt giảm đột ngột tỷ lệ trúng bộ nhớ đệm thường chỉ ra forwarder hỏng hoặc thay đổi khả năng tiếp cận upstream.

Kiểm tra bản ghi, vùng và phụ thuộc upstream

Nếu trình phân giải có vẻ khỏe mạnh, hãy chuyển upstream. Xác nhận các máy chủ chủ quyền có thể tiếp cận và phản hồi. Dùng dig để truy vấn các bản ghi NS của vùng và sau đó truy vấn trực tiếp các máy chủ đó. Xác minh số serial SOA và thời gian sửa đổi lần cuối để đảm bảo bạn đang xem phiên bản hiện tại của vùng. Xác nhận các bản ghi glue ở cha chính xác cho bất kỳ ủy quyền nào bạn kiểm soát.

Kiểm tra loại bản ghi và tên cụ thể mà bạn cần. Nhiều sự cố liên quan đến bản ghi A hoặc AAAA bị thiếu, chuỗi CNAME cũ hoặc bí danh dịch vụ hết hạn. Kiểm tra hành vi TTL và xem liệu thay đổi gần đây có giảm TTL cho việc di chuyển nhưng vẫn giữ mức thấp hay không. Nếu tên trỏ đến bộ cân bằng tải hoặc CDN, hãy xác minh điểm cuối đích khỏe mạnh và các kiểm tra sức khỏe dựa trên DNS không đánh dấu nó là hỏng.

Đừng quên phát hi���n dịch vụ và vùng nội bộ. Kubernetes CoreDNS, Consul và các hệ thống khác có thể che khuất hoặc mở rộng DNS chuẩn. Nếu chỉ một số pod hoặc nút bị lỗi, hãy xem nội dung resolv.conf theo từng nút, cài đặt ndots, miền tìm kiếm và xem dịch vụ DNS nội bộ có khỏe mạnh và được sao chép hay không.

Dùng quy trình khắc phục sự cố theo lớp

Một quy trình đơn giản, lặp lại được sẽ tiết kiệm thời gian.

• Tái tạo: Ghi lại chính xác tên, loại bản ghi, chủ máy khách và trình phân giải. Ghi lại dấu thời gian.
• Máy khách: Kiểm tra cài đặt bộ điều hợp, trạng thái VPN và firewall cục bộ. Xóa bộ nhớ đệm.
• Trình phân giải: Truy vấn trực tiếp trình phân giải đã cấu hình. So sánh với trình phân giải công khai và máy chủ chủ quyền.
• Upstream: Xác minh khả năng tiếp cận NS, nội dung vùng, chuỗi CNAME và trạng thái DNSSEC.
• Phụ thuộc: Xác thực bộ cân bằng tải, CDN, phát hiện dịch vụ và cấp phát chứng chỉ dựa vào DNS.
• Quan sát: Thêm hoặc rà soát nhật ký, chỉ số và dấu vết để sự cố tiếp theo được ch��n đoán nhanh hơn.

Khi tìm thấy chặng hỏng, hãy áp dụng thay đổi an toàn nhỏ nhất. Các ví dụ bao gồm sửa địa chỉ trình phân giải, mở lại cổng 53, sửa forwarder, sửa quy tắc split horizon, cập nhật bản ghi vùng hoặc khôi phục kiểm tra sức khỏe của dịch vụ phát hiện.

Ngăn sự cố lặp lại bằng quan sát và quy trình

Sau khi khôi phục, hãy củng cố môi trường. Giám sát DNS từ cả các điểm nhìn nội bộ và bên ngoài. Theo dõi tỷ lệ thành công, độ trễ và mã lỗi cho các tên phổ biến mà tổ chức bạn phụ thuộc. Cảnh báo khi TTL, giá trị bản ghi và tập NS của các vùng quan trọng thay đổi. Lưu các thay đổi DNS trong kiểm soát phiên bản và yêu cầu đánh giá đồng nghiệp. Lên lịch kiểm toán định kỳ resolv.conf trên các máy chủ và container và đưa kiểm tra DNS vào sổ tay xác thực thay đổi và triển khai.

Vấn đề DNS chỉ có vẻ bí ẩn khi bạn không thể nhìn thấy lộ trình. Bằng cách đi theo lộ trình từ máy khách đến trình phân giải và upstream, ghi lại những gì bạn quan sát ở mỗi bước và trang bị hệ thống để có khả năng hiển thị liên tục, bạn biến một sự cố mơ hồ thành một chuỗi có thể giải quyết. Đó là cách bạn thực hành cách khắc phục sự cố phân giải DNS trên các lớp máy khách và máy chủ một cách bình tĩnh, đáng tin cậy để giữ dịch vụ vận hành và người dùng làm việc hiệu quả.