DNS đã đổi trên panel nhưng khách vẫn thấy site cũ — vì sao?

Thường do cache resolver (TTL chưa hết), không phải 'DNS chưa đẩy đi toàn cầu'. Laptop bạn có thể đã refresh trong khi resolver nhà mạng của khách vẫn giữ IP cũ. Hãy so sánh câu trả lời từ nameserver authoritative với 1.1.1.1 / 8.8.8.8 trước khi báo 'xong'.

CNAME và A record khác nhau thế nào?

A (và AAAA) trỏ tên miền tới địa chỉ IP. CNAME trỏ tên miền tới một hostname khác (CDN, Pages, Heroku…). Apex (example.com) cổ điển không được đặt CNAME cạnh NS/SOA — dùng A/AAAA hoặc ALIAS/ANAME/flattened CNAME của nhà cung cấp.

TTL 300 có nghĩa 5 phút sau mọi người đều thấy bản mới?

Không. TTL là thời gian tối đa resolver được cache sau lần fetch. Một số cache ISP bỏ qua TTL ngắn. Hạ TTL trước cutover 1 ngày, đổi record, rồi mới nâng TTL lại khi ổn định.

Cloudflare đám mây cam ảnh hưởng CNAME lookup thế nào?

Chế độ Proxied (cam) công khai thường hiện IP anycast Cloudflare, không phải IP origin. Cập nhật A origin trong dashboard vẫn đúng hướng traffic CF→origin, nhưng dig công khai sẽ không 'thấy' IP VPS. Grey cloud (DNS only) mới lộ IP thật.

Dùng dig hay nslookup trên Windows?

nslookup có sẵn trên Windows. dig chi tiết hơn (ANSWER SECTION, TTL) — cài qua scoop/choco hoặc dùng WSL. Không bắt buộc dig: [DNS Check Kawa](/vi/tools/dns-check/) tra A/AAAA/CNAME/MX/TXT qua DNS over HTTPS khi bạn không muốn nhớ cờ lệnh.

Chỉ kiểm tra A đủ chưa?

Chưa. Mạng ưu tiên IPv6 sẽ dùng AAAA. Quên cập nhật AAAA = một nửa user vẫn vào máy cũ trong khi test IPv4 của bạn 'ổn'. Luôn kiểm cả A và AAAA sau cutover.

Kiểm tra DNS/CNAME đã lan chưa | Trước

Kết luận

“Domain xong” chỉ đúng khi authoritative NS trả đúng record và ít nhất 2 resolver công cộng đã khớp — không phải khi panel hosting hiện xanh. Propagation ≈ cache hết hạn (TTL), không phải phép đẩy toàn cầu. Freelancer VN: trước khi nhắn Zalo cho khách, chạy dig/nslookup (hoặc DNS Check) so authoritative vs 1.1.1.1/8.8.8.8, kiểm cả AAAA và bẫy Cloudflare proxy.

Freelancer hoặc team outsourcing Việt Nam hay gặp cảnh này: đổi A/CNAME trên cPanel / Cloudflare lúc 16:00, laptop Wi-Fi công ty thấy site mới, nhắn khách “Domain đã trỏ xong”. Tối hôm đó khách trên Viettel/FPT vẫn vào landing cũ — hoặc NXDOMAIN. Ticket mở lại, uy tín giảm, trong khi zone authoritative có thể đã đúng từ đầu.

Bài này là checklist trước khi báo khách, không phải định nghĩa DNS chung chung: thứ tự kiểm tra, lệnh, bảng lỗi, và case kiểu ship site cho SME Việt Nam.

Bài viết này giúp bạn

Phân biệt authoritative vs resolver cache (propagation thật sự là gì)
Quy trình dig / nslookup nhiều resolver trước khi “done”
Bẫy Cloudflare orange cloud, CNAME apex, quên AAAA
Checklist cutover + cách giải thích TTL cho khách không kỹ thuật
Dùng DNS Check Kawa khi cần xem nhanh A/CNAME/MX/TXT

Vì sao “tôi thấy được” ≠ “khách thấy được”

DNS là hệ thống nhất quán cuối cùng có ý kiến (eventually consistent with opinions). Mỗi resolver giữ bản cache đến khi TTL hết. Không có nút “Push to Vietnam”.

Bạn đang nhìn	Có thể đúng với
Panel DNS (Cloudflare / cPanel)	Cấu hình bạn vừa lưu — chưa chứng minh public
`ping` / trình duyệt trên laptop	Resolver + cache máy bạn
dig `@ns1...` (authoritative)	Nguồn sự thật của zone
dig `@1.1.1.1` / `@8.8.8.8`	Cache công cộng phổ biến
Mạng 4G khách	Resolver nhà mạng — đôi khi chậm hơn

Quy tắc vàng: authoritative đúng + public vẫn cũ → chờ TTL. Authoritative sai → sửa zone, đừng đổ lỗi “DNS đang lan”.

Thứ tự kiểm tra (4 bước)

Thứ tự debug DNS

Bước	Câu hỏi	Nếu lệch
1. NS	Registrar trỏ nameserver nào?	Sửa nhầm panel → zone không phải nơi traffic đang hỏi
2. Authoritative	NS đó trả A/AAAA/CNAME gì?	Sửa record tại host đúng — chưa nói tới propagation
3. Public DNS	1.1.1.1 và 8.8.8.8 trả gì?	Đúng → đợi TTL; sai lâu → kiểm cache / typo
4. User path	ISP / office DNS / LTE trả gì?	Split-horizon hoặc cache cứng — hỏi IT trước khi đổi zone lần nữa

Lệnh thực tế

Windows (nslookup):

nslookup -type=NS shop-khach.vn
nslookup shop-khach.vn 1.1.1.1
nslookup shop-khach.vn 8.8.8.8
nslookup -type=CNAME www.shop-khach.vn 1.1.1.1

macOS / Linux / WSL (dig — khuyến nghị):

dig shop-khach.vn NS +short
dig @ns1.dns-provider.net shop-khach.vn A +short
dig @1.1.1.1 shop-khach.vn A +short
dig @8.8.8.8 shop-khach.vn AAAA +short
dig @1.1.1.1 www.shop-khach.vn CNAME +short

So @authoritative với @1.1.1.1 kết thúc hầu hết tranh luận Zalo. Chụp terminal gửi khách kèm câu: “Máy chủ DNS gốc đã đúng; một số mạng còn cache khoảng X phút theo TTL.”

Không muốn nhớ cờ: mở DNS Check, chọn loại record (A, AAAA, CNAME, MX, TXT), đối chiếu với giá trị trên panel.

Propagation không phải phép màu

“DNS propagation” trong hầu hết ticket nghĩa là cache hết hạn. Không có sóng đẩy từ Hà Nội ra toàn cầu.

TTL 86400 khi đổi IP = có thể một ngày “hai thế giới” (một nửa user cũ, một nửa mới).
Hạ TTL xuống 300 (hoặc 60) trước cutover 1 ngày, đổi record, theo dõi resolver, rồi nâng TTL khi ổn.
Đổi khi TTL vẫn 86400 vào thứ Sáu 17:00 = tự lên lịch cuối tuần hỗ trợ.

Gửi PM/khách ảnh dig: authoritative đúng, public còn cũ, ETA ≈ TTL còn lại — hiệu quả hơn giải thích RFC.

CNAME lookup — khi nào và bẫy apex

CNAME dùng để làm gì

Subdomain trỏ SaaS / CDN / hosting:

www.shop-khach.vn     CNAME   shops.myshopify.com     ✅
cdn.shop-khach.vn     CNAME   d123.cloudfront.net     ✅
shop-khach.vn         CNAME   shops.myshopify.com     ❌ cổ điển (xung đột NS/SOA)
shop-khach.vn         A / ALIAS / flattened CNAME     ✅ theo host

Apex CNAME cạnh NS/SOA là lỗi kinh điển khi “copy y nguyên hướng dẫn www”. Dùng tính năng ALIAS / ANAME / CNAME flattening của Cloudflare, Route 53, DNSimple… hoặc A/AAAA.

Chuỗi CNAME

www → proxy.cdn.net → origin.example.net. Lookup từng bước; đừng chỉ tin panel hiện một dòng. Email (MX) và web (A/CNAME) trên cùng nhãn có thể cạnh tranh nếu đặt sai tên record (@ vs www).

Cloudflare / proxy — nhìn DNS ≠ nhìn origin

Chế độ	dig công khai thấy	Traffic thực tế
Grey (DNS only)	IP origin (VPS)	Thẳng tới máy bạn
Orange (Proxied)	IP anycast Cloudflare	CF → origin trong dashboard

Bạn “đã đổi A sang VPS mới” nhưng cam vẫn bật: dig không hiện IP VPS — bình thường. Lỗi SSL Full Strict / origin sai hay bị đổ oan là “DNS chưa lan”. /etc/hosts chỉ sửa máy bạn — đừng dùng làm bằng chứng với khách.

Lỗi hay gặp (bảng triệu chứng)

Triệu chứng	Nguyên nhân thường	Việc làm ngay
Laptop mới, khách cũ	TTL / cache ISP	dig nhiều resolver; báo ETA
NXDOMAIN sau khi “đã add”	Sai `@` vs `www`, hoặc NS registrar chưa trỏ host mới	Kiểm NS trước
Chỉ một số mạng lỗi	Quên AAAA (IPv6)	dig AAAA; cập nhật hoặc xóa AAAA cũ
CNAME “biến mất”	Orange cloud / flattened	Xem dashboard proxy + origin
Web OK, mail chết	Đổi NS quên copy MX/TXT	Checklist MX, SPF, DKIM, CAA
”Ping đúng nhưng HTTPS sai”	Proxy / cert / SNI — không phải A	Tách DNS vs TLS (xem bài SSL)

Case study (ẩn danh — kiểu freelance VN)

Case A — Báo xong trên Wi-Fi văn phòng. Dev đổi A VPS lúc TTL còn ~20 giờ. dig @8.8.8.8 đã mới; khách FPT vẫn cũ. Fix quy trình: không báo “xong” cho đến khi hai resolver công cộng khớp hoặc đã nêu rõ “một số mạng chờ hết TTL”.

Case B — Shopify + apex. Đặt CNAME tại @ → zone lỗi / hành vi lạ. Chuyển sang A/ALIAS theo docs Shopify + CNAME chỉ cho www, rồi 301 apex→www.

Case C — Đổi nameserver mất mail. Web về Cloudflare, quên mang MX Google Workspace. “DNS hỏng” thực ra là checklist thiếu. In before/after: A, AAAA, CNAME, MX, TXT, CAA trong ticket.

Case D — Office DNS split-horizon. Công ty khách resolve nội bộ app.khach.vn khác public. LTE điện thoại đúng, Wi-Fi văn phòng sai. Hỏi IT resolver trước khi sửa zone lần 3.

Checklist trước khi nhắn khách

Registrar NS trỏ đúng host đang edit
Authoritative trả đúng A / AAAA / CNAME
1.1.1.1 và 8.8.8.8 đã khớp (hoặc đã giải thích TTL còn lại)
Đã kiểm AAAA (hoặc chủ đích không dùng IPv6)
CDN/proxy: origin + chế độ cam/xám đúng ý
Nếu đổi NS: MX, TXT (SPF/DKIM), CAA còn đủ
TTL strategy: đã hạ trước cutover (nếu có kế hoạch)
Gửi bằng chứng (screenshot dig hoặc DNS Check), không chỉ “panel xanh”

Cách dùng DNS Check trên Kawa

Mở Kiểm tra DNS / CNAME Lookup
Nhập domain (ví dụ www.shop-khach.vn)
Chọn loại record: A, AAAA, CNAME, MX, hoặc TXT
Đối chiếu kết quả với panel DNS và với kỳ vọng trong hợp đồng/hosting docs
Lặp với apex và subdomain quan trọng (api., cdn.)

Tool lấy bản ghi qua DNS over HTTPS — tiện khi máy Windows chưa có dig, hoặc cần nhìn nhanh nhiều loại record trong một tab. Không thay dig @authoritative khi tranh luận “zone đã đúng chưa”, nhưng đủ cho bước đối chiếu public trong checklist trên.

FAQ nhanh

Chỉ cần F5 trình duyệt?
Không — cache DNS và cache HTTP khác nhau. Đổi record phải hỏi resolver, không phải hard refresh.

Bao lâu thì “lan xong”?
Theo TTL và cache cứng của ISP — vài phút đến 48 giờ trong trường hợp xấu. Authoritative đúng là điều kiện dừng sửa zone.

TXT SPF/DKIM kiểm thế nào?
Cùng tool hoặc dig TXT. Sau migrate mail, đây là bước hay bị bỏ.

CAA là gì?
Giới hạn CA được cấp cert. Đổi NS/host mà mất CAA có thể chặn Let’s Encrypt — kiểm kèm SSL.

Liên kết liên quan

Công cụ DNS Check — tra A/AAAA/CNAME/MX/TXT nhanh
Kiểm tra hạn SSL — sau khi DNS đúng, xác nhận HTTPS không hết hạn
Danh sách công cụ

Công cụ