Phân Biệt Nameserver, A, AAAA Và CNAME: Sửa Ở Đâu, Điền Gì Để Không Làm Sập Web Và Email?

Phạm vi thực hành: Máy chủ thử nghiệm chạy Ubuntu 24.04 LTS độc lập cùng tên miền phụ lab-cf02.localhost.vn. Chỉ thao tác trên tài sản số thuộc quyền quản lý của bạn. Hồ sơ thực nghiệm bên dưới ghi nhận kết quả tạo bản ghi A, truy vấn Nameserver (NS) và rà soát AAAA/CNAME trên máy LAB-CF-02 ngày 30/09/2026.

Trong bảng điều khiển quản lý tên miền, các thuật ngữ Nameserver, A, AAAA và CNAME thường nằm san sát nhau trong cùng một giao diện, khiến không ít anh em mới vào nghề hoa mắt rồi bấm nhầm. Tai nạn đau thương và phổ biến nhất là: sếp chỉ nhờ trỏ thêm một cái tên miền phụ (subdomain) về VPS mới để chạy thử trang landing page, nhưng cậu nhân viên lại hùng hổ đi đổi luôn cặp Nameserver của tên miền gốc sang tài khoản mới trắng tinh — hậu quả là toàn bộ hệ thống email công ty (bản ghi MX) đang hoạt động bình thường bỗng nhiên biến mất tăm! Bài viết này sẽ giúp bạn nắm chắc bản chất của từng khái niệm thông qua chính thao tác tay thực tế: sửa ở trang nào, điền giá trị gì và kiểm tra ra sao.

Hình dung đơn giản: Ai giữ sổ hộ khẩu, ai ghi dòng chỉ đường?

Tên miền (domain) sinh ra là để con người dễ nhớ, còn máy tính và các bộ định tuyến trên Internet chỉ nói chuyện với nhau bằng những con số địa chỉ IP. Hệ thống phân giải tên miền (DNS) chính là cuốn danh bạ khổng lồ dịch từ tên chữ sang số IP đó.

Để dễ hình dung, bạn hãy tách bạch hai tầng quản lý hoàn toàn khác nhau: Nhà đăng ký tên miền (Domain Registrar) — nơi bạn trả tiền mua tên miền hàng năm — là nơi lưu thông tin khai báo Nameserver, tức là chỉ định xem “đơn vị nào được quyền giữ cuốn sổ danh bạ (Zone file) của tên miền này”. Còn bên trong cuốn sổ danh bạ đó (chẳng hạn đang đặt tại Cloudflare DNS), các dòng A, AAAA và CNAME mới là những dòng ghi chú cụ thể chỉ đường xem “nhánh tên miền nào sẽ đi về địa chỉ máy chủ nào”. Nắm vững bức tranh hai tầng này là bạn đã tránh được 90% các pha xử lý đi vào lòng đất khi cấu hình tên miền.

Sơ đồ phân biệt vai trò của Nameserver (NS) và 3 loại bản ghi A, AAAA, CNAME do localhost.vn biên soạn.

1. Nameserver (NS): Đổi đơn vị nắm quyền quản lý toàn bộ cuốn danh bạ DNS

Thao tác đổi Nameserver được thực hiện tại trang quản lý của nhà đăng ký nơi bạn mua tên miền. Ví dụ, khi bạn muốn chuyển quyền quản lý DNS của tên miền về Cloudflare, Cloudflare sẽ cấp riêng cho tài khoản của bạn một cặp máy chủ tên miền (chẳng hạn arnold.ns.cloudflare.com và penny.ns.cloudflare.com). Một lưu ý nhỏ nhưng rất nhiều người mắc phải: mỗi tài khoản Cloudflare được cấp cặp tên máy chủ khác nhau, tuyệt đối không nhìn ảnh chụp màn hình trên mạng rồi chép nguyên tên máy chủ của người khác vào tên miền của mình!

Vì việc đổi Nameserver tương đương với việc vứt bỏ cuốn sổ danh bạ cũ để chuyển sang dùng cuốn sổ mới, trước khi bấm nút chuyển bạn bắt buộc phải kiểm kê và chép toàn bộ các bản ghi đang sống ở nhà cũ sang nhà mới: từ bản ghi A/AAAA/CNAME của website chính, các subdomain đang chạy, cho tới bộ bản ghi sống còn của hệ thống thư điện tử gồm MX, SPF, DKIM, DMARC và các dòng TXT xác minh dịch vụ. Đồng thời, nếu tên miền đang bật tính năng chữ ký số DNSSEC, bạn phải tắt DNSSEC ở nơi cũ trước khi chuyển Nameserver rồi mới bật lại ở nơi mới, nếu không toàn bộ tên miền sẽ bị báo lỗi phân giải trên diện rộng.

Ngược lại, nếu tên miền của bạn đã sử dụng sẵn Nameserver của Cloudflare và hôm nay bạn chỉ muốn trỏ thêm một subdomain mới (như lab-cf02.localhost.vn) về VPS mới, thì bạn hoàn toàn không đụng chạm gì tới mục Nameserver cả! Hãy dùng lệnh dig NS ten-mien-cua-ban +short để xác nhận xem đơn vị nào đang quản lý DNS rồi vào đúng nơi đó thêm bản ghi là xong.

2. Bản ghi A (Address Record): Nối thẳng tên miền tới một địa chỉ IPv4

Bản ghi A là gương mặt thân quen nhất: nhiệm vụ duy nhất của nó là ánh xạ một tên miền (hoặc subdomain) tới một địa chỉ IPv4 dạng 4 cụm số (như địa chỉ mẫu 203.0.113.10 trong tài liệu hoặc 103.82.26.183 trên máy Lab thật). Trên giao diện quản lý zone của example.com, nếu bạn gõ chữ lab vào ô Name, bạn đang tạo chỉ đường cho lab.example.com; còn nếu bạn gõ ký hiệu @, bạn đang trỏ cho chính tên miền gốc example.com.

Một lỗi rất hay gặp ở người mới là cố nhét cả giao thức http://, số cổng :8080 hoặc đường dẫn thư mục /bai-viet-moi vào ô giá trị của bản ghi A. Hãy nhớ rằng tầng DNS chỉ làm nhiệm vụ giải đáp câu hỏi “Máy chủ mang tên này nằm ở địa chỉ IP nào?” — nó hoàn toàn không biết gì về cổng TCP hay đường dẫn URL bên trong trang web. Nếu bạn muốn chuyển hướng khách truy cập từ đường dẫn /bai-cu sang /bai-moi, đó là công việc của lệnh HTTP Redirect (301/302) bên trong cấu hình NGINX chứ không phải việc của bản ghi A.

Ngoài ra, dù kỹ thuật DNS cho phép bạn tạo nhiều bản ghi A cùng tên trỏ về nhiều IP khác nhau (cơ chế chia tải thô sơ Round-Robin DNS), nhưng khi đang dựng VPS cho website WordPress thông thường, bạn chỉ nên giữ đúng một bản ghi A duy nhất cho mỗi tên miền để luồng truy cập luôn nhất quán và dễ kiểm tra.

Ảnh chụp thực tế bản ghi A của tên miền phụ lab-cf02.localhost.vn trên Cloudflare DNS vào ngày 30/09/2026: ô Content chỉ chứa duy nhất địa chỉ IPv4 103.82.26.183, đặt ở chế độ DNS only và TTL Auto. Bấm vào ảnh để xem rõ chi tiết.

3. Bản ghi AAAA (Quad-A Record): Nối thẳng tên miền tới một địa chỉ IPv6

Bản ghi AAAA (bốn chữ A đứng cạnh nhau vì địa chỉ IPv6 dài gấp bốn lần IPv4) có vai trò y hệt bản ghi A, chỉ khác là ô giá trị của nó nhận một địa chỉ IPv6 dạng chữ và số ngăn cách bởi dấu hai chấm (ví dụ thuộc dải tài liệu 2001:db8::/32). Nguyên tắc thực chiến rất rõ ràng: bạn chỉ tạo bản ghi AAAA khi và chỉ khi VPS của bạn đã được cấp địa chỉ IPv6 công khai (Public IPv6), dịch vụ NGINX bên trong đã được cấu hình lắng nghe trên giao thức IPv6 (listen [::]:80; và listen [::]:443 ssl;) và tường lửa UFW đã mở cổng cho IPv6.

Như chúng tôi đã cảnh báo ở bài trước, rất nhiều sự cố “ma ám” khi chuyển nhà cho website bắt nguồn từ việc quản trị viên chỉ cập nhật bản ghi A (IPv4) sang VPS mới mà quên béng mất một dòng AAAA (IPv6) cũ kỹ vẫn còn đang trỏ về máy chủ cũ! Do các thiết bị di động và trình duyệt đời mới luôn ưu tiên kết nối qua IPv6 trước (cơ chế Happy Eyeballs), việc để sót bản ghi AAAA cũ sẽ đẩy một nửa lượng khách truy cập vào nhầm máy chủ cũ. Và cũng xin lưu ý: địa chỉ IPv6 nội bộ bắt đầu bằng fe80:: (Link-Local) hiện ra khi bạn gõ lệnh ip address trên VPS không phải là địa chỉ IPv6 công cộng trên Internet, tuyệt đối không lấy địa chỉ fe80:: đó điền vào bản ghi AAAA nhé!

Sơ đồ 4 ngộ nhận kinh điển khi thao tác với các bản ghi A, AAAA và CNAME do localhost.vn biên soạn.

4. Bản ghi CNAME (Canonical Name): Tạo tên bí danh trỏ sang một tên miền khác

Khác với A và AAAA luôn chỉ thẳng tới những con số IP, bản ghi CNAME dùng để tạo một “tên bí danh” (alias) trỏ từ một tên miền này sang một tên miền khác — ví dụ kinh điển nhất là trỏ www.example.com về example.com. Nhờ có CNAME, sau này nếu bạn đổi địa chỉ IP của VPS, bạn chỉ cần sửa duy nhất bản ghi A của example.com là nhánh www tự động đi theo mà không cần sửa ở hai nơi.

Tuy nhiên, có 3 sự thật kỹ thuật về CNAME mà bạn bắt buộc phải nhớ kỹ:

• Thứ nhất, CNAME không phải là lệnh chuyển hướng trình duyệt (HTTP Redirect): Khi khách gõ www.example.com, bản ghi CNAME chỉ âm thầm bảo trình duyệt hãy đi lấy địa chỉ IP của example.com để kết nối, còn thanh địa chỉ trên trình duyệt của khách vẫn giữ nguyên chữ www.example.com! Do đó, trên VPS của bạn, cả cấu hình server_name của NGINX lẫn chứng chỉ bảo mật SSL/TLS đều phải khai báo nhận diện cả hai tên (có www và không có www).
• Thứ hai, CNAME tính khí rất “độc tôn”: Khi một nhánh tên miền đã được khai báo là CNAME, nó không chấp nhận đứng chung với bất kỳ bản ghi A, AAAA hay TXT nào khác có cùng tên đó. Chính vì quy tắc này mà ở tên miền gốc (@, nơi bắt buộc phải chứa bản ghi SOA và NS), chuẩn DNS truyền thống không cho phép đặt CNAME trực tiếp (trừ khi bạn dùng tính năng tự động làm phẳng CNAME Flattening của Cloudflare).
• Thứ ba, sự khác biệt thú vị về ký tự đại diện (Wildcard *) giữa chứng chỉ TLS và DNS: Trong chứng chỉ bảo mật TLS/SSL, một chứng chỉ wildcard dạng *.localhost.vn chỉ bảo vệ được đúng một cấp tên miền phụ bên trái (tức là khớp với lab-cf02.localhost.vn, nhưng sẽ báo lỗi bảo mật ngay nếu bạn truy cập vào www.lab-cf02.localhost.vn có hai cấp bên trái — quy định rõ tại RFC 9525, mục 6.3). Ngược lại, trong thế giới DNS, một bản ghi wildcard *.example.com lại có thể phân giải cho cả những tên miền nhiều cấp sâu bên trong như a.b.example.com (nếu nhánh đó chưa có bản ghi cụ thể nào chặn lại, theo tài liệu Cloudflare: Wildcard DNS records). Hiểu rõ sự lệch pha này sẽ giúp bạn không bao giờ bị bất ngờ khi thiết kế tên miền phụ!

Bảng tra cứu nhanh: Muốn làm việc này thì chọn đúng thao tác nào?

Trước khi nhấn nút Save trên bảng điều khiển DNS, hãy dừng lại 5 giây và đối chiếu mục tiêu của bạn với bảng chỉ dẫn thực chiến dưới đây:

Mẹo nhỏ an toàn: hãy luôn chụp lại màn hình danh sách bản ghi trước và sau khi sửa. Nếu làm việc theo nhóm, bạn có thể nhờ đồng nghiệp liếc mắt kiểm tra chéo 4 ô Type, Name, Content, Proxy status trước khi bấm lưu mà không cần phải chia sẻ mật khẩu tài khoản.

Sơ đồ 4 chốt kiểm tra cuối cùng trước khi bấm nút lưu bản ghi DNS do localhost.vn biên soạn.

Cách dùng lệnh dig để kiểm tra tách biệt cả 4 loại bản ghi

Thay vì đoán mò xem bản ghi mình vừa sửa đã ăn chưa, bạn hãy mở Terminal và chạy bộ 4 câu lệnh dig tương ứng với từng loại bản ghi dưới đây (nhớ thay example.com bằng tên miền thực tế của bạn):

dig NS example.com +short
dig lab.example.com A +noall +answer
dig lab.example.com AAAA +noall +answer
dig www.example.com CNAME +noall +answer

Khi đọc kết quả, nếu một câu lệnh trả về trống trơn, bạn hãy thử bỏ cờ +noall +answer (hoặc +short) đi để nhìn toàn bộ phần tiêu đề phản hồi: nếu thấy status: NOERROR, ANSWER: 0 thì nghĩa là tên miền hoạt động bình thường nhưng hiện chưa có bản ghi thuộc loại bạn vừa hỏi; còn nếu thấy status: NXDOMAIN thì nghĩa là cái tên miền phụ đó hoàn toàn chưa tồn tại trên hệ thống DNS. Và xin nhắc lại: nếu bạn bật đám mây vàng (Proxy) trên Cloudflare cho một bản ghi CNAME hoặc A, thì khi hỏi từ ngoài Internet, Cloudflare sẽ tự động trả về các địa chỉ IP Proxy của Cloudflare để bảo vệ máy chủ gốc của bạn.

Nếu chẳng may gõ nhầm địa chỉ IP hoặc xóa nhầm bản ghi, bạn chỉ cần bình tĩnh mở lại bức ảnh chụp màn hình ban đầu để khôi phục lại đúng giá trị cũ, sau đó chờ khoảng thời gian bằng con số TTL để các bộ nhớ đệm trên mạng tự làm mới. Trong trường hợp bạn đang chuyển đổi cặp Nameserver giữa hai nhà cung cấp, hãy giữ nguyên các bản ghi ở nhà cung cấp DNS cũ thêm ít nhất 24–48 giờ để đảm bảo không một khách hàng nào bị rớt mạng trong thời gian chờ đồng bộ toàn cầu.

Hồ sơ thực nghiệm đối chiếu bản ghi A, NS, AAAA và CNAME trên LAB-CF-02

Trong biên bản thực nghiệm lúc 22:48 ngày 30/09/2026 (UTC+7), kết quả truy vấn cho thấy cặp Nameserver (NS) đang giữ quyền quản lý cho tên miền gốc localhost.vn chính là arnold.ns.cloudflare.com và penny.ns.cloudflare.com. Khi hỏi trực tiếp hai máy chủ gốc này về bản ghi A của tên miền phụ lab-cf02.localhost.vn, cả hai đều trả lời dõng dạc với cờ thẩm quyền aa là địa chỉ 103.82.26.183 kèm TTL 300 giây. Các bộ phân giải trung gian gồm 127.0.0.53, 1.1.1.1 và 8.8.8.8 cũng đồng bộ kết quả tương tự.

Khi chạy lệnh hỏi tiếp bản ghi AAAA và CNAME trên cùng tên miền phụ lab-cf02.localhost.vn, hệ thống trả về rõ ràng NOERROR, ANSWER: 0 — xác nhận nhánh thực hành này chỉ sử dụng duy nhất một bản ghi A thuần túy, hoàn toàn không tạo thêm IPv6 hay bí danh CNAME. Sau khi hoàn tất cấu hình Virtual Host và chứng chỉ bảo mật, phép thử curl --resolve lúc 23:33 (UTC+7) cũng xác nhận cổng 80 chuyển hướng HTTP 301 sang cổng 443 và trả về đúng bài viết thử nghiệm qua kết nối TLS chuẩn.

Đọc hiểu sự khác biệt giữa bản ghi A và NS ngay trên ảnh chụp Console

Bức ảnh chụp màn hình Console lúc 09:25:59 ngày 01/10/2026 (UTC+7) dưới đây đặt cạnh nhau hai câu lệnh để bạn thấy rõ sự phân tầng: câu lệnh đầu hỏi bản ghi A của nhánh con lab-cf02.localhost.vn trả về địa chỉ IP của VPS là 103.82.26.183 (với TTL 300, NOERROR); câu lệnh tiếp theo hỏi bản ghi NS của tên miền gốc localhost.vn trả về cặp máy chủ penny.ns.cloudflare.com và arnold.ns.cloudflare.com. Ở phần cuối ảnh, lệnh nslookup hỏi qua máy chủ phân giải trung gian 1.1.1.1 cũng trả về đúng IP đó kèm dòng chữ Non-authoritative answer quen thuộc.

Ảnh chụp thực tế màn hình Console trên máy chủ Ubuntu LAB-CF-02 lúc 09:25:59 ngày 01/10/2026 (UTC+7), đặt song song kết quả truy vấn bản ghi A của subdomain và bản ghi NS của domain gốc. Bấm vào ảnh để xem bản gốc sắc nét.

Đọc hiểu cờ thẩm quyền aa (Authoritative) và phản hồi trống của AAAA/CNAME

Trong bức ảnh chụp Console thứ hai lúc 09:32:16 ngày 01/10/2026 (UTC+7), câu lệnh dig hỏi trực tiếp máy chủ penny.ns.cloudflare.com (162.159.38.124) xuất hiện rõ cờ aa trong hàng flags, trả về 1 câu trả lời cho bản ghi A là 103.82.26.183 với TTL 300. Ngay bên dưới, hai câu lệnh hỏi bản ghi AAAA và CNAME thông qua bộ phân giải cục bộ 127.0.0.53 đều hiển thị rõ status: NOERROR đi kèm ANSWER: 0.

Ảnh chụp màn hình Console lúc 09:32:16 ngày 01/10/2026 (UTC+7), minh họa trực quan phản hồi Authoritative của bản ghi A và kết quả NOERROR / 0 answer khi tên miền không có bản ghi AAAA hay CNAME. Bấm vào ảnh để phóng to.

Câu hỏi thường gặp (FAQ)

Dùng bản ghi CNAME có làm trang web tải chậm hơn hay nhanh hơn so với bản ghi A không? Trên lý thuyết, nếu trình duyệt hỏi một bản ghi CNAME trỏ sang một tên miền ở tận đẩu tận đâu, nó sẽ mất thêm một nhịp tra cứu DNS nữa để tìm ra số IP cuối cùng. Tuy nhiên, nếu cả CNAME (như www.domain.com) và bản ghi đích (domain.com) đều nằm chung trong một Zone (nhất là trên Cloudflare), máy chủ DNS sẽ trả lời gộp cả hai chỉ trong một lần hỏi duy nhất, nên tốc độ thực tế gần như không có bất kỳ sự khác biệt nào!

Nếu tôi lỡ tay xóa nhầm bản ghi A trên Cloudflare thì mã nguồn WordPress và cơ sở dữ liệu trên VPS có bị mất không? Không hề mất một byte nào! Việc xóa bản ghi DNS chỉ giống như việc bạn gỡ mất tấm biển chỉ đường ngoài đầu ngõ: khách đi đường không biết lối rẽ vào nhà bạn nữa, nhưng ngôi nhà và toàn bộ đồ đạc bên trong VPS vẫn nằm nguyên vẹn. Bạn chỉ cần tạo lại dòng bản ghi A trỏ về đúng IP của VPS là website lại hoạt động bình thường.

Hệ thống DNS có tới hàng chục loại bản ghi, tôi có cần học thuộc lòng hết không? Không cần đâu! Để tự tay dựng và vận hành trọn vẹn một máy chủ website WordPress, bạn chỉ cần nắm thật chắc 4 cái tên trong bài viết này (NS, A, AAAA, CNAME) cộng thêm bản ghi TXT (dùng khi xác minh tên miền hoặc cấu hình chống giả mạo email) và MX (chỉ định máy chủ nhận email). Khi nào dùng tới dịch vụ mở rộng nào thì đọc hướng dẫn cấu hình của đúng dịch vụ đó là đủ.

Tài liệu tham khảo và chặng tiếp theo

Bộ tài liệu chuẩn quốc tế đã được chúng tôi rà soát vào ngày 30/09/2026 bao gồm: Cloudflare: Các loại bản ghi DNS thông dụng, NGINX: Quy tắc khớp tên miền trong server_name, đặc tả RFC 9525: Quy tắc khớp tên miền trong chứng chỉ bảo mật TLS và tài liệu Cloudflare: Cách hoạt động của Wildcard DNS.

Bạn có thể theo dõi toàn bộ các bài viết trong lộ trình cài đặt WordPress trên VPS từ A đến Z. Sau khi đã phân biệt rành mạch từng loại bản ghi, mời bạn bước sang bài tiếp theo để làm chủ bộ công cụ chẩn đoán DNS từ dòng lệnh: Cách dùng dig hoặc nslookup để kiểm tra bản ghi DNS và thời gian lưu đệm TTL.