Các loại bản ghi DNS: A, AAAA, CNAME, MX, TXT, SRV, CAA

Vì sao cần

Các loại bản ghi DNS nghe có vẻ là kiến thức nền, nhưng dân kỹ thuật lẫn dân MMO đều từng dính lỗi vì hiểu sai chúng. Trỏ domain xong website vẫn không lên, mail gửi đi rơi thẳng vào spam, hoặc tệ hơn là bị hacker chiếm quyền cấp SSL cho tên miền của bạn.

Hai vấn đề hay gặp nhất:

• Trỏ nhầm loại bản ghi (dùng A thay vì CNAME, hoặc ngược lại) khiến dịch vụ chạy chập chờn, lúc được lúc không.
• Không biết TXT, SRV, CAA dùng để làm gì nên bỏ qua, dẫn đến email bị đánh dấu spam hoặc domain bị cấp chứng chỉ SSL trái phép.

Bài này gom lại các loại bản ghi DNS phổ biến nhất: A, AAAA, CNAME, MX, TXT, SRV, CAA, cùng cách chọn loại phù hợp cho từng tình huống thực tế.

Các loại bản ghi DNS quan trọng nhất

Mỗi bản ghi DNS thực chất là một câu trả lời cho một câu hỏi cụ thể mà trình duyệt, mail server hay ứng dụng đặt ra khi tra cứu domain. Hiểu đúng câu hỏi thì chọn đúng loại bản ghi, không cần học thuộc lòng.

A – domain này trỏ về IPv4 nào

Bản ghi A ánh xạ tên miền sang một địa chỉ IPv4, ví dụ example.com A 203.0.113.10. Đây là loại phổ biến nhất, dùng cho website, VPS, hoặc bất kỳ dịch vụ nào chạy trên một địa chỉ IP cố định.

Nếu server đổi IP, bạn phải cập nhật lại bản ghi A thủ công. Đây cũng là lý do nhiều người dùng CDN hoặc load balancer để tránh phải sửa DNS mỗi lần đổi hạ tầng.

AAAA – domain này trỏ về IPv6 nào

AAAA hoạt động y hệt A nhưng dành cho địa chỉ IPv6, dạng 2606:4700:4700::1111. Nhiều hệ thống hiện đại chạy song song cả A và AAAA để hỗ trợ cả hai chuẩn mạng.

Nếu bạn không có hạ tầng IPv6, bỏ qua AAAA cũng không sao. Đừng tạo bản ghi AAAA trỏ vào IP rác, vì trình duyệt hỗ trợ IPv6 sẽ ưu tiên gọi vào đó trước và bị lỗi kết nối.

CNAME – domain này là bí danh của domain nào khác

CNAME (Canonical Name) không trỏ thẳng vào IP, mà trỏ tên miền này sang một tên miền khác. Ví dụ www.example.com CNAME example.com, hoặc trỏ subdomain vào một dịch vụ SaaS như shop.example.com CNAME shops.myplatform.com.

Ưu điểm là khi IP đích đổi, bạn không cần sửa gì ở phía CNAME. Nhược điểm: CNAME có giới hạn không được đặt tại gốc domain, sẽ nói kỹ ở phần sau.

MX – mail của domain này đi qua server nào

MX (Mail Exchange) khai báo server nhận email cho domain, kèm theo một số ưu tiên (priority). Số càng nhỏ càng được ưu tiên thử trước, ví dụ example.com MX 10 mail1.example.com và example.com MX 20 mail2.example.com.

Thiếu bản ghi MX hoặc khai sai, email gửi đến domain của bạn sẽ bị bounce ngay lập tức. Đây là lỗi cực kỳ phổ biến khi chuyển nhà cung cấp email mà quên cập nhật DNS.

TXT – domain này xác nhận thông tin gì

TXT chứa văn bản tự do, dùng để xác minh quyền sở hữu domain hoặc khai báo chính sách email như SPF, DKIM, DMARC. Ví dụ một dòng SPF: v=spf1 include:_spf.google.com ~all.

Nhiều dịch vụ (Google Search Console, Facebook Business, các nền tảng MMO xác minh landing page) cũng yêu cầu thêm TXT để chứng minh bạn sở hữu domain. Thiếu TXT xác thực SPF/DKIM là nguyên nhân hàng đầu khiến mail marketing rơi vào spam.

SRV – dịch vụ cụ thể này chạy ở đâu, cổng nào

SRV (Service) chỉ định host và port cho một dịch vụ cụ thể, thường dùng cho VoIP, Minecraft server, XMPP, hoặc Microsoft Teams. Cấu trúc gồm service, protocol, priority, weight, port và target, ví dụ _sip._tcp.example.com SRV 10 5 5060 sip.example.com.

Ít người dùng SRV hằng ngày như A hay CNAME, nhưng nếu bạn vận hành game server hoặc hệ thống thoại nội bộ thì đây là bản ghi bắt buộc phải hiểu. Sai một trong năm thông số là dịch vụ không kết nối được.

CAA – ai được phép cấp SSL cho domain này

CAA (Certification Authority Authorization) giới hạn danh sách nhà cấp chứng chỉ (CA) được phép phát hành SSL cho domain của bạn. Ví dụ example.com CAA 0 issue "letsencrypt.org" chỉ cho phép Let’s Encrypt cấp chứng chỉ.

Đây là lớp bảo vệ ít người để ý nhưng rất quan trọng với domain có giá trị cao. Sẽ phân tích kỹ ở mục riêng bên dưới.

Bảng tra nhanh: dùng loại nào cho tình huống nào

Khi cần tra nhanh nên dùng loại bản ghi nào, bảng dưới đây tổng hợp lại các tình huống thực tế thường gặp.

Nếu bạn quản lý nhiều domain cùng lúc, việc lưu sẵn bảng này trong tài liệu nội bộ giúp đội ngũ đỡ hỏi lại nhiều lần. Bạn có thể tham khảo thêm hướng dẫn cấu hình DNS cơ bản để có ví dụ minh họa cụ thể hơn theo từng nhà cung cấp.

TTL: đặt bao nhiêu là hợp lý

TTL (Time To Live) quyết định thời gian bản ghi DNS được cache trước khi resolver hỏi lại. TTL thấp giúp thay đổi có hiệu lực nhanh, nhưng khiến DNS server phải xử lý nhiều truy vấn hơn.

Nguyên tắc chung dễ nhớ:

• Đang chuẩn bị đổi hạ tầng, chuyển hosting: hạ TTL xuống 300 giây (5 phút) trước ít nhất 24 giờ.
• Hệ thống ổn định, ít thay đổi: đặt TTL 3600 đến 86400 giây (1 giờ đến 1 ngày) để giảm tải truy vấn.
• Bản ghi MX và TXT cho SPF/DKIM: nên để TTL trung bình khoảng 3600 giây, tránh thay đổi liên tục vì mail server cache khá lâu.
• Bản ghi NS (name server) của domain: TTL thường cao, 86400 giây trở lên, vì ít khi đổi.

Sau khi hoàn tất thay đổi và xác nhận mọi thứ chạy ổn, bạn nên đưa TTL về mức bình thường (3600 giây trở lên). Giữ TTL quá thấp trong thời gian dài không có lợi, chỉ làm tăng tải không cần thiết cho hệ thống DNS.

CNAME không đặt ở gốc tên miền: vì sao

Đây là quy tắc gây bối rối nhiều nhất trong các loại bản ghi DNS. Theo chuẩn kỹ thuật DNS, bản ghi gốc (root hay apex, ví dụ example.com không có www) không được phép có CNAME nếu domain đó còn tồn tại các bản ghi khác như MX, NS, TXT.

Lý do nằm ở cách resolver hoạt động. CNAME yêu cầu domain đó chỉ được trả lời bằng một bản ghi bí danh duy nhất, trong khi domain gốc gần như luôn cần thêm NS (name server) và thường có cả MX, TXT.

Hai bản ghi này xung đột trực tiếp với ràng buộc của CNAME, nên hầu hết DNS server sẽ từ chối hoặc báo lỗi khi bạn cố tạo. Bạn có thể xem chi tiết kỹ thuật trong tài liệu chuẩn RFC về DNS tại rfc-editor.org nếu muốn hiểu sâu hơn phần đặc tả.

Cách xử lý phổ biến khi cần trỏ domain gốc vào một dịch vụ bên ngoài (như trỏ apex domain vào CDN hoặc nền tảng SaaS):

• Dùng bản ghi A trỏ thẳng vào IP mà nhà cung cấp đưa cho, nếu họ có IP cố định.
• Dùng tính năng “ALIAS” hoặc “ANAME” nếu nhà cung cấp DNS hỗ trợ, đây là giải pháp giả lập hành vi của CNAME nhưng hợp lệ ở gốc domain.
• Chuyển hướng domain gốc sang www bằng redirect ở tầng web server, rồi đặt CNAME cho www.

Nhiều nền tảng lớn như Cloudflare, Route 53 đã hỗ trợ sẵn ALIAS/CNAME flattening để giải quyết đúng vấn đề này. Nếu bạn dùng DNS của nhà đăng ký domain thông thường, kiểm tra kỹ xem họ có hỗ trợ tính năng tương tự không trước khi cố ép CNAME vào gốc.

CAA: chặn nhà cấp chứng chỉ lạ cấp SSL cho miền của bạn

Về mặt mặc định, bất kỳ Certificate Authority (CA) nào được trình duyệt tin tưởng đều có thể cấp SSL cho domain của bạn, miễn là họ xác minh được quyền kiểm soát domain. Điều này nghe an toàn nhưng thực tế mở ra rủi ro: nếu kẻ xấu chiếm được quyền xác minh tạm thời (qua lỗ hổng DNS, email, hoặc cấu hình sai), họ có thể xin cấp SSL hợp lệ cho domain của bạn từ một CA khác.

Bản ghi CAA giải quyết đúng lỗ hổng này bằng cách giới hạn rõ CA nào được phép cấp chứng chỉ. Cú pháp cơ bản gồm ba phần: flag, tag, value.

Ví dụ cấu hình chỉ cho phép Let’s Encrypt:

example.com. CAA 0 issue "letsencrypt.org"
example.com. CAA 0 issuewild "letsencrypt.org"
example.com. CAA 0 iodef "mailto:[email protected]"

Trong đó issue áp dụng cho chứng chỉ thường, issuewild áp dụng riêng cho wildcard certificate, còn iodef khai báo email nhận cảnh báo khi có CA nào cố cấp trái phép. Nếu domain của bạn đang dùng nhiều CA khác nhau (ví dụ vừa Let’s Encrypt vừa DigiCert), bạn cần liệt kê đầy đủ, thiếu một cái là chứng chỉ từ CA đó sẽ bị từ chối phát hành.

Với domain thương mại điện tử, cổng thanh toán, hay các domain MMO có giá trị tài sản cao, thiết lập CAA gần như là bắt buộc. Chi phí thiết lập gần như bằng không, nhưng giảm đáng kể rủi ro bị mạo danh domain qua chứng chỉ SSL giả mạo. Bạn có thể đọc thêm nguyên lý hoạt động của CAA tại Let’s Encrypt để nắm chi tiết cách các CA kiểm tra bản ghi này trước khi cấp chứng chỉ.

Sai lầm phổ biến

• Đặt CNAME cho domain gốc rồi thắc mắc tại sao mail và DNS server báo lỗi liên tục.
• Đổi IP server nhưng quên cập nhật bản ghi A, khiến một phần người dùng vẫn thấy website cũ do cache DNS chưa hết TTL.
• Copy nguyên bản ghi MX từ domain khác mà không đổi priority, dẫn đến mail gửi vòng vòng không tới nơi.
• Bỏ qua TXT SPF/DKIM khi gửi email hàng loạt, khiến toàn bộ chiến dịch rơi vào spam dù nội dung không có vấn đề gì.
• Không cấu hình CAA, để domain quan trọng mở toang cho bất kỳ CA nào cấp chứng chỉ.
• Để TTL quá cao trong lúc đang cần đổi hạ tầng gấp, khiến thay đổi mất nhiều giờ mới lan tỏa hết.

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

A và CNAME khác nhau chỗ nào?
A trỏ thẳng vào một địa chỉ IP, còn CNAME trỏ vào một tên miền khác. Dùng CNAME khi IP đích có thể đổi bất cứ lúc nào và bạn không muốn tự cập nhật DNS mỗi lần.

Vì sao website vẫn lỗi sau khi đã sửa DNS?
Nhiều khả năng do TTL cũ chưa hết hạn, resolver ở phía người dùng vẫn cache bản ghi cũ. Đợi hết thời gian TTL đã đặt trước đó, hoặc kiểm tra bằng công cụ tra cứu DNS trực tuyến để xác nhận giá trị mới đã lan tỏa.

Domain không gửi được mail thì kiểm tra bản ghi nào trước?
Kiểm tra MX trước tiên xem có trỏ đúng server mail không. Sau đó kiểm tra TXT SPF, DKIM, DMARC vì thiếu các bản ghi này khiến mail dễ bị đánh dấu spam dù MX đã đúng.

Có bắt buộc phải dùng AAAA không?
Không bắt buộc nếu hạ tầng của bạn chưa hỗ trợ IPv6. Chỉ tạo AAAA khi bạn thực sự có địa chỉ IPv6 hợp lệ đang chạy dịch vụ.

CAA có ảnh hưởng gì đến SSL đang dùng không?
Không ảnh hưởng đến chứng chỉ đã cấp trước đó. CAA chỉ tác động đến các yêu cầu cấp mới hoặc gia hạn, nên bạn cần đảm bảo CA hiện tại của mình nằm trong danh sách được phép trước khi bật.

SRV có thay thế được CNAME hay A không?
Không, SRV phục vụ mục đích khác, khai báo dịch vụ cụ thể chạy ở host và port nào chứ không thay thế việc phân giải tên miền cơ bản. Hai loại này thường dùng song song với nhau trong cùng một hệ thống.

Tóm tắt nhanh

• A và AAAA trỏ domain vào địa chỉ IPv4/IPv6, dùng cho website và server chạy IP cố định.
• CNAME trỏ domain vào một tên miền khác, không được đặt ở gốc domain vì xung đột với NS, MX.
• MX quyết định mail server nhận email cho domain, sai priority là mail bị bounce hoặc lạc đường.
• TXT dùng để xác minh quyền sở hữu domain và khai báo SPF/DKIM/DMARC chống giả mạo email.
• SRV khai báo host, port cho dịch vụ cụ thể như game server hoặc VoIP.
• CAA giới hạn CA nào được phép cấp SSL cho domain, nên bật cho mọi domain quan trọng.
• TTL nên hạ thấp trước khi đổi hạ tầng và đưa về mức bình thường sau khi ổn định, tham khảo thêm tại vsis.net.