Lan truyền DNS là gì và cách giảm thiểu tác động

Lan truyền DNS (DNS propagation) là khoảng thời gian một số resolver vẫn tiếp tục trả về giá trị cũ của một bản ghi sau khi bạn đã thay đổi nó trên máy chủ tên miền có thẩm quyền. Thực ra không có gì được phát tán trên Internet: mỗi resolver giữ câu trả lời trong bộ nhớ đệm cho đến khi TTL hết hạn. Độ trễ dao động từ vài phút đến 24 hoặc 48 giờ khi đổi máy chủ tên miền, tùy thuộc vào TTL của bản ghi trước khi thay đổi và, với máy chủ tên miền, vào TTL ủy quyền do cơ quan đăng ký (registry) đặt. Dưới đây là cách nó hoạt động và cách giảm thiểu tác động.

Điểm chính

• Thay đổi của bạn hiển thị ngay lập tức trên máy chủ có thẩm quyền. Độ trễ chỉ đến từ bộ nhớ đệm của các resolver, vốn giữ giá trị cũ cho đến khi TTL của nó hết hạn.
• Giá trị cũ tồn tại bao lâu do TTL có hiệu lực trước khi thay đổi quyết định, không phải TTL bạn vừa nhập. Hãy hạ TTL từ sớm.
• Đổi máy chủ tên miền là chậm nhất, vì nó phụ thuộc vào TTL ủy quyền của registry mà bạn không kiểm soát được.
• Lỗi “tên này không tồn tại” cũng bị lưu vào bộ nhớ đệm: truy cập một tên trước khi tạo bản ghi có thể kéo dài lỗi.

Lan truyền DNS không phải là phát tán

Thuật ngữ này dễ gây hiểu lầm. Không máy chủ nào gửi thay đổi của bạn cho các máy chủ khác. Khi bạn lưu thay đổi tại nhà cung cấp DNS, máy chủ tên miền có thẩm quyền của vùng (zone) trả ngay giá trị mới. Độ trễ nằm ở chỗ khác, trong các bộ nhớ đệm.

Khi một thiết bị tra cứu địa chỉ của tên miền, yêu cầu đi qua nhiều tầng, và mỗi tầng đều có thể ghi nhớ câu trả lời:

• trình duyệt, có bộ nhớ đệm thường kéo dài khoảng một phút và không phải lúc nào cũng tuân theo TTL;
• hệ điều hành, lưu các câu trả lời gần đây;
• resolver đệ quy của nhà cung cấp Internet hoặc của một dịch vụ công cộng (ví dụ 8.8.8.8 của Google, 1.1.1.1 của Cloudflare), duyệt qua hệ thống phân cấp DNS rồi lưu kết quả.

Mỗi resolver áp dụng TTL mà máy chủ có thẩm quyền đưa cho nó vào lúc nó lưu câu trả lời. Vì không phải tất cả cùng hỏi một lúc, bản sao của chúng hết hạn ở những thời điểm khác nhau. Một bản ghi có TTL 3.600 giây được lưu cách đây 5 phút sẽ được làm mới sau 55 phút. Vì thế mới có những phản hồi mâu thuẫn: người này thấy trang mới, người kia thấy trang cũ, người thứ ba gặp lỗi.

Lan truyền DNS mất bao lâu

Thời gian phụ thuộc vào loại thay đổi. TTL một ngày (86.400 giây) là phổ biến, và các bản ghi hiếm khi đổi như máy chủ tên miền thường có giá trị cao hơn.

Ba yếu tố quyết định độ trễ

TTL trước khi thay đổi

Giả sử một bản ghi có TTL 86.400 giây và hôm nay bạn đặt thành 300. Resolver đã lưu nó từ hôm qua sẽ giữ giá trị cũ tới 24 giờ, bất kể giá trị mới là gì: TTL 300 giây chỉ áp dụng sau khi bản sao của nó được làm mới. Với CNAME, mỗi tên trong chuỗi có TTL riêng, và TTL dài nhất quyết định tổng độ trễ.

Ủy quyền tại registry

Khi đổi máy chủ tên miền, thay đổi được thực hiện tại nhà đăng ký, rồi chuyển tới registry của tên miền cấp cao nhất. Những resolver vẫn biết danh sách máy chủ tên miền cũ sẽ tiếp tục truy vấn chúng cho đến khi ủy quyền hết hạn. TTL này thuộc về registry: bạn không thể rút ngắn nó.

Resolver không tuân thủ TTL từng chữ

Một số resolver đặt trần hoặc nâng TTL, và trình duyệt có bộ nhớ đệm riêng tồn tại ngắn. Vì vậy không thể đảm bảo cùng một thời gian ở mọi nơi. TTL là giới hạn trên về mặt lý thuyết, không phải lời hứa của mọi bộ nhớ đệm.

Cái bẫy của bộ nhớ đệm phủ định

Hầu hết hướng dẫn chỉ nói về TTL của bản ghi và quên các câu trả lời phủ định. Khi một resolver biết rằng một tên không tồn tại (phản hồi NXDOMAIN) hoặc không có bản ghi loại được yêu cầu, nó có thể ghi nhớ sự vắng mặt đó. RFC 2308 quy định thời gian của bộ nhớ đệm phủ định là giá trị nhỏ hơn trong hai giá trị: TTL của SOA thuộc vùng và trường MINIMUM của nó. RFC cho rằng từ một đến ba giờ là hợp lý và cảnh báo rằng giá trị vượt quá một ngày gây ra vấn đề.

Kịch bản điển hình: bạn thử moi.example.com trước khi tạo bản ghi, gặp lỗi, rồi mới tạo bản ghi. Với resolver của bạn, tên đó “không tồn tại” cho đến khi bộ nhớ đệm phủ định kết thúc, dù bản ghi đã hoạt động được một phút. Cách tránh:

• tạo bản ghi trước khi thử hoặc công bố tên;
• nếu nhà cung cấp DNS cho phép chỉnh SOA, hãy giữ trường MINIMUM ở mức vừa phải;
• xóa bộ nhớ đệm cục bộ trước khi kết luận rằng “không chạy”: Microsoft nêu rằng ipconfig /flushdns cũng loại bỏ các mục đệm phủ định.

Phương pháp giảm thiểu tác động của việc di chuyển

1. Ghi lại TTL hiện tại của từng bản ghi liên quan (xem các lệnh bên dưới). Chính nó quyết định độ trễ.
2. Hạ TTL xuống 300 giây, sớm ít nhất bằng thời gian của TTL cũ. Với 86.400 giây, hãy làm 24 đến 48 giờ trước khi chuyển. Kiểm tra mức tối thiểu mà nhà cung cấp chấp nhận.
3. Chuẩn bị đích mới: website, máy chủ thư hoặc CDN sẵn sàng trả lời với nội dung giống bản cũ. Cả hai phải hoạt động trong giai đoạn chuyển tiếp.
4. Chuyển bản ghi, mỗi lần một thay đổi để biết cần kiểm tra gì.
5. Kiểm tra máy chủ có thẩm quyền trước, rồi đến các resolver công cộng.
6. Giữ máy chủ cũ hoạt động ít nhất cho đến khi TTL cũ dài nhất trôi qua, rồi mới tắt.
7. Nâng TTL trở lại (3.600 giây trở lên) khi mọi thứ đã ổn định.

Với việc đổi máy chủ tên miền, trước hết hãy tạo lại toàn bộ vùng tại nhà cung cấp mới (A, CNAME, MX, TXT gồm cả SPF và DKIM, và mọi thứ còn lại), kiểm tra nó trả lời đúng, rồi mới đổi máy chủ tên miền tại nhà đăng ký. Hãy để vùng ở nhà cung cấp cũ hoạt động và giữ nguyên nội dung trong 48 giờ: những resolver vẫn biết ủy quyền cũ sẽ tiếp tục truy vấn nó.

Kiểm tra mỗi resolver đang thấy gì

Lệnh dig (macOS, Linux) hoặc nslookup (Windows) cho phép so sánh câu trả lời của máy chủ có thẩm quyền và của nhiều resolver công cộng.

# Giá trị và TTL còn lại mà các resolver công cộng thấy
dig +noall +answer example.com A @8.8.8.8
dig +noall +answer example.com A @1.1.1.1

# Các máy chủ tên miền được khai báo cho tên miền
dig +short NS example.com

# Giá trị do máy chủ có thẩm quyền trả về (thay bằng máy chủ tên miền của bạn)
dig +noall +answer example.com A @ns1.nha-cung-cap-dns.example

# Số serial của SOA, để so sánh giữa các máy chủ tên miền
dig +short SOA example.com @ns1.nha-cung-cap-dns.example
dig +short SOA example.com @ns2.nha-cung-cap-dns.example

# Lệnh tương đương trên Windows
nslookup -type=A example.com 8.8.8.8
nslookup -type=NS example.com

Trong câu trả lời của resolver, TTL hiển thị giảm dần sau mỗi truy vấn: đó là thời gian còn lại trước khi bản sao của nó hết hạn. Nếu một resolver trả giá trị cũ với TTL đang đếm ngược trong khi máy chủ có thẩm quyền đã trả giá trị mới, bạn chỉ cần chờ.

Hãy so sánh cả số serial của SOA giữa các máy chủ tên miền của bạn. Nếu khác nhau, có một máy chủ đang phục vụ dữ liệu lỗi thời: vấn đề nằm ở nhà cung cấp DNS, không phải ở việc lan truyền. Trang dns.google cho phép truy vấn một loại bản ghi cụ thể, kể cả SOA, và hướng dẫn khắc phục sự cố của Google Public DNS mô tả cách kiểm tra này.

Xóa các bộ nhớ đệm bạn kiểm soát được

Xóa bộ nhớ đệm của chính bạn không thay đổi gì với những người truy cập khác, nhưng giúp bạn biết mình thực sự đang thấy gì.

# Windows (dấu nhắc lệnh)
ipconfig /flushdns

# macOS gần đây
sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder

# Linux dùng systemd-resolved
resolvectl flush-caches

Microsoft mô tả /flushdns và /displaydns trên trang về lệnh ipconfig (bản tiếng Anh). Sau đó hãy đóng hẳn trình duyệt, vì nó có bộ nhớ ngắn hạn riêng.

Hai resolver công cộng cũng cung cấp chức năng xóa, hữu ích sau khi đổi máy chủ tên miền hoặc cho người dùng các dịch vụ đó: công cụ Flush Cache của Google Public DNS (Google khuyên xóa cả tên miền đã đăng ký lẫn tên chính xác đang trả về câu trả lời lỗi thời) và công cụ xóa bộ nhớ đệm 1.1.1.1 của Cloudflare, nơi bạn chọn tên miền và loại bản ghi. Resolver của các nhà cung cấp Internet không thể xóa: bạn phải chờ bản sao của chúng hết hạn.

Những lỗi thường gặp

• Hạ TTL ngay lúc chuyển. Đã muộn: các resolver giữ bản sao được tạo với TTL cũ.
• Thử tên trước khi tạo bản ghi. Bộ nhớ đệm phủ định có thể kéo dài lỗi.
• Đổi máy chủ tên miền trước khi tạo lại toàn bộ vùng. Các bản ghi thư hoặc tên miền phụ bị bỏ sót sẽ ngừng hoạt động với những resolver đã truy vấn nhà cung cấp mới.
• Tắt máy chủ cũ quá sớm. Khách truy cập có bộ nhớ đệm chưa hết hạn sẽ đến một máy chủ không còn trả lời.
• Kết luận việc lan truyền đã xong chỉ từ máy tính của bạn. Bộ nhớ đệm cục bộ không đại diện cho các resolver khác.
• Để TTL rất thấp vĩnh viễn. Điều này làm tăng số truy vấn tới máy chủ tên miền của bạn. Hãy nâng lại sau khi di chuyển xong.

Câu hỏi thường gặp

Lan truyền DNS mất bao lâu?

Khi sửa một bản ghi, tối đa bằng TTL cũ: một giờ với TTL 3.600 giây, 24 giờ với 86.400 giây. Khi đổi máy chủ tên miền, từ vài giờ đến 48 giờ. Hầu hết resolver cập nhật sớm hơn nhiều so với thời hạn tối đa. Phần còn lại chỉ là một vài bộ nhớ đệm chậm trễ.

Có thể đẩy nhanh việc lan truyền DNS không?

Không thể trên toàn Internet: bạn không thể ép bộ nhớ đệm của người khác. Bạn có thể hạ TTL trước khi thay đổi, xóa các resolver công cộng của Google và Cloudflare, và xóa bộ nhớ đệm của chính mình. Resolver của các nhà cung cấp Internet không thể xóa.

Nên chọn TTL nào trước khi di chuyển?

Một giá trị ngắn như 300 giây (5 phút), áp dụng ít nhất trong thời gian của TTL cũ trước khi chuyển. Khi việc di chuyển đã ổn định, hãy nâng lại lên 3.600 giây trở lên: TTL rất thấp kéo dài sẽ nhân số truy vấn lên. Hãy kiểm tra mức tối thiểu mà nhà cung cấp DNS của bạn chấp nhận.

Vì sao đồng nghiệp của tôi thấy trang mới còn tôi thì không?

Hai bạn đi qua các resolver khác nhau, và chúng lưu câu trả lời ở những thời điểm khác nhau. Hãy truy vấn cùng một resolver công cộng từ cả hai máy để so sánh, rồi xóa bộ nhớ đệm cục bộ trên máy vẫn thấy phiên bản cũ.

Thư điện tử của tôi sẽ ra sao trong lúc lan truyền?

Thay đổi bản ghi MX tuân theo cùng quy tắc: trong thời gian trễ, một số người gửi vẫn viết tới máy chủ thư cũ. Hãy giữ nó hoạt động cho đến khi quá trình chuyển tiếp kết thúc. Nếu một máy chủ không khả dụng, các máy chủ gửi thường giữ lại thư và thử lại trong vài ngày.

Có cần xóa bộ nhớ đệm của máy tính không?

Có, để kiểm tra những gì bạn thấy, nhưng điều đó không thay đổi gì với những người truy cập khác. Hãy dùng lệnh của hệ thống bạn rồi đóng hẳn trình duyệt. Nếu giá trị vẫn cũ, bản sao đang nằm ở resolver của nhà cung cấp Internet của bạn.

Vì sao các công cụ kiểm tra lan truyền trực tuyến cho kết quả khác nhau?

Mỗi công cụ truy vấn các resolver ở những quốc gia khác nhau, và chúng lưu câu trả lời ở những thời điểm khác nhau. Kết quả lẫn lộn là bình thường cho đến khi TTL hết hạn ở mọi nơi. Nếu chính các máy chủ tên miền có thẩm quyền trả lời khác nhau, hãy so sánh số serial của SOA của chúng: khi đó vấn đề nằm ở vùng, không phải ở việc lan truyền.