DNS TTL: Vì sao đổi IP rồi vẫn có người vào máy chủ cũ?

Đổi địa chỉ IP trong trang quản trị DNS xong nhưng người dùng vẫn vào máy chủ cũ là tình huống phổ biến khi chuyển hosting. Nguyên nhân không nhất thiết là thao tác lưu thất bại: nhiều resolver có thể đang dùng câu trả lời đã cache. TTL giúp giải thích một phần quá trình đó, nhưng không phải đồng hồ đếm ngược cho toàn bộ Internet.

Bài viết giải thích TTL và đề xuất checklist cho việc đổi bản ghi địa chỉ của tên miền đang có. Đây không phải hướng dẫn đổi nameserver, không thay thế kế hoạch đồng bộ dữ liệu hay kiểm tra HTTPS.

1. TTL nói lên điều gì?

Tài liệu DNS của Cloudflare mô tả TTL là khoảng thời gian bản ghi được cache. Ví dụ, TTL 300 biểu thị 300 giây. TTL DNS không phải số hop của gói IP dù cùng tên viết tắt, và không quyết định thời gian cache HTML, ảnh hoặc API ở trình duyệt.

Một cách hình dung: authoritative server giữ câu trả lời do bên quản trị công bố; recursive resolver hỏi rồi giữ bản trả lời để phục vụ các truy vấn tiếp theo. Những resolver lấy dữ liệu ở thời điểm khác nhau có thể còn thời gian cache khác nhau.

2. Hạ TTL không thu hồi cache cũ

Ví dụ giả định: bản ghi có TTL 3.600 giây; một resolver lấy IP cũ lúc 09:00. Lúc 09:10, quản trị viên đổi TTL xuống 300 giây. Bản trả lời resolver đã giữ trước đó không nhận một thông báo buộc nó rút ngắn thời hạn xuống 5 phút. Theo mô hình cache thông thường, nó có thể tiếp tục dùng IP cũ đến gần 10:00.

Vì vậy, với kế hoạch chuyển có chuẩn bị, hạ TTL trước thời điểm đổi IP và dành khoảng đệm dựa trên TTL cũ. Không hứa rằng “đổi TTL về 300 thì mọi nơi cập nhật sau đúng 5 phút”. Cấu hình cache ở client, resolver và hạ tầng trung gian có thể khiến quan sát thực tế khác nhau.

3. Phân biệt ba nơi cần kiểm tra

Nhìn một website “DNS checker” báo xanh không chứng minh mọi người dùng đã chuyển. Khi điều tra, ghi thời điểm, tên truy vấn, loại bản ghi và resolver được hỏi. Cùng tên miền nhưng A và AAAA là hai loại dữ liệu phải kiểm tra riêng.

4. Đừng bỏ quên câu trả lời không tồn tại

RFC 2308 quy định negative caching cho các câu trả lời như tên không tồn tại hoặc không có loại bản ghi được hỏi, với thông tin thời hạn liên quan đến SOA. Vì vậy, tạo một tên mới sau khi nó từng được hỏi và trả lỗi không bảo đảm mọi resolver sẽ lập tức trả bản ghi mới.

Đây là lý do cần phân biệt sửa tên đã tồn tại với vừa tạo tên mới. Không lấy TTL của bản ghi A mới làm lời giải thích duy nhất cho một phản hồi NXDOMAIN còn cache. Nếu nameserver, delegation hoặc DNSSEC cũng thay đổi, cần phân tích riêng thay vì quy tất cả cho TTL A.

5. Checklist đổi địa chỉ có kiểm soát

1. Ghi giá trị hiện tại của A, AAAA hoặc chuỗi CNAME liên quan, TTL và người chịu trách nhiệm.
2. Kiểm tra máy chủ đích bằng tên miền đúng, chứng chỉ và dữ liệu trước khi chuyển.
3. Nếu được phép, hạ TTL từ trước và chờ khoảng đệm theo TTL cũ.
4. Chốt cách xử lý ghi dữ liệu trong giai đoạn người dùng có thể vào cả hai máy chủ.
5. Đổi bản ghi đã xác định, quan sát authoritative, resolver và log ứng dụng.
6. Giữ phương án rollback và tiêu chí ngừng phục vụ máy cũ dựa trên quan sát, không chỉ một bộ đếm.
7. Sau khi ổn định, xem lại TTL vận hành phù hợp và ghi hồ sơ thay đổi.

Nếu website nằm sau proxy/CDN, địa chỉ DNS công khai có thể là địa chỉ của proxy; đổi origin trong nền tảng đó là một lớp cấu hình khác. Cần xác định người dùng thực sự kết nối tới thành phần nào trước khi sửa bản ghi.

6. TTL ngắn không tự tạo failover

TTL ngắn có thể hỗ trợ quá trình nhận cập nhật nhanh hơn trong điều kiện phù hợp, nhưng không tự phát hiện máy hỏng, chọn máy dự phòng hay bảo đảm dữ liệu nhất quán. TTL dài có thể giảm số lần resolver cần hỏi lại; lựa chọn là cân bằng theo nhu cầu thay đổi và khả năng vận hành, không có một con số tốt nhất cho mọi tên miền.

Hãy coi chuyển DNS là một thay đổi dịch vụ có nhiều lớp. Hiểu cache giúp đặt kỳ vọng đúng, còn kiểm tra endpoint, dữ liệu và phương án quay lại mới giúp kiểm soát tác động với người dùng.