DNS là gì? DNS (Domain Name System, hệ thống tên miền) là danh bạ phân cấp của internet: máy chủ DNS giữ các dòng dữ liệu gọi là bản ghi, và mỗi dòng đổi một tên miền như example.com thành thứ máy tính cần. Bản ghi A cho địa chỉ IP (Internet Protocol) của máy chủ web, bản ghi MX (mail exchanger) cho nơi nhận email, bản ghi TXT (text) chứa văn bản xác minh. Câu “trỏ DNS về đây” nghĩa là vào trang quản lý DNS của tên miền, sửa bản ghi A hoặc CNAME (bản ghi bí danh, canonical name) của website sang địa chỉ nền tảng đưa ra, và để nguyên MX cùng TXT để email chạy tiếp. Riêng tên miền gốc (example.com, ghi là @ trong bảng DNS) không đặt CNAME được theo RFC 1034 và RFC 2181 (tài liệu chuẩn Request for Comments của IETF), nên Netlify yêu cầu bản ghi A hoặc ALIAS (kiểu bản ghi giống CNAME mà nhà cung cấp DNS tự xử lý) ở đó, còn www dùng CNAME.
DNS trả lời một tên miền qua những bước nào
Trình duyệt không tự biết example.com nằm ở đâu, nên nó hỏi một bộ phân giải (resolver). Bài dùng example.com làm ví dụ vì đây là tên miền mà IANA (Internet Assigned Numbers Authority, tổ chức quản lý vùng gốc của DNS) dành riêng để làm ví dụ trong tài liệu (RFC 2606 mục 3), nên ai tra cũng được. Resolver là máy chủ của nhà mạng hoặc của dịch vụ công cộng như 1.1.1.1 (Cloudflare) và 8.8.8.8 (Google). Theo RFC 1034 mục 2.4, resolver là chương trình lấy thông tin từ máy chủ tên (name server, viết tắt NS) thay cho người dùng, còn máy chủ tên giữ dữ liệu của phần cây tên miền mà nó chịu trách nhiệm.
Khi cache chưa có câu trả lời, resolver hỏi từ trên xuống: máy chủ gốc (root) cho biết ai quản lý đuôi .com, máy chủ của .com cho biết ai quản lý example.com, và máy chủ tên của example.com trả bản ghi cần tìm. Lệnh dig +trace chạy đúng chuỗi này, theo man dig là đi theo từng lượt chuyển hướng từ máy chủ gốc và in câu trả lời của mọi máy chủ đã hỏi.
Kết quả của dig @1.1.1.1 +trace +nodnssec example.com A lúc 09:57 ngày 06/11/2026 (giờ Việt Nam):
$ dig @1.1.1.1 +trace +nodnssec example.com A
; <<>> DiG 9.10.6 <<>> @1.1.1.1 +trace +nodnssec example.com A
; (1 server found)
;; global options: +cmd
. 517019 IN NS a.root-servers.net.
. 517019 IN NS b.root-servers.net.
. 517019 IN NS c.root-servers.net.
. 517019 IN NS d.root-servers.net.
. 517019 IN NS e.root-servers.net.
. 517019 IN NS f.root-servers.net.
. 517019 IN NS g.root-servers.net.
. 517019 IN NS h.root-servers.net.
. 517019 IN NS i.root-servers.net.
. 517019 IN NS j.root-servers.net.
. 517019 IN NS k.root-servers.net.
. 517019 IN NS l.root-servers.net.
. 517019 IN NS m.root-servers.net.
;; Received 239 bytes from 1.1.1.1#53(1.1.1.1) in 51 ms
com. 172800 IN NS a.gtld-servers.net.
com. 172800 IN NS b.gtld-servers.net.
com. 172800 IN NS c.gtld-servers.net.
com. 172800 IN NS d.gtld-servers.net.
com. 172800 IN NS e.gtld-servers.net.
com. 172800 IN NS f.gtld-servers.net.
com. 172800 IN NS g.gtld-servers.net.
com. 172800 IN NS h.gtld-servers.net.
com. 172800 IN NS i.gtld-servers.net.
com. 172800 IN NS j.gtld-servers.net.
com. 172800 IN NS k.gtld-servers.net.
com. 172800 IN NS l.gtld-servers.net.
com. 172800 IN NS m.gtld-servers.net.
;; Received 836 bytes from 199.7.83.42#53(l.root-servers.net) in 56 ms
example.com. 172800 IN NS hera.ns.cloudflare.com.
example.com. 172800 IN NS elliott.ns.cloudflare.com.
;; Received 359 bytes from 192.55.83.30#53(m.gtld-servers.net) in 158 ms
example.com. 300 IN A 104.20.23.154
example.com. 300 IN A 172.66.147.243
;; Received 72 bytes from 108.162.195.228#53(elliott.ns.cloudflare.com) in 29 ms
06/11/2026 09:57:26 +0700Mỗi đoạn là câu trả lời của một tầng. Đoạn đầu là danh sách 13 máy chủ gốc (a đến m.root-servers.net) do 1.1.1.1 trả về. Đoạn hai do l.root-servers.net trả: 13 máy chủ tên của .com (a đến m.gtld-servers.net), kèm TTL (time to live, thời gian một bản ghi được giữ trong cache) 172800 giây, tức hai ngày. Đoạn ba do m.gtld-servers.net trả: example.com giao cho hera.ns.cloudflare.com và elliott.ns.cloudflare.com, cũng TTL 172800 giây. Đoạn cuối do elliott.ns.cloudflare.com trả hai bản ghi A với TTL 300 giây.
Hai máy chủ ở đoạn ba chính là nơi giữ bản ghi của tên miền, và chủ tên miền đổi chúng bằng mục nameserver ở nhà đăng ký. Bản ghi A, MX hay TXT chỉ có tác dụng khi được sửa ở đúng nơi đó. Sửa ở một nhà cung cấp mà tên miền không trỏ NS tới thì dig ở đoạn ba vẫn đi về máy chủ cũ.
Đọc từng dòng kết quả của lệnh dig
Lệnh dùng nhiều nhất là dig @1.1.1.1 example.com A: hỏi bộ phân giải 1.1.1.1 các bản ghi A của example.com. Kết quả lúc 09:57 ngày 06/11/2026:
$ dig @1.1.1.1 example.com A
; <<>> DiG 9.10.6 <<>> @1.1.1.1 example.com A
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 48394
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;example.com. IN A
;; ANSWER SECTION:
example.com. 103 IN A 104.20.23.154
example.com. 103 IN A 172.66.147.243
;; Query time: 46 msec
;; SERVER: 1.1.1.1#53(1.1.1.1)
;; WHEN: Fri Nov 06 09:57:26 +07 2026
;; MSG SIZE rcvd: 72Bảng dưới đọc từng phần của output này:
| Phần của output | Giá trị lần chạy này | Ý nghĩa |
|---|---|---|
| status | NOERROR | Truy vấn thành công. NXDOMAIN (mã trả lời số 3, name error trong RFC 1035) nghĩa là tên không tồn tại. |
| flags | qr rd ra ad | qr là câu trả lời, rd là yêu cầu hỏi đệ quy, ra là máy chủ hỗ trợ đệ quy, ad là bộ phân giải coi câu trả lời đã được xác thực bằng DNSSEC (RFC 4035 mục 3.2.3). Máy chủ tên trả lời thẩm quyền thì có thêm cờ aa. |
| ANSWER | 2 | Hai bản ghi A. Một tên có nhiều IP là chuyện bình thường. |
| Cột thứ hai của dòng bản ghi | 103 | TTL còn lại, tính bằng giây: bộ phân giải được giữ câu trả lời này trong cache thêm 103 giây rồi mới hỏi lại. |
| IN A 104.20.23.154 | IN, A, địa chỉ IPv4 | IN là lớp Internet, A là kiểu bản ghi, phần cuối là giá trị. |
| Query time, SERVER | 46 msec, 1.1.1.1 | Thời gian trả lời và máy chủ đã trả lời. |
Hai địa chỉ A của example.com cùng nằm trong dải IP Cloudflare công bố tại cloudflare.com/ips-v4 (104.16.0.0/13 chứa 104.20.23.154, 172.64.0.0/13 chứa 172.66.147.243, tra ngày 06/11/2026), và tên miền cũng dùng máy chủ tên của Cloudflare. Người truy cập example.com vì vậy kết nối tới Cloudflare. Theo tài liệu trạng thái proxy của Cloudflare, bản ghi bật proxy (đám mây cam) trả địa chỉ của Cloudflare thay cho IP máy chủ gốc, nhưng example.com có bật proxy hay không và nội dung gốc nằm ở đâu thì output không cho biết (chưa kiểm).
Muốn biết bản ghi đang lưu ở máy chủ tên là gì, hỏi thẳng máy chủ tên thay vì hỏi bộ phân giải. Hai lệnh dưới hỏi hera.ns.cloudflare.com và 8.8.8.8 cùng một câu, chạy lúc 09:57 ngày 06/11/2026:
$ dig +nocmd @hera.ns.cloudflare.com example.com A +noall +answer
example.com. 300 IN A 172.66.147.243
example.com. 300 IN A 104.20.23.154
$ dig +nocmd @8.8.8.8 example.com A +noall +answer
example.com. 300 IN A 172.66.147.243
example.com. 300 IN A 104.20.23.154Cả hai trả cùng hai địa chỉ với TTL 300, chỉ khác thứ tự dòng. 300 giây là TTL gốc mà chủ tên miền đặt, và mọi con số nhỏ hơn 300 ở bộ phân giải (như 103 ở lần hỏi 1.1.1.1 ở trên) là phần còn lại của lần cache trước.
Con số TTL còn lại nhảy lên xuống giữa các lần hỏi. Hỏi 1.1.1.1 sáu lần cách nhau 5 giây, cùng một tên, mỗi dòng mở đầu bằng giờ chạy (lúc 09:57 ngày 06/11/2026):
$ for i in 1 2 3 4 5 6; do printf '%s ' "$(date +%H:%M:%S)"; dig +nocmd @1.1.1.1 example.com A +noall +answer | head -1; sleep 5; done
09:57:33 example.com. 88 IN A 104.20.23.154
09:57:38 example.com. 128 IN A 104.20.23.154
09:57:43 example.com. 152 IN A 172.66.147.243
09:57:48 example.com. 163 IN A 104.20.23.154
09:57:53 example.com. 94 IN A 104.20.23.154
09:57:58 example.com. 267 IN A 172.66.147.243TTL là 88, 128, 152, 163, 94, 267: không đếm lùi đều theo từng 5 giây mà có lúc còn tăng lên, nghĩa là các lần hỏi rơi vào những bản cache khác nhau sau cùng địa chỉ 1.1.1.1 (cơ chế bên trong chưa kiểm). Hệ quả thực tế: sau khi đổi một bản ghi có TTL 300, chỗ này thấy giá trị mới còn chỗ kia vẫn thấy giá trị cũ tới tối đa 300 giây.
Bản ghi A, AAAA, CNAME, MX, TXT và NS làm việc gì
Mỗi loại bản ghi trả lời một câu hỏi khác nhau về cùng một tên. Cột cuối của bảng là giá trị lấy ngày 06/11/2026 từ example.com và python.org:
| Loại | Trả lời câu hỏi | Giá trị lúc tra |
|---|---|---|
| A | Địa chỉ IPv4 của máy chủ ứng với tên này là gì (RFC 1035: host address). | example.com: 104.20.23.154 và 172.66.147.243 |
| AAAA | Địa chỉ IPv6 của máy chủ là gì. | example.com: 2606:4700:10::ac42:93f3 và 2606:4700:10::6814:179a |
| CNAME | Tên này là bí danh của tên nào (RFC 1035: canonical name for an alias). | www.python.org: dualstack.python.map.fastly.net. |
| MX | Máy nào nhận thư của tên miền; số nhỏ được ưu tiên trước. | example.com: 0 . (không nhận thư); python.org: 50 mail.python.org. |
| TXT | Đoạn văn bản gắn với tên, dùng cho SPF (Sender Policy Framework, danh sách máy được gửi thư) và xác minh sở hữu. | example.com: “v=spf1 -all” |
| NS | Máy chủ tên nào giữ các bản ghi của tên miền. | example.com: hera.ns.cloudflare.com. và elliott.ns.cloudflare.com. |
CNAME khác A ở chỗ nó không chứa IP. Resolver gặp CNAME thì quay lại hỏi tên đích. Kết quả của www.python.org lúc 09:58 ngày 06/11/2026 gồm một dòng CNAME rồi bốn dòng A của tên đích:
$ dig @1.1.1.1 www.python.org A
; <<>> DiG 9.10.6 <<>> @1.1.1.1 www.python.org A
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 18189
;; flags: qr rd ra; QUERY: 1, ANSWER: 5, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;www.python.org. IN A
;; ANSWER SECTION:
www.python.org. 604636 IN CNAME dualstack.python.map.fastly.net.
dualstack.python.map.fastly.net. 17 IN A 151.101.64.223
dualstack.python.map.fastly.net. 17 IN A 151.101.128.223
dualstack.python.map.fastly.net. 17 IN A 151.101.192.223
dualstack.python.map.fastly.net. 17 IN A 151.101.0.223
;; Query time: 43 msec
;; SERVER: 1.1.1.1#53(1.1.1.1)
;; WHEN: Fri Nov 06 09:58:04 +07 2026
;; MSG SIZE rcvd: 152TTL còn lại của dòng CNAME là 604636 giây (gần 7 ngày) còn của bốn dòng A chỉ 17 giây, nên IP phía sau đổi được mà không phải sửa bản ghi www; TTL gốc của bốn dòng A chưa kiểm, vì output chỉ cho phần còn lại. Tên gốc python.org thì không dùng CNAME mà trả thẳng bốn bản ghi A:
$ dig @1.1.1.1 python.org A +noall +answer
; <<>> DiG 9.10.6 <<>> @1.1.1.1 python.org A +noall +answer
; (1 server found)
;; global options: +cmd
python.org. 131 IN A 151.101.192.223
python.org. 131 IN A 151.101.128.223
python.org. 131 IN A 151.101.64.223
python.org. 131 IN A 151.101.0.223Lý do nằm ở luật độc quyền của CNAME. RFC 1034 mục 3.6.2 viết rằng nếu một nút có CNAME thì không có dữ liệu nào khác ở nút đó, để resolver dùng CNAME trong cache mà không phải hỏi lại máy chủ về các loại bản ghi khác. RFC 2181 mục 10.1 làm rõ thêm: một bí danh chỉ có một tên chuẩn, và tên đã là bí danh thì không mang dữ liệu nào khác ngoài các bản ghi DNSSEC.
Tên gốc của một tên miền luôn mang bản ghi NS và SOA (bản ghi đánh dấu khởi đầu của vùng quản lý), và mang thêm MX, TXT khi tên miền khai báo thư, như example.com ở trên. Đặt thêm CNAME vào đó là vi phạm luật này, cho nên Netlify, Cloudflare và các nhà cung cấp DNS khác dùng đường vòng ALIAS, ANAME (tên khác của cùng kiểu bản ghi) hoặc flattening ở tên gốc, phần sau mô tả từng cách.
Bản ghi email cũng chịu luật riêng. RFC 2181 mục 10.3 cấm giá trị của MX và NS là một tên đang là bí danh. Output dưới là MX, TXT và NS của example.com, rồi MX của python.org kèm bản ghi A của máy nhận thư, chạy lúc 09:58 ngày 06/11/2026. example.com còn một dòng TXT nữa là chuỗi xác minh của một dịch vụ, đã lược khỏi output bằng grep để chỉ in dòng SPF:
$ dig +nocmd @1.1.1.1 example.com MX +noall +answer
example.com. 300 IN MX 0 .
$ dig +nocmd @1.1.1.1 example.com TXT +noall +answer | grep spf1
example.com. 300 IN TXT "v=spf1 -all"
$ dig +nocmd @1.1.1.1 example.com NS +noall +answer
example.com. 80051 IN NS hera.ns.cloudflare.com.
example.com. 80051 IN NS elliott.ns.cloudflare.com.
$ dig +nocmd @1.1.1.1 python.org MX +noall +answer
python.org. 60 IN MX 50 mail.python.org.
$ dig +nocmd @1.1.1.1 mail.python.org A +noall +answer
mail.python.org. 82269 IN A 188.166.95.178MX của example.com là 0 ., gọi là null MX: theo RFC 7505 mục 3, tên miền không nhận thư thì công bố đúng một bản ghi MX có số ưu tiên 0 và tên máy là dấu chấm, và không được kèm bản ghi MX nào khác. Dòng TXT v=spf1 -all là SPF (danh sách máy được gửi thư thay mặt tên miền) với một luật duy nhất là all mang dấu trừ, nên kết quả kiểm tra luôn là fail (RFC 7208 mục 4.6.2 và 5.1). RFC 7505 mục 4.2 khuyên tên miền không gửi thư công bố SPF -all như vậy. Với tên miền có nhận thư thì MX phải trỏ vào một tên có bản ghi địa chỉ: MX của python.org là mail.python.org, và mail.python.org có bản ghi A chứ không phải CNAME. RFC 7208 mục 3.2 buộc mỗi tên chỉ có một bản ghi SPF, vì còn hai dòng bắt đầu bằng v=spf1 thì kết quả kiểm tra là permerror (mục 4.5), nên khi thêm nhà cung cấp mail mới phải sửa dòng v=spf1 cũ chứ không thêm dòng thứ hai. Tối đa 10 thuật ngữ gây truy vấn DNS (include, a, mx, ptr, exists, redirect) được tính trong một lần kiểm (mục 4.6.4).
DKIM (chữ ký thư) và DMARC (chính sách xử lý thư giả mạo) cũng được công bố bằng TXT theo hướng dẫn của nhà cung cấp mail; RFC của hai loại này chưa đọc nên bài không nói chi tiết. Cách an toàn là dán nguyên tên và giá trị mà nhà cung cấp đưa.
Trỏ tên miền về Netlify, Cloudflare Pages hay VPS thì tạo bản ghi nào
Bước đầu là hỏi tên miền đang dùng máy chủ tên nào, bằng dig NS tên-miền +short. Bản ghi chỉ có tác dụng ở nơi đó, dù tên miền mua ở nhà đăng ký khác. Nếu muốn chuyển sang DNS của Netlify hay Cloudflare, đổi NS ở nhà đăng ký và chép trước mọi MX, TXT sang nơi mới, vì sau khi đổi, đoạn ba của dig +trace đi về máy chủ mới và bản ghi ở nơi cũ không còn ai hỏi tới.
Bảng dưới là bản ghi cần tạo cho từng việc. Giá trị của Netlify tra ngày 06/11/2026 trên trang cấu hình DNS ngoài của Netlify, và địa chỉ có thể đổi nên cần xem lại trang đó trước khi dán:
| Việc cần làm | Loại bản ghi | Tên (host) | Giá trị |
|---|---|---|---|
| Trỏ website về VPS | A (thêm AAAA nếu VPS có IPv6) | @ và www | IP công cộng của VPS |
| Trỏ www về Netlify | CNAME | www | tên-site.netlify.app, không kèm https:// |
| Trỏ tên gốc về Netlify khi DNS hỗ trợ ALIAS, ANAME hoặc flattened CNAME | ALIAS | @ | apex-loadbalancer.netlify.com |
| Trỏ tên gốc về Netlify khi DNS không hỗ trợ ba kiểu đó | A | @ | 75.2.60.5 |
| Trỏ www về Cloudflare Pages | CNAME | www | tên-dự-án.pages.dev, sau khi thêm domain trong dashboard Pages |
| Trỏ tên gốc về Cloudflare Pages | CNAME do Cloudflare tạo | @ | Tên miền phải là một zone (vùng DNS chứa mọi bản ghi của tên miền) trong Cloudflare, cùng tài khoản với dự án Pages |
| Nhận email | MX | @ | Giữ nguyên giá trị nhà cung cấp mail đưa |
| Cho phép gửi email | TXT (SPF) | @ | Một dòng v=spf1 duy nhất |
| Xác minh sở hữu | TXT hoặc CNAME | Tên nhà cung cấp chỉ định | Chuỗi nhà cung cấp đưa |
Với Netlify, trang tài liệu cấu hình DNS ngoài ghi rằng tên gốc không hỗ trợ CNAME và phải dùng ALIAS, ANAME, flattened CNAME hoặc A, còn thay đổi có thể mất tới một ngày mới lan hết. Bản ghi A 75.2.60.5 là phương án dự phòng, vì trang gọi cấu hình ALIAS là cách bền hơn. Những nền tảng này khác nhau ở giới hạn gói và cách tính tiền, đã so ở bài Netlify là gì và bài giới hạn gói miễn phí của Vercel, Netlify và Cloudflare Pages.
Cloudflare giải quyết cùng chỗ vướng bằng CNAME flattening: máy chủ tên tự tìm IP của tên đích, theo cả chuỗi CNAME qua hai bước trở lên, rồi trả IP đó thay cho bản ghi CNAME, nhờ vậy tên gốc trỏ được tới tên đích. Trang tài liệu nêu ba giới hạn: CNAME sang tài khoản Cloudflare khác bị chặn (lỗi 1014), xác minh của dịch vụ bên thứ ba bằng CNAME có thể hỏng nếu bật flatten cho mọi CNAME, và đích không có A hoặc AAAA thì kết quả rỗng (NODATA), trông như bản ghi chưa lan.
Với Cloudflare Pages, tài liệu tên miền riêng chia hai trường hợp. Tên miền gốc phải là zone Cloudflare cùng tài khoản, và khi nameserver đã trỏ về Cloudflare thì Cloudflare tạo CNAME giúp. Subdomain không cần zone Cloudflare, chỉ cần CNAME tới tên-dự-án.pages.dev ở nhà cung cấp DNS, nhưng phải thêm domain trong dashboard Pages trước, vì CNAME thêm tay mà chưa làm bước đó sẽ không phân giải và có thể trả lỗi 522.
Khi trỏ website mà phải giữ email, làm theo thứ tự sau:
- Chạy
dig NS,dig MXvàdig TXTcho tên miền, lưu output vào một tệp. - Mở trang quản lý DNS ở đúng nơi giữ NS: nếu NS ở bước một là *.ns.cloudflare.com thì đó là Cloudflare, nếu là NS của nhà đăng ký hay hosting thì đó là bảng DNS trong tài khoản nhà đó.
- Nếu dùng Netlify hoặc Cloudflare Pages, thêm tên miền trong dashboard của nền tảng trước.
- Sửa hoặc thêm bản ghi A hay CNAME của @ và www theo bảng ở trên.
- Giữ nguyên mọi dòng MX và TXT.
- Chạy lại
dig @máy-chủ-tên tên-miền Ađể xem bản ghi đã lưu, sau đódig @1.1.1.1 tên-miền Ađể xem phía người dùng.
Nếu website là WordPress và định tách phần giao diện ra nền tảng khác, bài chuyển WordPress sang headless mà giữ link và tín hiệu SEO nói thêm về phần địa chỉ. Còn khi bản thử dựng bằng công cụ AI cần chạy thật, bài từ vibe coding lên hệ thống chạy thật liệt kê các việc phải làm, trong đó có tên miền và máy chủ.
Lỗi hay gặp khi trỏ DNS và cách kiểm từng lỗi
Đổi bản ghi rồi mà vẫn thấy IP cũ
Triệu chứng là dig hoặc trình duyệt vẫn ra địa chỉ cũ sau khi đã lưu bản ghi mới. Nguyên nhân là cache còn giữ giá trị cũ trong thời gian TTL, như bảng TTL ở trên cho thấy các bản cache khác nhau hết hạn lệch nhau. Cách kiểm là hỏi thẳng máy chủ tên bằng dig @hera.ns.cloudflare.com tên-miền A, thay hera bằng NS của tên miền, rồi so với dig @1.1.1.1 tên-miền A. Máy chủ tên đã ra giá trị mới mà 1.1.1.1 còn ra giá trị cũ thì chỉ cần chờ hết TTL.
Nếu máy chủ tên vẫn ra giá trị cũ, bản ghi đã được lưu ở nhà cung cấp mà tên miền không trỏ NS tới, và cần sửa ở nơi đúng. Cách làm thông thường, suy ra từ định nghĩa TTL, là hạ TTL xuống 300 giây trước ngày chuyển ít nhất một TTL cũ, rồi mới đổi bản ghi.
Xoá nhầm MX làm email ngừng nhận thư
Triệu chứng là thư gửi tới tên miền không vào hộp thư sau khi chuyển website. Nguyên nhân hay gặp là đổi nameserver sang nhà cung cấp mới mà không chép MX và TXT, hoặc xoá toàn bộ bản ghi cũ cho gọn. Cách kiểm là chạy dig MX tên-miền +short: không có dòng nào, hoặc dòng không phải máy nhận thư của nhà cung cấp mail, là lỗi. Cách sửa là tạo lại MX và SPF đúng như tệp output đã lưu ở bước một của danh sách trên, vì đó là lý do cần lưu trước khi sửa.
Đặt CNAME ở tên miền gốc
Triệu chứng là giao diện DNS báo lỗi khi thêm CNAME cho @, hoặc email của tên miền hỏng sau khi thêm. Nguyên nhân là luật độc quyền của CNAME trong RFC 1034 mục 3.6.2 và RFC 2181 mục 10.1: tên gốc đã có NS, SOA, và MX, TXT nếu có email, nên CNAME không đứng cùng được. Cách sửa là dùng bản ghi A tới IP của nền tảng, hoặc ALIAS, ANAME, flattening nếu nhà cung cấp DNS có. Giao diện của từng nhà cung cấp xử lý yêu cầu này theo cách riêng (chặn, báo lỗi hay xoá bản ghi khác) mà bài chưa kiểm.
Hỏi đáp
DNS khác tên miền chỗ nào?
Tên miền là cái tên đăng ký ở nhà đăng ký, còn DNS là hệ thống giữ các bản ghi gắn với cái tên đó. Mua tên miền xong website chưa chạy vì chưa có bản ghi A hoặc CNAME nào trỏ tới máy chủ.
Bản ghi A và CNAME khác nhau chỗ nào?
A đổi tên thành địa chỉ IPv4 ngay trong bản ghi. CNAME đổi tên thành một tên khác, và resolver phải hỏi tiếp tên đó, như www.python.org trỏ tới dualstack.python.map.fastly.net. Tên đã có CNAME thì không được mang bản ghi khác (RFC 1034 mục 3.6.2).
Trỏ DNS mất bao lâu mới có hiệu lực?
Tối đa bằng TTL của bản ghi cũ còn nằm trong cache, 300 giây ở example.com. Trang cấu hình DNS ngoài của Netlify ghi thay đổi có thể mất tới một ngày để lan hết, đó là mức chặn trên mà nhà cung cấp tự nêu.
Trỏ tên miền sang Netlify có làm mất email không?
Không, miễn là chỉ sửa bản ghi A, ALIAS và CNAME của website và giữ nguyên MX, TXT. Email chỉ mất khi chuyển nameserver sang Netlify DNS hoặc Cloudflare mà chưa tạo lại MX và TXT ở nơi mới.
Tên miền gốc có dùng CNAME được không?
Theo RFC 1034 và RFC 2181 thì không. Cloudflare dùng CNAME flattening, tức trả IP của tên đích thay cho CNAME, còn Netlify gọi các kiểu tương tự là ALIAS, ANAME hoặc flattened CNAME, và với nhà cung cấp DNS không có chúng thì dùng bản ghi A.
MONA Software dựng và vận hành phần mềm web cho doanh nghiệp, gồm bước đưa hệ thống lên máy chủ, gắn tên miền và giữ email chạy khi chuyển nền tảng. Phạm vi nằm ở dịch vụ IT, lập trình web app và viết phần mềm theo yêu cầu. Nếu đã trỏ tên miền mà website hoặc email vẫn không lên, gửi output của dig NS, dig MX và dig @1.1.1.1 tên-miền A qua hotline 1900 636 648 để xem đang kẹt ở tầng nào.
