Kiểm tra DNS bằng dig và nslookup: Đọc chuẩn bản ghi, hiểu đúng TTL để khỏi bấm F5 trong vô vọng

Phạm vi thực hành: Môi trường Ubuntu 24.04 LTS trên VPS độc lập; tên miền lab sử dụng là lab-cf02.localhost.vn. Bạn chỉ nên thực hiện truy vấn và thay đổi cấu hình trên các tài sản thuộc quyền quản lý của mình. Toàn bộ dữ liệu đo đạc DNS dưới đây được ghi nhận trực tiếp trên máy chủ LAB-CF-02 vào ngày 30/09 và đợt theo dõi TTL ngày 01/10/2026; phần lệnh trên Windows là hướng dẫn tham khảo tương đương.

Có một nghi thức tâm linh mà hầu như anh em kỹ thuật nào mới vào nghề cũng từng trải qua: vừa lưu bản ghi DNS trên bảng điều khiển xong là lập tức quay sang Chrome bấm F5 liên hoàn 50 lần trong 10 giây, rồi tự hỏi sao web vẫn chưa lên. Thực tế, trình duyệt là nơi tệ nhất để chẩn đoán DNS vì nó bị che mờ bởi đủ tầng bộ nhớ đệm. Thay vì đoán mò, việc kiểm tra DNS bằng dig (hoặc nslookup) sẽ chỉ thẳng cho bạn biết máy tính đang nhận câu trả lời nào, từ máy chủ phân giải (Resolver) nào và còn bao nhiêu giây bộ nhớ đệm (TTL). Nhờ đó, khi vừa trỏ subdomain về VPS, bạn có số liệu rõ ràng để đối chiếu thay vì ngồi nhìn màn hình trắng trong bất lực. Tất nhiên, hãy nhớ một nguyên tắc vàng: một lần truy vấn đơn lẻ chỉ phản ánh góc nhìn tại một điểm mạng và một thời điểm nhất định.

Chuẩn bị công cụ và xác định đúng tên miền cần hỏi

Trên hệ điều hành Ubuntu, bộ đôi công cụ dig và nslookup nằm sẵn trong gói dnsutils. Bạn có thể cài đặt nhanh gọn bằng lệnh sau:

sudo apt update &&
  sudo apt install dnsutils

Mẹo nhỏ cho thói quen vận hành an toàn: nếu bước cập nhật danh mục gói (apt update) chẳng may báo lỗi mạng hay sai kho chứa, hãy dừng lại xử lý dứt điểm trước khi cài. Toán tử && ở trên chính là chiếc phanh an toàn giúp ngăn lệnh cài đặt chạy bừa khi bước cập nhật trước đó trả về mã lỗi khác 0.

Nếu bạn dùng macOS, thường dig đã có sẵn trong Terminal. Trên Windows, công cụ nslookup luôn túc trực sẵn trong PowerShell hoặc Command Prompt. Điểm hay của việc kiểm tra DNS công khai là bạn có thể gõ lệnh ngay trên chiếc laptop cá nhân mà chẳng cần SSH vào VPS — thậm chí cách này còn phản ánh sát sườn hơn đường truyền mạng thực tế mà người dùng của bạn đang đi qua.

Trước khi gõ lệnh, hãy ghi chép rõ tên miền đầy đủ (FQDN) cần truy vấn, ví dụ lab-cf02.localhost.vn, kèm theo địa chỉ IP của máy chủ gốc (origin IP) mà bạn dự định trỏ tới. Lưu ý đừng lỡ tay dán (paste) cả cụm https:// hay đuôi /wp-admin vào lệnh dig nhé, vì hệ thống phân giải tên miền chỉ làm việc với tên máy chủ thuần túy chứ không hiểu giao thức HTTP hay đường dẫn thư mục. Ở phần cuối bài viết, chúng tôi có đính kèm kết quả thực nghiệm của bản ghi A trên hệ thống lab để bạn tiện so sánh. Khi áp dụng cho tên miền riêng, bạn nhớ đối chiếu với IP thực tế của mình rồi mới chuyển sang bước kiểm tra giao thức HTTP/HTTPS.

Sơ đồ khái quát do đội ngũ localhost.vn biên soạn nhằm minh họa cấu trúc một bản tin phản hồi DNS.

Bước 1: Đọc toàn bộ bản tin phản hồi trước khi dùng cờ rút gọn

dig lab-cf02.localhost.vn A

Khi mới chạy dig không kèm tham số phụ, màn hình sẽ đổ ra khá nhiều chữ, nhưng đừng vội hoa mắt. Hãy tập trung vào ba điểm cốt lõi: trạng thái status ở phần HEADER, vùng ANSWER SECTION và dòng SERVER ở gần cuối. Trong vùng ANSWER SECTION, các cột lần lượt hiển thị: tên miền được hỏi, thông số TTL (tính bằng giây), lớp mạng IN (Internet), loại bản ghi (như A, AAAA, CNAME) và cuối cùng là giá trị đích. Nếu bạn hỏi một Recursive Resolver thông thường, con số TTL hiển thị chính là thời gian sống còn lại của bản ghi trong bộ nhớ đệm (cache), nên mỗi lần bạn gõ lại lệnh sau vài giây, con số này sẽ đếm ngược giảm dần. Ngược lại, nếu bạn hỏi trực tiếp máy chủ tên miền có thẩm quyền gốc (Authoritative Nameserver), TTL sẽ luôn đứng im ở mức giá trị cấu hình gốc của bản ghi đó.

Để dễ hình dung bằng một tình huống minh họa: giả sử bạn nhận về một dòng kết quả mang TTL 120, loại bản ghi A và địa chỉ IP khớp hoàn toàn với IP của VPS. Điều này khẳng định rằng Resolver mà bạn vừa hỏi đang trả về đúng địa chỉ IPv4 mong muốn, và nó sẽ còn giữ câu trả lời này trong bộ nhớ đệm thêm 2 phút nữa. Tuy nhiên, kết quả đẹp đẽ này mới chỉ hoàn thành nhiệm vụ của phần danh bạ mạng — nó hoàn toàn chưa nói lên được việc NGINX trên VPS đã bật chưa, cổng 80/443 đã mở trên tường lửa chưa hay chứng chỉ SSL/TLS có hợp lệ hay không.

Một chi tiết cực kỳ quan trọng mà nhiều bạn hay cắt bỏ khi chụp ảnh màn hình gửi nhờ hỗ trợ là dòng SERVER ở cuối kết quả. Dòng này chỉ rõ danh tính của Resolver đã trả lời truy vấn của bạn, kèm theo dấu thời gian chính xác. Nếu cắt mất thông tin nguồn trả lời, hai kết quả khác nhau từ hai máy chủ phân giải khác nhau rất dễ bị chẩn đoán nhầm thành lỗi hệ thống DNS nhảy IP lung tung.

Bước 2: Rút gọn output thông minh theo từng mục đích sử dụng

dig lab-cf02.localhost.vn A +short
dig lab-cf02.localhost.vn A +noall +answer
dig lab-cf02.localhost.vn AAAA +noall +answer
dig lab-cf02.localhost.vn CNAME +noall +answer

Khi đã quen mặt cấu trúc bản tin hoặc cần nhúng kết quả vào script tự động, cờ +short là trợ thủ đắc lực vì nó lược bỏ mọi râu ria và chỉ in ra đúng giá trị đích cuối cùng. Tuy nhiên, nếu bạn đang lập biên bản theo dõi quá trình chuyển đổi hạ tầng (migration log), tổ hợp cờ +noall +answer lại đáng giá hơn nhiều vì nó vừa gọn gàng, vừa giữ lại được cột TTL và loại bản ghi rõ ràng. Một lưu ý nhỏ: khi truy vấn bản ghi AAAA (IPv6) mà thấy kết quả trả về trống trơn thì cũng đừng vội hoảng hốt báo động đỏ. Rất nhiều máy chủ VPS chỉ cấu hình chạy thuần IPv4 nên việc không có bản ghi AAAA là hoàn toàn bình thường, miễn là nó khớp với thiết kế hạ tầng ban đầu của bạn.

Trong trường hợp kết quả trả về một bản ghi bí danh CNAME, công việc của bạn chưa dừng lại ở đó đâu nhé. Bạn cần kiểm tra nối tiếp xem cái tên miền đích mà CNAME trỏ tới có phân giải ra được địa chỉ IP hợp lệ hay không. Rất nhiều vụ sập web éo le xảy ra vì bản ghi CNAME viết hoàn toàn đúng cú pháp, nhưng lại trỏ sang một tên miền đích đã hết hạn hoặc bị cấu hình sai. Ngoài ra, nếu bạn sử dụng các dịch vụ quản lý DNS hiện đại có tính năng CNAME Flattening hoặc bật đám mây cam (Proxy) trên Cloudflare, máy chủ DNS sẽ tự động biên dịch và trả về thẳng bản ghi A hoặc AAAA cho người dùng cuối; lúc này bạn cần mở song song bảng điều khiển quản trị để nắm rõ cấu hình gốc.

Bước 3: Đối chiếu giữa Resolver mặc định, Public Resolver và Authoritative NS

dig @1.1.1.1 lab-cf02.localhost.vn A +noall +answer
dig @8.8.8.8 lab-cf02.localhost.vn A +noall +answer
dig NS localhost.vn +short

Việc hỏi thêm hai đại gia phân giải công cộng là Cloudflare (1.1.1.1) và Google (8.8.8.8) giúp bạn có thêm góc nhìn khách quan ngoài nhà mạng ISP đang dùng, dù chúng cũng không thể đại diện cho 100% thiết bị người dùng trên toàn thế giới. Nếu thấy một Resolver vẫn ngoan cố trả về địa chỉ IP của máy chủ cũ, hãy bình tĩnh liếc nhìn cột TTL xem còn bao nhiêu giây và pha một ly cà phê ngồi đợi hết khoảng thời gian đó rồi truy vấn lại. Tuyệt đối tránh kiểu tâm lý sốt ruột: vừa đổi sang IP mới được 2 phút thấy chưa nhận lại lật đật sửa ngược về IP cũ, rồi lại đổi sang IP mới — làm vậy chỉ biến bộ nhớ đệm của các Resolver thành một nồi lẩu thập cẩm cực kỳ khó gỡ lỗi.

Để biết chắc chắn 100% rằng thao tác lưu cấu hình trên bảng điều khiển DNS của bạn đã thực sự có hiệu lực tại gốc hay chưa, hãy lấy một tên máy chủ từ kết quả truy vấn NS ở lệnh cuối (ví dụ penny.ns.cloudflare.com), sau đó gõ lệnh hỏi trực tiếp nó: dig @TEN-NS lab-cf02.localhost.vn A. Câu trả lời từ chính Authoritative Nameserver là lời khẳng định đanh thép nhất về dữ liệu trong Zone của bạn; nếu tại gốc đã đúng mà các Public Resolver vẫn bơ vơ tìm sai chỗ, lúc đó chúng ta mới cần đào sâu lên tầng ủy quyền tên miền (delegation) tại nhà đăng ký (Registrar).

Sơ đồ hướng dẫn do đội ngũ localhost.vn biên soạn giúp hình dung phương pháp đối chiếu chéo ba nguồn DNS cùng thời điểm.

Bước 4: Thao tác tương đương bằng nslookup trên Windows

nslookup -type=A lab-cf02.localhost.vn
nslookup -type=AAAA lab-cf02.localhost.vn
nslookup -type=NS localhost.vn
nslookup lab-cf02.localhost.vn 1.1.1.1

Khi chạy nslookup, rất nhiều người mới giật mình thon thót khi thấy dòng chữ Non-authoritative answer (Câu trả lời không có thẩm quyền gốc) hiện ra ngay đầu kết quả. Đừng lo, thông báo này không hề có nghĩa là bản ghi DNS của bạn bị sai hay hàng giả mạo đâu! Nó chỉ đơn giản giải thích một sự thật kỹ thuật: bạn đang nhận câu trả lời gián tiếp thông qua bộ nhớ đệm của một máy chủ trung gian (như 1.1.1.1 hoặc DNS của nhà mạng), chứ không phải gõ cửa hỏi trực tiếp máy chủ Nameserver gốc. Việc bạn cần làm vẫn là đọc kỹ tên miền, địa chỉ IP trả về và danh tính máy chủ đã phản hồi.

Nếu bạn muốn soi kỹ thông số TTL ngay trên Windows, bạn có thể thêm cờ -debug vào lệnh nslookup, hoặc sử dụng dig trong môi trường WSL / máy ảo Linux. Không cần thiết phải cài đặt hàng tá phần mềm thứ ba lên máy tính chỉ để có giao diện chụp ảnh màn hình giống hệt bài hướng dẫn; mục tiêu tối thượng của người làm kỹ thuật là nắm được chính xác nguồn trả lời và giá trị đích trả về.

Bảng bắt bệnh DNS nhanh qua các mã trạng thái

Kinh nghiệm xương máu khi đụng độ mã lỗi SERVFAIL là tuyệt đối đừng hoảng loạn xóa bừa các bản ghi A hay CNAME trong bảng điều khiển. Thủ phạm phổ biến nhất của SERVFAIL sau khi chuyển đổi nhà cung cấp DNS thường nằm ở việc bạn quên tắt hoặc chưa cập nhật bản ghi DS của cơ chế bảo mật DNSSEC tại nhà đăng ký tên miền (Registrar). Còn nếu gặp lỗi Timeout, hãy thử đổi sang hỏi một Public Resolver khác ngay lập tức để phân biệt xem do mạng máy bạn đang chặn cổng 53 hay do máy chủ DNS kia thực sự ngưng phản hồi.

TTL không phải là nút bấm “Làm mới toàn bộ Internet”

Một hiểu lầm kinh điển khác là: để nguyên TTL ở mức 24 giờ (86400 giây), đến lúc đổi IP máy chủ xong thấy web chưa cập nhật mới cuống cuồng vào bảng điều khiển hạ TTL xuống 60 giây với hy vọng các máy chủ khắp thế giới sẽ nhận IP mới ngay lập tức. Rất tiếc, cơ chế cache không vận hành như vậy! Các Resolver đã trót lưu bản ghi của bạn trước thời điểm đổi IP sẽ vẫn ôm khư khư con số 86400 giây cũ cho đến khi đồng hồ đếm ngược về 0, bất chấp việc bạn vừa chỉnh TTL mới thành bao nhiêu. Vì vậy, quy trình chuẩn của đàn anh đi trước là: nếu có kế hoạch chuyển server vào tối thứ Bảy, hãy chủ động hạ TTL xuống thấp (ví dụ 300 giây) từ chiều thứ Sáu, đợi cho chu kỳ TTL cũ trôi qua hết rồi mới tiến hành đổi IP đích. Tương tự, với một tên miền con mới tinh vừa tạo, nếu bạn gõ thử trên trình duyệt trước khi lưu bản ghi DNS, rất có thể phản hồi NXDOMAIN (không tồn tại) đã bị lưu vào bộ nhớ đệm âm (Negative Cache) khiến bạn phải chờ thêm một lúc mới thấy tên miền sống dậy.

Theo tài liệu tham chiếu chính thức về TTL của Cloudflare (đối chiếu ngày 01/10/2026), chế độ Auto tương đương với 300 giây (5 phút). Với các bản ghi để chế độ đám mây xám (DNS only), bạn được toàn quyền chọn mốc TTL tùy ý; riêng các bản ghi bật đám mây cam (Proxied) sẽ mặc định khóa ở mức Auto. Tất nhiên, con số 300 giây trên lý thuyết không phải là lời cam kết rằng mọi ngóc ngách mạng trên toàn cầu sẽ đồng loạt thấy IP mới đúng 5 phút sau khi bấm nút lưu, vì một số ISP vẫn tự ý giữ cache lâu hơn một chút. Khi ghi nhật ký vận hành, bạn hãy luôn ghi kèm mốc thời gian, địa chỉ Resolver và con số TTL thực tế thu được.

Ảnh chụp bảng điều khiển thực tế ngày 30/09/2026 ghi nhận cấu hình bản ghi A, chế độ DNS only và mức TTL Auto của môi trường LAB-CF-02. Đây là ảnh chụp cấu hình trên giao diện quản trị vào ngày 30/09, tách biệt với kết quả đo đạc CLI ngày 01/10 bên dưới. Bạn có thể bấm vào ảnh để xem kích thước gốc.

Thực hành quan sát sự khác biệt TTL giữa hai nguồn

Trên máy chủ Ubuntu sử dụng dịch vụ phân giải cục bộ systemd-resolved tại địa chỉ 127.0.0.53, bạn có thể chạy cặp lệnh chỉ đọc (read-only) dưới đây, nghỉ tay vài giây rồi chạy lặp lại để tận mắt thấy đồng hồ TTL đếm ngược. Nếu thực hành trên máy tính cá nhân có cấu hình mạng khác, bạn chỉ việc thay địa chỉ IP trong lệnh bằng địa chỉ xuất hiện ở dòng SERVER từ Bước 1 và tên Nameserver thực tế lấy từ Bước 3:

dig @127.0.0.53 lab-cf02.localhost.vn A +noall +comments +answer +stats
dig @penny.ns.cloudflare.com lab-cf02.localhost.vn A +norecurse +noall +comments +answer +stats

Chúng ta chủ đích giữ lại phần thông tin bình luận (+comments) và thống kê (+stats) để quan sát rõ trạng thái status, cờ xác thực thẩm quyền gốc aa (Authoritative Answer) cùng dòng SERVER định danh nguồn trả lời. Thao tác quan sát này hoàn toàn vô hại, không làm thay đổi bản ghi cũng chẳng cần xóa bộ nhớ đệm. Nếu trong lúc theo dõi bạn thấy con số TTL đang giảm bỗng nhiên nhảy vọt lên lại mức 300, hãy kiểm tra kỹ xem có phải chu kỳ cache cũ vừa hết hạn và Resolver vừa đi lấy bản tin mới về hay không trước khi nghi ngờ hệ thống gặp lỗi.

Sơ đồ quy trình phân loại triệu chứng trước khi can thiệp sửa lỗi do đội ngũ localhost.vn biên soạn.

Hoàn thành, xử lý khôi phục (Rollback) và câu hỏi thường gặp

Bản thân các câu lệnh dig và nslookup trong bài viết này chỉ đóng vai trò đọc dữ liệu (read-only), không hề tác động hay chỉnh sửa bất kỳ cấu hình nào nên bạn không cần lo lắng chuyện phải hoàn tác câu lệnh. Tuy nhiên, nếu nhờ quá trình truy vấn mà bạn phát hiện ra bản ghi DNS mình vừa sửa ở bước trước bị gõ nhầm IP, cách rollback chuẩn chỉnh nhất là mở lại đúng Zone trên bảng điều khiển, cập nhật về giá trị IP cũ chính xác và tiếp tục dùng chính các Resolver vừa rồi để theo dõi cho tới khi cache cập nhật đồng bộ. Hãy nhớ rằng thao tác xóa bộ nhớ đệm DNS trên chiếc laptop của bạn (như ipconfig /flushdns) chỉ làm sạch đúng máy tính của bạn chứ không hề xóa giúp bộ nhớ đệm trên điện thoại hay mạng cáp quang của khách hàng.

Hỏi: Khi truy vấn DNS đã trả về đúng IP máy chủ mà mở trình duyệt vẫn báo lỗi thì phải làm sao?
Đáp: Lúc này danh bạ DNS đã hoàn thành xuất sắc nhiệm vụ chỉ đường! Bạn hãy ngừng đào bới bảng điều khiển DNS và chuyển ngay sang kiểm tra tầng giao vận và ứng dụng web: dùng curl thử phản hồi HTTP/HTTPS, kiểm tra xem cổng 80/443 đã mở trên UFW và Cloud Firewall chưa, cũng như rà soát lại cấu hình Server Block (Virtual Host) trong NGINX.

Hỏi: Có nên lôi ngay vũ khí hạng nặng dig +trace ra dùng từ đầu không?
Đáp: Chưa cần thiết đối với các bước kiểm tra thông thường. Lệnh dig +trace rất lợi hại khi bạn cần lần dấu vết ủy quyền từ cụm máy chủ Root (.) xuống TLD (.vn) rồi mới tới Nameserver của bạn, nhưng kết quả của nó rất dài và đôi khi bị tường lửa mạng nội bộ chặn giữa chừng. Hãy ưu tiên làm chủ các truy vấn trực diện và gọn gàng ở trên trước.

Hỏi: Cần lưu lại những thông tin gì làm bằng chứng nghiệm thu hoặc gửi phiếu hỗ trợ kỹ thuật?
Đáp: Hãy lưu lại trọn vẹn một bản tin dig đầy đủ (có dòng SERVER và dấu thời gian), kết quả so sánh giữa Public Resolver với Authoritative Nameserver, kèm theo địa chỉ IP đích mong muốn. Lưu ý che hoặc loại bỏ các tên miền nội bộ nhạy cảm nếu nằm ngoài phạm vi được phép chia sẻ công khai.

Kết quả thực nghiệm trên máy chủ LAB-CF-02 ngày 30/09/2026

Vào lúc 22:48 (múi giờ UTC+7), đợt chạy kiểm tra thực tế từ hệ điều hành Ubuntu 24.04 trên VPS LAB-CF-02 đã ghi nhận các thông số chuẩn xác như sau:

Tất cả các nguồn được hỏi đều trả về kết quả đồng nhất tại thời điểm ghi nhật ký, tuy nhiên điều này chỉ xác nhận trạng thái tại các điểm đo chứ không đại diện cho toàn bộ bộ nhớ đệm của mọi nhà mạng viễn thông. Do tên miền lab này không cấu hình bản ghi AAAA nên đợt thực nghiệm này chưa bao gồm việc kiểm tra kết nối web qua giao thức IPv6.

Phân tích ảnh chụp màn hình dig và nslookup ngày 01/10/2026

Bức ảnh chụp giao diện console lúc 09:25:59 (UTC+7) ngày 01/10/2026 ghi nhận công cụ dig 9.18.39 chạy trên Ubuntu của máy chủ LAB-CF-02. Khi truy vấn bản ghi A của tên miền lab, chúng ta đọc được tuần tự các thông số: trạng thái status: NOERROR, số lượng câu trả lời ANSWER: 1, mức TTL 300, địa chỉ IP 103.82.26.183 và máy chủ phản hồi SERVER: 127.0.0.53. Ngay bên dưới là danh sách hai Nameserver của Cloudflare và kết quả chạy lệnh nslookup chỉ định qua 1.1.1.1, tất cả đều trả về cùng địa chỉ IP kèm dòng chữ quen thuộc Non-authoritative answer.

Ảnh chụp màn hình console thực tế ngày 01/10/2026 lúc 09:25:59 (UTC+7); vùng hiển thị kết quả lệnh được giữ nguyên từng pixel và chỉ bổ sung thanh logo nhận diện ở dưới chân ảnh. Bấm vào ảnh để phóng to bản đầy đủ.

Đợt chạy lệnh này hoàn toàn chỉ đọc dữ liệu, không can thiệp sửa bản ghi hay xóa bộ nhớ đệm. Đây là một mốc quan sát độc lập vào buổi sáng, tách biệt với phép đo 4 mẫu đếm ngược TTL lúc 04:15 sáng cùng ngày ở phần tiếp theo.

Truy vấn A record từ nguồn Authoritative và phản hồi AAAA/CNAME

Bức ảnh console thứ hai được ghi nhận vào lúc 09:32:16 ngày 01/10/2026 (UTC+7). Đối với truy vấn bản ghi A, dòng SERVER hiển thị rõ địa chỉ 162.159.38.124 (tức máy chủ penny.ns.cloudflare.com), bật sáng cờ aa trong phần flags, trả về ANSWER: 1, mức TTL 300 và địa chỉ IP 103.82.26.183. Đối với hai truy vấn AAAA và CNAME đi qua Resolver cục bộ 127.0.0.53, cả hai đều nhận về mã NOERROR cùng số lượng câu trả lời ANSWER: 0. Vì máy chủ đã phản hồi tức thì một bản tin hợp lệ báo rằng không có loại bản ghi đó, chúng ta tuyệt đối không được đánh đồng kết quả ANSWER: 0 này với lỗi đứt kết nối Timeout.

Ảnh chụp console thực tế ngày 01/10/2026 lúc 09:32:16 (UTC+7), bảo toàn nguyên vẹn pixel vùng kết quả và gắn thêm dải logo ở chân ảnh. Ở phần truy vấn A, bạn có thể thấy rõ cờ aa, dòng answer và thông tin server; còn phần AAAA/CNAME hiển thị trọn vẹn cả trạng thái NOERROR lẫn ANSWER: 0. Bấm vào ảnh để xem kích thước lớn.

Cả hai đợt chụp màn hình console trên đều là thao tác đọc DNS thuần túy trên Ubuntu, không chỉnh sửa cấu hình hay phát sinh kiểm tra HTTP/HTTPS mới.

Bốn mẫu đo đếm ngược TTL thực tế ngày 01/10/2026

Để chứng minh trực quan sự khác biệt giữa TTL của bộ nhớ đệm và TTL của máy chủ gốc, trong khung giờ từ 04:15:41 đến 04:15:51 (giờ Việt Nam) ngày 01/10/2026, chúng tôi đã cho máy chủ LAB-CF-02 thực hiện 4 lượt truy vấn bản ghi A của cùng tên miền. Ở mỗi lượt, hai câu lệnh hỏi Local Resolver và Authoritative Nameserver được kích hoạt chạy song song; bảng số liệu dưới đây ghi nhận dấu thời gian ngay khi câu lệnh hoàn tất, với quãng nghỉ giữa các lượt là 3 giây:

Cả 8 câu lệnh truy vấn trong 4 lượt đo đều kết thúc hoàn hảo với mã thoát 0, trả về trạng thái NOERROR và địa chỉ IPv4 103.82.26.183. Bốn phản hồi từ máy chủ penny đều mang cờ xác thực aa. Như bạn thấy, con số TTL tại Local Resolver giảm đều đặn từ 300 xuống 296, 293 rồi 290 giây đúng theo nhịp đồng hồ đếm ngược của bộ nhớ đệm; trong khi đó, máy chủ gốc Authoritative vẫn kiên định báo mức TTL chuẩn là 300 giây. Hiện tượng một bên giảm, một bên giữ nguyên chính là cơ chế vận hành chuẩn mực của giao thức DNS chứ không phải lỗi đồng bộ.

Biểu đồ trực quan hóa dữ liệu từ 8 truy vấn thực tế trong 4 lượt đo (đơn vị: giây). Hai đường biểu diễn cho thấy rõ sự đối lập giữa thời gian lưu cache giảm dần tại Resolver cục bộ và giá trị TTL cố định từ Nameserver gốc. Bấm vào ảnh để xem rõ chi tiết.

Toàn bộ quá trình đo đạc trong cửa sổ 10 giây này chỉ quan sát tự nhiên mà không can thiệp xóa cache hay sửa bản ghi. Khi tự tay thực hành trên hệ thống của mình, bạn hãy luôn đảm bảo mình đang so sánh cùng một tên miền, cùng một loại bản ghi và xác định rõ nguồn trả lời trước khi đặt các con số TTL lên bàn cân.

Tài liệu tham khảo và bước tiếp theo

Các tài liệu kỹ thuật chính thống được đối chiếu phục vụ bài viết vào ngày 01/10/2026 bao gồm: Cloudflare Docs: Time to Live (TTL) và ISC BIND 9 Documentation: dig DNS lookup utility. Tài liệu của BIND xác nhận chuẩn xác cơ chế hiển thị vùng answer của dig cũng như cú pháp chỉ định máy chủ cho nslookup (lưu ý nhánh tài liệu latest của BIND thuộc bản 9.21 đang phát triển, trong khi gói thực tế trên Ubuntu 24.04 của lab là bản 9.18.39). Ngoài ra, tài liệu Cloudflare Docs: DNS record types được tham chiếu theo mốc ngày 30/09/2026.

Bạn có thể theo dõi bức tranh tổng thể tại lộ trình cài đặt WordPress trên VPS từ A đến Z. Nếu cần ôn lại kiến thức nền tảng, hãy xem lại bài trước: Nameserver, A, AAAA, CNAME khác nhau ở thao tác nào? Khi đã tự tin cầm dig xác nhận bản ghi A trỏ về đúng địa chỉ IP của VPS, mời bạn bước sang bài tiếp theo: Cấu hình Virtual Host (Server Block) cho domain và www để bắt đầu đón khách ở tầng máy chủ web.