DNS Negative Caching: vì sao thêm bản ghi rồi vẫn báo NXDOMAIN?

Bản ghi đã xuất hiện trong trang quản trị DNS, nhưng ứng dụng vẫn báo không tìm thấy hostname. Trước khi sửa lại cấu hình hoặc khởi động lại mọi dịch vụ, hãy kiểm tra khả năng resolver đang nhớ một câu trả lời phủ định trước đó. DNS có thể lưu cả kết quả “không tồn tại”, không chỉ địa chỉ IP.

Bài viết xây dựng một quy trình chẩn đoán cho quản trị viên và lập trình viên triển khai hostname mới. Tên miền, địa chỉ và kết quả bên dưới là minh họa; các lệnh chỉ đọc dữ liệu DNS, không thay đổi cấu hình production.

1. Phân biệt ba loại kết quả trước khi xử lý

RFC 2308 mô tả negative caching và cách dùng SOA để xác định thời gian lưu câu trả lời phủ định. TTL ban đầu liên quan đến giá trị nhỏ hơn giữa TTL của SOA và trường SOA MINIMUM; khi đọc từ cache, thời gian còn lại có thể đã giảm.

2. Dựng timeline thay vì nói chung là “chờ propagation”

Ví dụ một resolver nhận kết quả phủ định lúc 09:00, với thời gian lưu 600 giây. Đến 09:02, quản trị viên mới tạo bản ghi. Resolver đó có thể tiếp tục trả kết quả đã lưu cho tới khi entry hết hạn theo chính sách của nó. Đây là một ví dụ đơn giản, không phải cam kết mọi mạng sẽ cập nhật đúng 09:10.

Từ timeline này, nhóm vận hành nên ghi lại bốn mốc: lúc lần đầu truy vấn hostname, lúc tạo bản ghi, lúc authoritative server trả dữ liệu đúng và lúc resolver người dùng trả dữ liệu đúng. Những mốc cụ thể giúp phân biệt lỗi xuất bản zone với một cache cũ.

Việc hạ TTL của bản ghi A vừa tạo không phải bằng chứng cache phủ định đã được xóa. Tương tự, sửa TTL trên server không thu hồi ngay những entry đã nằm trong cache ở nơi khác. Hãy đo response thực tế thay vì liên tục thay đổi cấu hình trong lúc chờ.

3. So sánh authoritative server với resolver

Trên máy có BIND dig, dùng các truy vấn sau. Thay tên nameserver minh họa bằng máy authoritative của zone; nếu hostname thuộc một zone được ủy quyền riêng, dùng nameserver của zone đó:

dig example.com. NS
dig @ns1.example.com. api.example.com. A +norecurse
dig api.example.com. A
dig api.example.com. AAAA

Lệnh có @ chỉ định server cần hỏi; +norecurse yêu cầu không thực hiện đệ quy. Xem status, cờ aa khi server có thẩm quyền, ANSWER, AUTHORITY và dòng SERVER. Đừng chỉ dựa vào số lượng dòng trong answer: referral hoặc chuỗi CNAME có thể cần phân tích thêm. Tùy chọn được mô tả trong tài liệu dig của ISC BIND.

Thực hiện kiểm tra với từng authoritative server đang được delegation công bố. Nếu chúng trả kết quả khác nhau, cần xử lý sự không đồng nhất đó trước khi kết luận mọi resolver đều đang giữ cache cũ.

Nếu authoritative trả A đúng còn resolver trả NXDOMAIN, đã có một điểm khác biệt để điều tra. Nó chưa tự chứng minh nguyên nhân duy nhất là cache: còn phải kiểm tra split DNS, forwarder và đường phân giải mà ứng dụng sử dụng.

4. Đọc SOA trong phản hồi phủ định

Một đoạn AUTHORITY minh họa có thể trông như sau:

example.com. 420 IN SOA ns1.example.com. hostmaster.example.com. (
  2026101801 3600 600 1209600 600
)

Trong tình huống minh họa này, 420 là TTL đi kèm SOA trong response đang quan sát; 600 ở cuối là MINIMUM. Không lấy số serial 2026101801 để tính thời gian chờ. Đọc cả response và vị trí từng field, không suy đoán từ một con số chụp riêng trong dashboard.

Ghi lại cùng truy vấn sau một khoảng thời gian ngắn. TTL giảm là dấu hiệu hữu ích về cache đang được quan sát; số không giảm hoặc thay đổi bất thường cần xem thêm kiến trúc resolver, nhiều node và chính sách cache. Không tạo vòng lặp truy vấn dồn dập để “ép DNS cập nhật”.

5. SERVFAIL cần một nhánh điều tra khác

RFC 9520 đề cập việc cache các lỗi phân giải để hạn chế truy vấn lặp lại. Vì vậy, sửa lỗi phía server không đồng nghĩa mọi resolver sẽ thử lại tức thì. Tuy nhiên, không được diễn giải SERVFAIL thành “hostname chưa được tạo”.

Với SERVFAIL, hãy kiểm tra delegation có trỏ đúng không, nameserver có phản hồi không, các thay đổi DNSSEC gần đây và log của resolver thuộc quyền quản lý. Không tắt DNSSEC toàn hệ thống hoặc thay resolver doanh nghiệp chỉ để làm kết quả thử nghiệm biến mất.

6. Khi dig đúng nhưng ứng dụng vẫn lỗi

Lúc này cần tìm đúng nơi đang nhớ dữ liệu. Resolver của hệ điều hành, browser dùng DNS-over-HTTPS, runtime ứng dụng và container có thể đi qua các đường khác nhau. Kết quả dig từ laptop không đại diện cho kết quả của một worker chạy trên server khác.

• Chạy phép kiểm tra trong cùng host hoặc môi trường mạng với ứng dụng.
• Ghi rõ đang hỏi resolver nào, có VPN hay split DNS không.
• Kiểm tra ứng dụng có giữ connection pool hoặc cache DNS riêng hay không.
• Nếu cần xóa cache, chỉ xóa ở tầng đã xác định và thuộc quyền quản lý.
• Đo lại từ đường truy cập của người dùng sau thay đổi; không dùng một lần thử thành công làm bằng chứng toàn hệ thống đã phục hồi.

Xóa cache trên máy cá nhân không xóa cache ở recursive resolver của ISP. Khởi động lại ứng dụng cũng không đảm bảo thay đổi resolver bên ngoài. Một thao tác hữu ích phải khớp đúng tầng gây ra sự cố.

7. Checklist trước khi ra mắt hostname mới

1. Tạo record và kiểm tra trên mọi authoritative server trước khi công bố URL.
2. Kiểm tra đúng loại record mà client cần, bao gồm A và AAAA khi có liên quan.
3. Xác minh đích CNAME, delegation và các nhánh DNS nội bộ/công khai.
4. Quan sát từ môi trường ứng dụng và các mạng người dùng mục tiêu.
5. Lưu timestamp, status, server trả lời, SOA và TTL vào biên bản chẩn đoán.
6. Chỉ kiểm tra HTTPS sau khi phân giải đúng; DNS thành công chưa chứng minh certificate hoặc backend đã hoạt động.

Cách giảm sự cố hiệu quả là chuẩn bị DNS trước khi lưu lượng thật xuất hiện và giữ bằng chứng ở từng tầng. Khi gặp NXDOMAIN, bắt đầu bằng câu hỏi “server nào đang trả câu này?” sẽ giúp khoanh vùng nhanh hơn việc sửa đi sửa lại bản ghi.