DNS đã đổi nhưng website vẫn trỏ sai: kiểm tra từ đâu?

Khi vừa đổi DNS mà website vẫn mở từ máy chủ cũ, việc vội vã xóa cache trình duyệt hay sửa lại bản ghi nhiều lần thường không mang lại kết quả. Điều quan trọng trước tiên là xác định câu trả lời cũ đang xuất hiện ở tầng nào trong chuỗi phân giải.

Thứ tự kiểm tra:

1. Domain đang được delegate tới nameserver nào.
2. Từng authoritative nameserver đang trả bản ghi gì.
3. Recursive resolver còn giữ cache cũ hay không.
4. Thiết bị hoặc trình duyệt có đang dùng đường DNS riêng (DoH, VPN, hosts) không.
5. DNS đã trỏ đúng nhưng CDN, TLS hoặc web server vẫn đang phục vụ website cũ hay không.

Thứ tự này giúp tách biệt rõ ràng giữa hai trường hợp: một thay đổi chỉ cần chờ hết TTL của cache, và một cấu hình sai sẽ không bao giờ tự hoạt động dù chờ bao lâu.

Mỗi lớp có thể giữ một câu trả lời khác nhau; hãy xác định chính xác lớp nào còn trỏ sai.

Ghi lại chính xác thay đổi trước khi kiểm tra

“Đã đổi DNS” có thể là nhiều việc khác nhau: đổi IP trong bản ghi A, thêm AAAA, đổi CNAME, chuyển nameserver sang nhà cung cấp khác hoặc bật proxy CDN. Mỗi thay đổi có đường kiểm tra riêng.

Hãy ghi lại:

• Domain hoặc hostname đầy đủ, ví dụ example.com hay www.example.com.
• Record type đã đổi: A, AAAA, CNAME hay NS.
• Giá trị cũ và giá trị mới.
• TTL trước lúc đổi và TTL hiện tại.
• Thời điểm lưu thay đổi, kèm múi giờ.
• DNS provider và registrar đang sử dụng.
• Proxy/CDN có được bật trên record hay không.

Đừng coi apex và www là một. example.com có thể trỏ đúng máy chủ mới trong khi www.example.com vẫn là CNAME tới một đích cũ. Tương tự, bản ghi A có thể đúng nhưng AAAA vẫn dẫn client IPv6 tới hạ tầng cũ.

Bước 1: xác nhận domain đang dùng đúng authoritative nameserver

Authoritative nameserver là nơi công bố dữ liệu DNS của domain. Bạn có thể sửa record rất đúng trong một dashboard, nhưng thay đổi đó không có tác dụng nếu Internet đang được delegate tới nameserver của nhà cung cấp khác.

Kiểm tra NS hiện được công bố:

dig NS example.com

Nếu vừa chuyển DNS provider, truy vấn theo chuỗi delegation giúp thấy parent zone đang chỉ về đâu:

dig +trace example.com NS

So sánh kết quả với nameserver được gán trong dashboard của DNS provider. Cần kiểm tra đúng tên, không chỉ nhìn thấy cùng thương hiệu. Một zone được xóa rồi thêm lại có thể nhận cặp nameserver khác trước.

Nếu parent/TLD vẫn trả nameserver cũ, sửa record ở provider mới chưa thể ảnh hưởng public DNS. Bạn cần cập nhật nameserver tại registrar. Với một subdomain được delegate riêng, thay đổi lại nằm trong parent zone của subdomain đó, không nhất thiết ở registrar.

Khi chuyển DNS provider và domain có DNSSEC, bản ghi DS cũ tại registrar cũng có thể làm resolver xác thực từ chối câu trả lời mới. Không nên tắt DNSSEC rồi coi sự cố đã giải quyết; cần đồng bộ lại chuỗi ký và delegation theo hướng dẫn của provider.

Bước 2: hỏi trực tiếp từng authoritative nameserver

Sau khi delegation đúng, bỏ qua recursive cache và truy vấn thẳng từng authoritative server:

dig @ns1.provider.example example.com A
dig @ns2.provider.example example.com A

Lặp lại với đúng hostname và record type liên quan:

dig @ns1.provider.example example.com AAAA
dig @ns1.provider.example www.example.com CNAME

Bạn cần nhìn bốn phần:

• status: truy vấn thành công, NXDOMAIN, SERVFAIL hay timeout.
• ANSWER: hostname, record type và giá trị trả về.
• TTL còn lại.
• Server nào đã trả lời.

Nếu authoritative server vẫn trả IP cũ, đây chưa phải vấn đề cache của ISP. Các khả năng thường gặp là:

• Bạn sửa zone ở sai tài khoản hoặc sai provider.
• Sửa www nhưng người dùng truy cập apex, hoặc ngược lại.
• Sửa A nhưng traffic đi qua AAAA hay CNAME.
• Thay đổi còn ở trạng thái draft, chưa được publish.
• Automation hoặc IaC đã ghi đè record sau khi bạn sửa tay.
• Một record wildcard hoặc CNAME khác đang quyết định câu trả lời.

Đừng giảm TTL hoặc xóa cache local ở giai đoạn này. Authoritative data phải đúng trước.

Tất cả authoritative server phải trả lời nhất quán

Một domain thường có từ hai authoritative nameserver. Resolver có thể hỏi bất kỳ server nào, vì vậy chúng cần phục vụ cùng một phiên bản zone hoặc ít nhất cùng kết quả dự kiến.

Nếu ns1 trả IP mới nhưng ns2 trả IP cũ, người dùng có thể lúc vào đúng website, lúc vào máy cũ. Chờ cache không giải quyết được nguồn dữ liệu không đồng nhất.

Hãy truy vấn từng server với cùng hostname và record type. Nếu provider dùng zone serial trong SOA, so sánh serial cũng giúp phát hiện server chưa đồng bộ:

dig @ns1.provider.example example.com SOA
dig @ns2.provider.example example.com SOA

Với DNS có GeoDNS, load balancing hoặc chính sách theo vị trí, answer khác nhau có thể là chủ đích. Khi đó, điều cần kiểm tra không phải “IP có giống hệt nhau không” mà là mỗi answer có thuộc tập đích hợp lệ hay không.

Bước 3: kiểm tra đủ A, AAAA và CNAME

Một trình duyệt không nhất thiết dùng bản ghi bạn vừa xem.

A và AAAA

A ánh xạ hostname tới IPv4. AAAA ánh xạ tới IPv6. Nếu cả hai tồn tại, thiết bị có IPv6 có thể chọn đường AAAA trong khi một thiết bị khác dùng A.

Kiểm tra riêng:

dig example.com A
dig example.com AAAA

Nếu A đã về máy mới nhưng AAAA còn IP cũ, sự cố có thể chỉ xuất hiện trên một số mạng có hỗ trợ IPv6. Tránh xóa ngay bản ghi AAAA khi chưa tìm hiểu rõ. Hãy xác định website có chủ đích phục vụ IPv6 không, origin mới đã sẵn sàng nhận traffic IPv6 chưa và cấu hình firewall/TLS có hỗ trợ đường đó không.

CNAME chain

www.example.com có thể là CNAME tới một hostname khác, rồi hostname đó mới có A hoặc AAAA. Mỗi mắt xích có record và TTL riêng.

dig www.example.com CNAME
dig target.example.net A
dig target.example.net AAAA

Nếu chỉ đổi record ở cuối chuỗi nhưng một CNAME cũ vẫn còn cache, resolver có thể tiếp tục hỏi sai đích. Khi dùng công cụ flush cache của public resolver, cần hiểu toàn bộ chain thay vì chỉ flush hostname người dùng nhập.

TTL nói điều gì và không nói điều gì?

TTL cho phép recursive resolver giữ một câu trả lời trong cache trong một khoảng thời gian trước khi phải hỏi lại authoritative server. Nếu resolver đã lấy IP cũ với TTL 3600 giây ngay trước lúc bạn đổi record, nó có thể tiếp tục trả IP đó cho tới khi cache hết hạn.

Điểm quan trọng là TTL được cache tại thời điểm câu trả lời cũ được nhận. Giảm TTL từ 3600 xuống 300 sau khi đổi record không làm cache 3600 giây đang tồn tại tự rút ngắn.

Vì vậy, trước một migration có kế hoạch:

1. Giảm TTL trước đủ lâu để cache theo TTL cũ hết hạn.
2. Xác nhận authoritative server đã trả TTL mới.
3. Thực hiện thay đổi trong maintenance window.
4. Giữ hạ tầng cũ hoạt động trong khoảng chuyển tiếp nếu có thể.
5. Tăng TTL lại sau khi hệ thống ổn định.

TTL thấp không sửa được record sai. Nó chỉ làm resolver hỏi lại dữ liệu sai thường xuyên hơn.

So sánh recursive resolver để nhận biết cache cũ

Khi authoritative answer đã đúng, truy vấn một vài recursive resolver:

dig @1.1.1.1 example.com A
dig @8.8.8.8 example.com A

So sánh answer và TTL. Một tình huống thường gặp là:

• Authoritative server trả IP mới.
• Resolver A trả IP mới.
• Resolver B còn trả IP cũ với TTL đang giảm.

Đây có thể là cache hợp lệ. Bạn có thể chờ TTL hết hạn hoặc dùng công cụ flush do resolver đó cung cấp nếu phù hợp. Việc xóa cache trên laptop không xóa cache tại resolver của ISP hay public DNS.

Kết quả khác nhau giữa resolver không luôn đồng nghĩa có lỗi. CDN hoặc authoritative DNS có thể trả đích khác nhau theo vị trí resolver hoặc EDNS Client Subnet. Thay vì yêu cầu mọi IP giống nhau, hãy xác minh chúng đều thuộc hạ tầng dự kiến.

NXDOMAIN cũng có thể được cache

Nếu người dùng truy cập một hostname trước khi bạn tạo record, resolver có thể cache câu trả lời “không tồn tại”. Sau khi record được thêm, một số nơi vẫn nhận NXDOMAIN cho tới khi negative cache hết hạn.

Khi điều tra, ghi rõ kết quả cũ là một IP cũ hay NXDOMAIN. Đây là hai trường hợp cache khác nhau. Việc tạo record mới không bắt mọi resolver bỏ ngay câu trả lời âm đã lưu.

Nếu authoritative server trả record đúng nhưng một resolver vẫn trả NXDOMAIN, kiểm tra TTL/negative caching và delegation. Nếu nhiều resolver trả SERVFAIL, hãy xem thêm DNSSEC, authoritative availability và khả năng trả lời qua cả UDP/TCP thay vì chỉ chờ.

Cache phía thiết bị chỉ là một lớp

Sau khi public resolver trả đúng mà một máy vẫn thấy kết quả cũ, mới chuyển sang client.

Trên Windows, có thể xem và xóa DNS client cache:

ipconfig /displaydns
ipconfig /flushdns

nslookup truy vấn DNS server được chỉ định và không dựa vào DNS client cache của Windows, nên có thể dùng để so sánh:

nslookup example.com 1.1.1.1
nslookup example.com 8.8.8.8

Ngoài cache hệ điều hành, hãy kiểm tra:

• Trình duyệt có dùng DNS over HTTPS với resolver riêng không.
• Router hoặc mạng doanh nghiệp có DNS cache không.
• VPN có đẩy DNS server khác không.
• File hosts có ánh xạ thủ công không.
• Một captive portal hoặc phần mềm bảo mật có can thiệp DNS không.

Xóa cache trình duyệt, DNS client và khởi động router cùng lúc có thể làm triệu chứng biến mất nhưng mất luôn bằng chứng về lớp gây lỗi. Tốt hơn là so sánh từng lớp trước khi xóa.

Khi dùng CDN hoặc proxy, IP public không phải IP origin

Nếu record được proxy qua Cloudflare hoặc một CDN tương tự, truy vấn A/AAAA có thể trả IP của mạng CDN thay vì IP máy chủ gốc. Đây có thể là hành vi đúng.

Trong trường hợp đó, đừng kết luận “DNS chưa đổi” chỉ vì không thấy IP origin mới. Hãy kiểm tra:

• Record đang ở chế độ proxied hay DNS-only.
• Origin address được cấu hình trong CDN/load balancer là gì.
• Request có tới origin mới trong access log không.
• Host header và SNI được gửi tới origin có đúng không.
• CDN còn cache nội dung hoặc redirect từ origin cũ không.

Chuyển record sang DNS-only chỉ để nhìn thấy IP origin có thể làm thay đổi đường traffic, bỏ qua lớp bảo vệ và để lộ origin. Nếu cần thử origin, dùng một phương pháp kiểm tra có kiểm soát thay vì thay đổi production DNS tùy tiện.

DNS đúng nhưng website vẫn sai

Khi delegation, authoritative answer và recursive resolver đều đúng, vấn đề chính có thể đã chuyển khỏi DNS.

Web server phục vụ nhầm virtual host

Một IP có thể phục vụ nhiều website. Nếu Nginx hoặc Apache chưa có đúng server_name/virtual host, request tới domain mới có thể rơi vào default site.

Certificate không khớp

DNS đưa client tới đúng IP nhưng certificate tại CDN, load balancer hoặc origin chưa chứa hostname. Khi đó, trình duyệt báo lỗi TLS dù DNS hoàn toàn đúng.

Redirect quay về domain hoặc origin cũ

Ứng dụng, reverse proxy hoặc CDN có thể còn redirect 301/302 tới hostname cũ. Trình duyệt cũng có thể đã cache redirect lâu dài. Hãy xem response header thay vì chỉ nhìn trang cuối.

Cache HTTP còn nội dung cũ

CDN, reverse proxy, plugin cache hoặc service worker có thể phục vụ nội dung cũ sau khi DNS đã chuyển. DNS TTL và cache TTL của nội dung là hai cơ chế khác nhau.

Origin mới chưa sẵn sàng

Máy chủ mới có thể trả 502, 404 hoặc trang mặc định vì application, firewall hay upstream chưa đúng. Bài Website trả lỗi 502: kiểm tra proxy, ứng dụng hay tài nguyên trước? giúp tiếp tục điều tra khi DNS đã đưa request tới đúng hạ tầng nhưng reverse proxy không gọi được application.

Bảng đọc nhanh kết quả

Quy trình đổi DNS an toàn cho lần sau

Một thay đổi có kế hoạch nên được chuẩn bị từ trước:

1. Kiểm kê apex, www, A, AAAA, CNAME, MX và record xác minh liên quan.
2. Giảm TTL trước đủ lâu, không phải sau khi đã đổi.
3. Chuẩn bị origin mới, certificate và virtual host trước khi chuyển traffic.
4. Kiểm tra origin mới bằng cách không làm ảnh hưởng người dùng public.
5. Ghi lại giá trị cũ, mới, thời điểm và người thực hiện.
6. Đổi một lớp có chủ đích; tránh đồng thời đổi registrar, nameserver, CDN và origin nếu không cần thiết.
7. Hỏi trực tiếp từng authoritative server sau khi lưu.
8. So sánh một vài resolver và kiểm tra cả IPv4/IPv6.
9. Giữ origin cũ trong khoảng chuyển tiếp nếu kiến trúc cho phép.
10. Theo dõi TLS, HTTP status, nội dung và log origin—not chỉ DNS lookup.

Nếu cần rollback, hãy đưa record về giá trị cũ đã ghi nhận và tiếp tục tính tới cache. Rollback DNS cũng không diễn ra tức thì đối với resolver đang giữ answer mới.

Checklist khi website vẫn trỏ sai

• ☐ Đã ghi đúng hostname, record type, giá trị cũ/mới và thời điểm đổi.
• ☐ Delegation tại parent/registrar trỏ tới đúng authoritative nameserver.
• ☐ Từng authoritative server trả cùng kết quả dự kiến.
• ☐ A, AAAA, CNAME, apex và www đã được kiểm tra riêng.
• ☐ TTL cũ được dùng để ước lượng cache, không chỉ TTL hiện tại.
• ☐ Đã so sánh một vài recursive resolver.
• ☐ Đã phân biệt IP cũ với NXDOMAIN hoặc SERVFAIL.
• ☐ DNSSEC được kiểm tra nếu vừa đổi nameserver hoặc thấy validation failure.
• ☐ Proxy/CDN được tính đến trước khi so IP public với origin.
• ☐ Cache client, browser DoH, VPN và file hosts chỉ được kiểm tra sau lớp public DNS.
• ☐ Khi DNS đúng, đã chuyển sang kiểm tra TLS, virtual host, redirect và cache HTTP.
• ☐ Origin cũ chưa bị tắt trước khi đường mới được xác nhận ổn định.

“DNS cần thời gian” chỉ đúng khi dữ liệu authoritative đã chính xác và một cache hợp lệ chưa hết TTL. Nếu delegation sai, authoritative server trả record cũ hoặc AAAA vẫn trỏ về máy cũ, chờ thêm sẽ không giải quyết được. Hãy tìm đúng lớp đang trả câu trả lời sai rồi mới quyết định sửa hay chờ. Nếu việc trỏ sai DNS diễn ra ngay giữa đợt chuyển đổi website khiến khách hàng gặp sự cố, bạn nên áp dụng Quy trình 30 phút đầu khi website gặp sự cố để vừa bảo vệ dữ liệu vừa thực hiện rollback kịp thời.

Nguồn tham khảo

• Cloudflare DNS — DNS record types
• Cloudflare DNS — Update nameservers
• Cloudflare DNS — Pending nameserver troubleshooting
• Cloudflare DNS — Proxied records and origin IP
• Google Public DNS — Troubleshooting
• Google Public DNS — Domain troubleshooting
• Google Public DNS — Performance and caching
• Microsoft Learn — Troubleshooting DNS clients