DNS là gì? A, CNAME, NS cho junior trước khi tick checklist domain
DNS không phải ‘bấm Save là xong’. Junior cần nắm A = tên → IP, CNAME = tên → tên khác, NS = ai đang quản lý zone. Trước khi tick checklist domain: xác nhận NS đúng nhà, record khớp dig/DNS check (không chỉ khớp UI), và www ≠ apex nếu bạn chỉ sửa một bên. F5 trình duyệt không chứng minh propagation.
Bạn vừa trỏ domain cho khách trên Vercel / Netlify / Cloudflare. Panel báo Changes saved. Mở Chrome — vẫn trang cũ hoặc DNS_PROBE_FINISHED_NXDOMAIN. Khách hỏi: “Xong chưa?”
Bài này dành cho junior và freelance cần hiểu DNS đủ để không báo xong sớm. Không đi sâu RFC hay DNSSEC — tập trung A, CNAME, NS và checklist trước khi bàn giao.
Bài viết này giúp bạn
- Hiểu DNS bằng mô hình “hỏi → trả lời” thay vì thuật ngữ khô
- Phân biệt A / AAAA / CNAME / NS / MX / TXT đủ để làm việc hàng ngày
- Biết khi nào dùng A, khi nào CNAME (và lỗi hay gặp ở apex)
- Có checklist bàn giao domain + cách kiểm tra bằng lệnh hoặc tool
- Case study: subdomain đúng, apex sai — và ngược lại
DNS là gì? (mô hình junior)
DNS (Domain Name System) là hệ thống dịch tên miền (shop.khach.vn) thành thông tin máy có thể nối tới — thường là địa chỉ IP, đôi khi là tên miền khác hoặc máy mail.
Luồng đơn giản:
- Bạn gõ
www.example.comtrên trình duyệt - Resolver (ISP,
1.1.1.1, DNS over HTTPS…) hỏi nameserver của zone - Nameserver trả bản ghi (A, CNAME, …)
- Trình duyệt mới bắt tay TCP/TLS tới IP thật
Nếu bước 2–3 sai, bạn có thể có SSL đẹp trên server cũ, deploy mới hoàn hảo — nhưng người dùng vẫn vào chỗ sai. Đó là lý do kiểm tra DNS trước khi đổ lỗi app.
Cache trình duyệt + cache OS + TTL trên resolver trung gian khiến F5 vô ích. Hãy hỏi DNS trực tiếp bằng dig / nslookup hoặc DNS Record Check.
Ba bản ghi junior phải thuộc lòng
A và AAAA — tên trỏ thẳng IP
| Loại | Ý nghĩa | Ví dụ |
|---|---|---|
| A | IPv4 | example.com → 93.184.216.34 |
| AAAA | IPv6 | example.com → 2606:2800:… |
Dùng khi hosting/VPS đưa cho bạn một IP cố định, hoặc khi apex không hỗ trợ CNAME.
example.com. A 203.0.113.10
www.example.com A 203.0.113.10
CNAME — tên trỏ sang tên khác
CNAME nói: “đừng hỏi IP tôi — hỏi hostname kia”. Phổ biến với CDN, SaaS, subdomain:
www.example.com. CNAME cname.vercel-dns.com.
api.example.com. CNAME ghs.googlehosted.com.
Ưu: Đổi IP phía đích một lần, mọi CNAME theo sau tự cập nhật.
Nhược / rule vàng: Trên cùng một hostname, CNAME không đứng cạnh A/AAAA/MX. Nhiều panel vẫn cho “save” rồi zone bị reject hoặc hành vi lạ — luôn kiểm tra bằng lookup thật.
NS — ai đang cầm zone
example.com. NS ada.ns.cloudflare.com.
example.com. NS bob.ns.cloudflare.com.
NS trả lời câu: “Sửa A trên chỗ nào mới có hiệu lực?” Freelance hay mắc: sửa record trên cPanel hosting trong khi NS đã trỏ Cloudflare (hoặc ngược lại). UI save thành công — internet vẫn hỏi nameserver kia.
So sánh nhanh: chọn bản ghi nào?
| Tình huống | Nên dùng | Ghi chú |
|---|---|---|
| Apex (@) → VPS có IP | A / AAAA | Đơn giản, dễ debug bằng ping/dig |
| www → Vercel/Netlify/CDN | CNAME | Theo đúng docs nhà hosting |
| api. / docs. / cdn. | CNAME (thường) | Trừ khi dịch vụ bắt A cố định |
| Chuyển DNS sang Cloudflare | Đổi NS ở registrar | Đợi NS propagate rồi mới tin record mới |
| Xác minh domain / SPF | TXT | Không thay A/CNAME — bổ sung song song |
| Email @domain | MX (+ SPF TXT) | Sai MX = mail vào nhầm chỗ dù web đúng |
Apex và CNAME — cái bẫy cổ điển
Nhiều DNS cấm CNAME ở apex (example.com). Hosting bảo “trỏ CNAME vào chúng tôi” — áp dụng cho www, còn @ cần A/AAAA hoặc bản ghi đặc biệt (ALIAS / ANAME / CNAME flattening của Cloudflare).
Junior checklist sai: chỉ cấu hình www, quên apex → khách mở example.com vào trang registrar mặc định.
Bản ghi phụ bạn sẽ gặp ngay tuần đầu
- MX — máy nhận mail. Web đúng ≠ mail đúng.
- TXT — SPF, DKIM, xác minh Google/Meta/Apple. Paste nguyên chuỗi, đừng thêm dấu ngoặc thừa nếu panel đã quote.
- AAAA — thiếu AAAA đôi khi vẫn OK; có AAAA sai thì dual-stack client có thể vào IP chết trước.
Không cần thuộc hết — nhưng khi khách bảo “domain xong mà mail/verify fail”, hãy mở đúng loại record thay vì sửa A lung tung.
Vì sao “đã save” mà chưa thấy?
TTL và cache
Mỗi bản ghi có TTL (giây). Resolver giữ câu trả lời cũ đến khi hết hạn. Đổi A từ IP cũ → IP mới: một số mạng thấy ngay, một số giữ vài phút đến nhiều giờ.
Mẹo trước khi migrate: hạ TTL xuống ~300 vài ngày trước giờ cắt. Sau khi ổn định, tăng lại để giảm query.
Bạn đang nhìn resolver khác nhau
| Cách kiểm tra | Ý nghĩa |
|---|---|
| Chỉ F5 Chrome | Cache mạnh, dễ sai |
nslookup mặc định | Theo DNS máy/ISP |
dig @1.1.1.1 / @8.8.8.8 | Resolver công khai — gần “internet thấy gì” |
| DNS check Kawa | Lookup qua DNS over HTTPS, chọn A/CNAME/MX/TXT |
www và apex là hai hostname
Sửa www không tự sửa @. Checklist phải liệt kê từng tên cần sống.
Cách kiểm tra thực tế
Windows (nslookup)
nslookup example.com
nslookup www.example.com
nslookup -type=NS example.com
nslookup -type=CNAME www.example.com 1.1.1.1
macOS / Linux (dig)
dig example.com A +short
dig www.example.com CNAME +short
dig example.com NS +short
dig @8.8.8.8 example.com A
Online nhanh (không cần cài gì)
Mở CNAME Lookup & DNS Check, nhập domain, chọn loại A / AAAA / CNAME / MX / TXT. Tool lấy bản ghi qua DNS over HTTPS — tiện khi máy công ty chặn dig hoặc bạn đang trên Windows thiếu dig.
🌐 Kiểm tra DNS ngay tại đây
Cách đọc kết quả:
- A của apex có khớp IP panel không?
- www là CNAME đúng đích docs hosting không?
- NS có đúng Cloudflare/Route53 bạn đang edit không?
- Nếu “No records” — hoặc sai zone, hoặc chưa propagate, hoặc bạn gõ nhầm hostname
Checklist trước khi tick “domain xong”
In hoặc copy vào PR/ticket bàn giao:
- NS tại registrar khớp nameserver nhà DNS bạn sửa
- A/AAAA apex → IP hoặc ALIAS đúng (không còn trang parking)
- www → CNAME/A đúng; thử cả
https://example.comvàhttps://www.example.com - Subdomain dự án (
api.,staging.) có trong list và lookup được - Lookup từ resolver công khai khớp panel (không chỉ UI xanh)
- Thử mạng khác (4G điện thoại) để loại cache ISP văn phòng
- Cert HTTPS cover đúng tên (tránh mở IP cũ còn cert cũ)
- Nếu có mail: MX + SPF TXT không bị xóa nhầm khi dọn zone
Chỉ báo khách khi bước 2–6 xanh. “Đã bấm Save” không nằm trong định nghĩa xong.
Case study ngắn
1) Freelance: www đúng, apex sai
Cấu hình Vercel theo docs — thêm CNAME www → cname.vercel-dns.com. Quên A/ALIAS cho @. Khách bookmark khach.vn (không www) vẫn thấy trang “domain mới mua” của nhà đăng ký. Dig www đẹp; dig apex ra IP parking. Sửa apex xong mới bàn giao.
2) Team outsourcing: sửa nhầm panel
NS đã trỏ Cloudflare từ tháng trước. Dev mới vào cPanel hosting cũ, sửa A, screenshot gửi lead. Lead F5 — không đổi. Dig NS vẫn Cloudflare; A trên Cloudflare mới là source of truth. Bài học: luôn dig NS trước khi đụng A/CNAME.
3) “Propagation 48 giờ” thành cái cớ
TTL 300 giây nhưng team chờ 2 ngày vì copy lời khuyên chung. Dig @1.1.1.1 đã thấy IP mới sau vài phút — lỗi thật là cache trình duyệt và còn CNAME www trỏ project staging. Kiểm tra record cụ thể nhanh hơn chờ mù.
Lỗi hay gặp (và cách nghĩ)
| Triệu chứng | Hướng kiểm tra |
|---|---|
| NXDOMAIN | Sai chính tả hostname, hoặc NS/zone chưa có record |
| Vào đúng IP nhưng sai site | Virtual host / sai project trên PaaS — DNS đã đúng |
| Chỉ một mạng thấy bản mới | TTL/cache ISP — so sánh @1.1.1.1 vs DNS máy |
| Mail chết sau khi “fix web” | Đụng nhầm MX/TXT khi dọn zone |
| Cert tên không khớp | DNS trỏ host mới, cert còn host cũ (hoặc thiếu SAN www) |
DNS đúng chỉ là điều kiện cần. Sau đó còn reverse proxy, firewall, và app — nhưng đừng debug app khi A vẫn trỏ máy chủ tuần trước.
Tóm tắt một trang
- A/AAAA: tên → IP
- CNAME: tên → tên (không kèm A trên cùng label)
- NS: quyết định panel nào là thật
- Kiểm tra bằng dig/nslookup/DNS check, không bằng cảm giác F5
- Checklist bàn giao liệt kê từng hostname (apex, www, api…)
Khi cần nhìn nhanh A/CNAME/MX/TXT không mở terminal: dùng DNS Record Check trên Kawa (chạy trên trình duyệt, DNS over HTTPS).