Hãy hình dung địa chỉ máy chủ của tên miền đã được đổi, nhưng ở nhà bạn mở được trang mới còn điện thoại vẫn nối tới máy chủ cũ. Dù hai thiết bị nhập cùng một tên, kết quả có thể tạm thời khác nhau nếu đi qua các bộ nhớ đệm DNS khác nhau. Bộ nhớ đệm HTTP phục vụ việc tải lại trang và bộ nhớ đệm DNS dùng để tìm địa chỉ kết nối có đối tượng cần kiểm tra khác nhau ngay từ đầu.
Bài viết dùng máy chủ thư viện giả định www.library.example để tìm hiểu quan hệ giữa phân giải tên và bộ nhớ đệm. Tên và bảng thời gian minh họa được tạo để giải thích, không phải kết quả đo phản hồi của dịch vụ thật. Mục tiêu là tách quá trình DNS cung cấp địa chỉ, nguyên nhân thay đổi có vẻ chậm và sự cố xảy ra sau khi phân giải tên.
1. DNS có nhiều loại câu trả lời cho một tên
DNS cung cấp thông tin gắn với tên miền dưới dạng các loại bản ghi. A biểu thị địa chỉ IPv4, AAAA biểu thị địa chỉ IPv6; một tên cũng có thể có nhiều địa chỉ. CNAME là bí danh trỏ tới tên khác, MX chỉ máy chủ nhận thư và NS chỉ máy chủ tên có thẩm quyền cho vùng đó. Vì vậy, ngay cả khi hỏi cùng một tên, câu trả lời vẫn có thể khác nếu loại bản ghi được yêu cầu khác nhau.
Như hướng dẫn bản ghi DNS của Cloudflare giải thích, giá trị CNAME là một tên khác, không phải địa chỉ IP. Nếu cần địa chỉ, việc phân giải tên đó có thể tiếp tục. Ngoài ra, trong https://www.library.example/books, tên máy chủ mà DNS xử lý là www.library.example. Đường dẫn /books hay nội dung trang không được đăng ký vào DNS. Thiết lập CNAME cũng không tự tạo chuyển hướng HTTP làm thay đổi thanh địa chỉ trình duyệt.
2. Bộ phân giải đệ quy tìm máy chủ có thẩm quyền ra sao
Chức năng phân giải tên trên thiết bị thường hỏi bộ phân giải đệ quy đã được cấu hình. Nếu thông tin cần thiết có trong bộ nhớ đệm, bộ phân giải dùng nó; nếu thiếu, nó truy vấn các máy chủ DNS khác rồi trả về câu trả lời cuối cùng hoặc lỗi. Tiêu chuẩn thuật ngữ DNS RFC 9499 phân biệt vai trò phân giải thay này với máy chủ có thẩm quyền nắm thông tin của vùng mình phụ trách. Cần đọc nguồn câu trả lời theo vai trò mà máy chủ đang thực hiện khi phản hồi.
Trong luồng đơn giản không có bộ nhớ đệm và bên chuyển tiếp trung gian, bộ phân giải nhận chỉ dẫn tới máy chủ tên miền cấp cao từ máy chủ gốc, rồi nhận chỉ dẫn tới máy chủ có thẩm quyền của vùng đích từ máy chủ đó. Máy chủ có thẩm quyền cuối cùng cung cấp bản ghi hoặc bí danh cần tìm. Không phải một máy chủ gốc lưu địa chỉ IP của mọi trang web. Thực tế có thể bắt đầu từ thông tin ủy quyền đã lưu hoặc chuyển tiếp sang bộ phân giải khác, nên không nhất thiết lặp lại toàn bộ chuỗi này trong mỗi lần truy cập.
3. TTL là thời gian đệm còn lại, không phải đồng hồ chung toàn cầu
TTL của bản ghi là thông tin thời gian sống của bộ nhớ đệm, được truyền theo giây. Trong phản hồi đệm thông thường, thời gian còn lại giảm theo thời gian dữ liệu đã được lưu. Ví dụ, nếu bộ phân giải lưu địa chỉ có TTL 300 giây đúng 10:00, khi trả lời bằng chính bản lưu đó lúc 10:02 thì TTL còn khoảng 180 giây. Bảng sau giả định chỉ có một bộ phân giải, không truy vấn lại, không làm mới sớm và không cung cấp phản hồi hết hạn.
| Thời điểm giả định | Địa chỉ trên máy chủ có thẩm quyền | Cách bộ phân giải này xử lý |
|---|---|---|
| 10:00 | Địa chỉ cũ | Lưu địa chỉ cũ với TTL 300 giây |
| 10:01 | Đổi sang địa chỉ mới | Bản lưu vẫn còn 240 giây |
| 10:03 | Địa chỉ mới | Có thể dùng lại địa chỉ cũ trong 120 giây còn lại |
| Truy vấn đầu tiên từ 10:05 | Địa chỉ mới | Giả định truy vấn lại để thay bản lưu hết hạn và lấy địa chỉ mới |
Bộ phân giải khác có thể lưu bản ghi này muộn hơn hoặc chưa từng thấy nó. Thời điểm cập nhật khác nhau nên một TTL không xác định được lúc mọi người dùng trên thế giới đồng loạt chuyển đổi. Bộ nhớ đệm cũng có thể bỏ dữ liệu trước khi hết hạn; tải lại trang web không xóa luôn bản lưu ở bộ phân giải dùng chung. TTL là manh mối để hiểu việc dùng lại phản hồi DNS, không phải giới hạn thời gian cho toàn bộ kết nối web hay cập nhật màn hình.
4. Khi nào nên giảm TTL và bộ nhớ đệm cho câu trả lời “không có”
Bộ nhớ đệm từng nhận địa chỉ cũ với TTL 3600 giây không lập tức được báo khi người vận hành bây giờ giảm TTL xuống 60 giây. Nếu đã lên kế hoạch đổi địa chỉ, cần điều chỉnh TTL trước và tính đến thời gian các phản hồi lưu theo thời hạn cũ dài hơn vẫn còn tồn tại. TTL thấp có thể khiến thay đổi được kiểm tra thường xuyên hơn, nhưng cũng tăng tải truy vấn và sự phụ thuộc vào máy chủ có thẩm quyền. Thay vì áp cùng một con số ngắn cho mọi dịch vụ, hãy cân nhắc cả kế hoạch thay đổi và xử lý sự cố.
NXDOMAIN cho biết tên không tồn tại, hoặc NODATA khi tên có nhưng không có loại bản ghi được yêu cầu, cũng có thể được lưu đệm. Tiêu chuẩn bộ nhớ đệm phủ định RFC 2308 quy định dùng giá trị nhỏ hơn giữa TTL của bản ghi SOA từ máy chủ có thẩm quyền và giá trị MINIMUM trong SOA làm thời gian đệm cho phản hồi phủ định. Vì vậy, ngay sau khi thêm máy chủ vốn chưa tồn tại, câu trả lời cũ “không có” vẫn có thể còn được lưu. Chỉ nhìn TTL của bản ghi A mới rồi cho rằng thời hạn câu trả lời kia cũng bằng vậy sẽ khiến bạn bỏ sót nguyên nhân.
5. Kiểm tra với cùng tên, loại và máy chủ
Trong nhật ký kiểm tra, hãy ghi cùng nhau tên chính xác đã hỏi, loại như A hoặc AAAA, máy chủ DNS được hỏi và thời điểm. Nếu môi trường có cài dig, có thể chỉ rõ tên và loại bằng dig example.com A. Khi điều tra vấn đề thật, thay example.com bằng máy chủ mình cần kiểm tra. Lệnh này là ví dụ thao tác, không phải nhật ký cho thấy bài viết đã thực sự chạy lệnh hay đo thời gian phản hồi.
Xem trạng thái phản hồi cùng tên, loại, giá trị và TTL trong ANSWER. Khi gửi lại cùng truy vấn tới cùng bộ phân giải, hãy xem TTL có giảm không, nhưng đừng kết luận có lỗi chỉ vì giá trị tăng. Dữ liệu có thể đã được làm mới trước hoặc một nút khác trong nhiều nút đệm đã phản hồi. Ghi riêng kết quả A và AAAA thay vì trộn chúng sẽ giúp xác định nhóm địa chỉ nào có khác biệt.
Người vận hành có thể so sánh câu trả lời của bộ phân giải đệ quy đang dùng với máy chủ có thẩm quyền của vùng mình quản lý cho cùng tên và loại. Nếu khác, kiểm tra lần lượt thời gian đệm còn lại, tính thống nhất dữ liệu giữa các máy chủ có thẩm quyền và cấu hình ủy quyền. Không khái quát câu trả lời từ một bộ phân giải công cộng thành trạng thái của mọi người dùng. DNS nội bộ công ty hoặc cấu hình DNS riêng của trình duyệt có thể đổi đường truy vấn, nên cũng cần ghi môi trường kết nối khi so sánh.
6. Tách lỗi DNS, lỗi kết nối và các ngoại lệ
NXDOMAIN là phản hồi tên không tồn tại, còn NODATA là trường hợp không có loại bản ghi được yêu cầu. Ngược lại, SERVFAIL là việc máy chủ không xử lý được truy vấn; hết thời gian chờ là quan sát rằng chưa nhận được câu trả lời trong khoảng chờ quy định. Không được hiểu tất cả thành “tên miền đã bị xóa”. Cần giữ thông tin có mã phản hồi hay không và đã hỏi máy chủ nào trước khi chọn đối tượng kiểm tra tiếp theo.
Vẫn nhìn thấy câu trả lời cũ sau TTL không phải lúc nào cũng vi phạm quy tắc. Cơ chế serve-stale trong RFC 8767 quy định cách dùng thông tin hết hạn để tăng khả dụng trong tình huống ngoại lệ không thể làm mới từ máy chủ có thẩm quyền. Điều đó không có nghĩa mọi bộ phân giải đều dùng cùng cấu hình. Vì vậy, thay vì chốt thời gian áp dụng thay đổi từ một giá trị TTL, hãy kiểm tra hoạt động của bộ phân giải thực sự được sử dụng.
Cuối cùng, tìm được địa chỉ bình thường không bảo đảm kết nối trang web thành công. Mạng tới địa chỉ đó, chứng chỉ TLS, máy chủ web và ứng dụng là các giai đoạn riêng. Nếu DNS trả đúng địa chỉ mong đợi mà trang không mở, hãy chuyển phạm vi điều tra sang giai đoạn kết nối tiếp theo. Ghi riêng câu trả lời phân giải tên và phản hồi web giúp khoanh vùng thất bại chính xác hơn trước khi xóa bộ nhớ đệm trang hoặc thay đổi DNS một cách tùy tiện.