Công cụ phổ biến

Giao diện

Tra cứu CNAME

Tra cứu CNAME (check CNAME) miễn phí cho mọi tên: lần theo chuỗi CNAME qua từng chặng, hỏi tại chính nameserver của mỗi vùng, với mọi bí danh kèm TTL và máy chủ đã trả lời, nền tảng đứng sau đích và các địa chỉ cuối cùng. Đích mồ côi, vòng lặp và chuỗi quá dài đều được chỉ rõ, kèm cách sửa.

Nguồn: nameserver của chính từng vùng, lần theo từ một máy chủ gốc · Google Public DNS · Cloudflare 1.1.1.1 · Team Cymru

Tra cứu đúng như bạn nhập: www. và tên miền phụ được giữ nguyên, còn IDN được gửi dưới dạng punycode.

Thử

CNAME là gì? Bản ghi CNAME hoạt động thế nào?

Bản ghi CNAME (canonical name, tên chuẩn) biến một tên thành bí danh của một tên khác. Khi hỏi bí danh, DNS trả lời: hãy tra cứu tên kia thay thế. Giá trị luôn là một tên, không bao giờ là địa chỉ IP (RFC 1034 §3.6.2).

Bộ phân giải tự lần theo bí danh và trả về địa chỉ của đích trong cùng một câu trả lời, nên trình duyệt không hề nhận ra. Đó là lý do các nền tảng yêu cầu bạn tạo CNAME: bạn trỏ www tới tên của họ một lần, và họ có thể chuyển máy chủ mà bạn không phải đụng đến DNS của mình.

Nói chính xác, tên chuẩn là đích; gọi bí danh là “một CNAME” chỉ là cách nói tắt phổ biến. Một tên có CNAME không được chứa gì khác và chỉ có một CNAME (RFC 2181 §10.1), nên đỉnh của một vùng, nơi bắt buộc giữ bản ghi SOA và NS, không thể có CNAME (RFC 1034 §4.2.1).

Từng phần của một bản ghi CNAMEwww.microsoft.com · ghi lại ngày 23 thg 10, 2026
www.microsoft.com.Bí danh (chủ sở hữu)3600TTLINLớpCNAMELoạiwww.microsoft.com-c-3.edgekey.net.Tên chuẩn (đích)
Bí danhTên mà mọi người nhập hoặc liên kết tới. Nó chỉ giữ bản ghi này, không có gì khác.
TTL · 1 giờThời gian bộ phân giải được giữ bản ghi này trước khi hỏi lại.
ĐíchNơi cần tìm tiếp: tên edge của Akamai. Luôn là một tên, không bao giờ là địa chỉ.
  1. Bạn tra cứuwww.github.com
  2. CNAME · 1 giờ
  3. Tên chuẩngithub.com
  4. A · 1 phút
  5. Địa chỉ · AS8075 Microsoft20.207.73.82
  • www.github.comCNAMEgithub.comcùng tên miền
  • www.rust-lang.orgCNAMErust-lang.github.ioGitHub Pages
  • www.cursor.comCNAMEcname.vercel-dns.comVercel
  • docs.github.comA185.199.108.154+3 nữakhông có bí danh: địa chỉ riêng
Ghi lại tại nameserver của chính từng vùng. Bộ phân giải hỏi www.github.com nhận được bí danh và địa chỉ của github.com trong cùng một câu trả lời.

Cách kiểm tra bản ghi CNAME (check CNAME)

Nhập tên ở trên và nhấn Tra cứu CNAME: công cụ hỏi nameserver của chính từng vùng qua từng chặng và vẽ ra chuỗi. Trên máy tính, dig làm việc này trong một dòng: hỏi loại A và câu trả lời liệt kê mọi bí danh trước, rồi đến các địa chỉ.

Hỏi loại CNAME để chỉ xem bí danh đầu tiên. Windows có nslookup -type=cname, PowerShell có Resolve-DnsName -Type CNAME, còn host -t cname in ra một câu.

Hai điểm cần lưu ý: bộ phân giải hiển thị phần TTL còn lại trong bộ nhớ đệm của nó, không phải TTL mà vùng đặt, và dig +short bỏ TTL lẫn tên chủ sở hữu, nên chuỗi chỉ in ra như một danh sách trơn.

dig www.example.com A +noall +answer

Mọi bí danh kèm TTL, rồi đến các địa chỉ. +short chỉ in các đích, không có TTL.

dig, có chú thíchwww.nytimes.com qua 8.8.8.8 · 23 thg 10, 2026
bash · dig
$ dig www.nytimes.com A +noall +answer
www.nytimes.com.                  12902IN  CNAME www.prd.map.nytimes.com.3
www.prd.map.nytimes.com.             482   IN  CNAME www.prd.map.nytimes.xovr.nyt.net.
www.prd.map.nytimes.xovr.nyt.net.    260   IN  CNAME nytimes.map.fastly.net.
nytimes.map.fastly.net.               28   IN  A     151.101.1.1644
nytimes.map.fastly.net.               28   IN  A     151.101.129.164
nytimes.map.fastly.net.               28   IN  A     151.101.193.164
nytimes.map.fastly.net.               28   IN  A     151.101.65.164

$ dig www.nytimes.com +short5
www.prd.map.nytimes.com.          # không có TTL, không có tên chủ sở hữu
www.prd.map.nytimes.xovr.nyt.net.
nytimes.map.fastly.net.
151.101.1.164
151.101.129.164
151.101.193.164
151.101.65.164
  1. Tên bạn đã hỏi. Cột đầu tiên của mỗi dòng là chủ sở hữu của bản ghi.
  2. Số giây còn lại trong bộ nhớ đệm của Google: 290 giây trong tổng 600 giây của vùng. Máy chủ của chính vùng hiển thị TTL đầy đủ.
  3. CNAME → tên tiếp theo. Ở đây có 3 bí danh, nên có 3 dòng như thế này.
  4. Các địa chỉ thuộc về tên cuối cùng trong chuỗi: của Fastly, TTL 1 phút tại vùng.
  5. +short ẩn TTL và tên chủ sở hữu: chỉ còn lại các đích và địa chỉ.

Cùng câu hỏi đó trong các công cụ khác

nslookup
$ nslookup -type=cname www.nytimes.com
Non-authoritative answer:
www.nytimes.com	canonical name = www.prd.map.nytimes.com.
PowerShell
PS> Resolve-DnsName www.nytimes.com -Type CNAME
# mỗi bản ghi một dòng: tên, loại, TTL và đích
host
$ host -t cname www.nytimes.com
www.nytimes.com is an alias for www.prd.map.nytimes.com.

nslookup như macOS in ra; Windows trình bày cùng câu trả lời hơi khác một chút.

Cách đọc kết quả

Phần đầu cho biết trong một câu tên dẫn đến đâu và qua bao nhiêu bí danh, kèm logo của nền tảng; các ghi chú bên dưới là những phát hiện quan trọng. Con số đếm các bản ghi CNAME: www.github.com → github.com là 1, không phải 2.

Chế độ xem Chuỗi liệt kê từng bản ghi đúng như máy chủ của chính vùng đã trả lời, kèm vùng, máy chủ, cờ AA và TTL, rồi đến các nhận định: vòng lặp, độ dài, đích bị thiếu, dữ liệu khác nằm cạnh CNAME. Chế độ xem Bản sao đặt bản sao lưu đệm của Google và Cloudflare cho từng bản ghi cạnh bản của vùng. Bên phải, cột màu xanh navy vẽ ra chuỗi: vòng lặp thành một vòng tròn, đích bị thiếu thành một nhánh đứt.

Tra cứu CNAME cho www.nytimes.com: ba bí danh tới Fastly, TTL và vùng của từng bản ghi, cùng chuỗi vẽ đến địa chỉTra cứu CNAME cho www.nytimes.com: ba bí danh tới Fastly, TTL và vùng của từng bản ghi, cùng chuỗi vẽ đến địa chỉKết luậnTên dẫn đến đâu, qua bao nhiêu bí danh, nền tảng và mạng của các địa chỉ.Các bản sao lưu đệmBản sao của Google và Cloudflare cho từng bản ghi, thời gian còn lại của mỗi bản và khi nào một thay đổi ở bản ghi đầu tiên hiển thị.Từng bản ghi, qua từng chặngĐích và TTL đúng như vùng đang giữ, máy chủ đã trả lời, cờ AA và thời gian.ChuỗiTên, từng bí danh kèm vùng và TTL, rồi đến các địa chỉ cuối cùng và mạng của chúng.
Tra cứu CNAME cho www.nytimes.com: kết luận, từng bí danh đúng như máy chủ của vùng đã trả lời, các nhận định và chuỗi được vẽ ở bên phải. Chọn một số để xem từng phần thể hiện điều gì.

CNAME và bản ghi A khác nhau thế nào?

Bản ghi A chứa một địa chỉ: docs.github.com → 185.199.108.154. CNAME chứa một tên: www.github.com → github.com, và địa chỉ đến từ bản ghi A của chính tên đó.

Dùng bản ghi A cho máy chủ của chính bạn và cho tên miền gốc. Dùng CNAME khi một nền tảng đưa cho bạn một tên để trỏ tới (Vercel, GitHub Pages, một CDN, khóa DKIM của một dịch vụ email): khi họ chuyển đi, bản ghi của bạn tự đi theo.

Cái giá là thêm một lượt tra cứu cho mỗi bí danh và các quy tắc nghiêm ngặt: không có gì khác tại tên đó, và không bao giờ ở đỉnh vùng.

Đặt cạnh nhaubản ghi thực tế, ghi lại ngày 23 thg 10, 2026
CNAMEbí danhwww.github.comAđịa chỉdocs.github.com
Trỏ tớimột tên khác: github.commột địa chỉ IPv4: 185.199.108.154
Ở tên miền gốc (example.com)không: đỉnh vùng giữ SOA và NScó
Bản ghi khác tại tênkhông có: không MX, TXT hay A bên cạnhbất kỳ: AAAA, MX, TXT…
Lượt tra cứu thêmmỗi bí danh một lượt: ở đây là 1, với www.nytimes.com là 3không có
Khi host chuyển đitự đi theo đíchbạn tự sửa địa chỉ
Dùng chotên của một nền tảng, CDN, khóa DKIMmáy chủ của chính bạn, tên miền gốc
CNAME: hai bướcwww.github.comgithub.com20.207.73.82
A: một bướcdocs.github.com185.199.108.154

CNAME ở tên miền gốc: ALIAS, ANAME và CNAME flattening

Tên miền gốc (github.com) là đỉnh của vùng, và đỉnh vùng bắt buộc giữ bản ghi SOA và NS của vùng. CNAME không cho phép gì nằm cạnh nó, nên không thể đặt ở đó: hai quy tắc xung đột nhau (RFC 1034 §4.2.1, RFC 2181 §10.1).

Các nhà cung cấp DNS lách quy tắc này trong chính máy chủ của họ: họ tự lần theo đích và trả lời bằng địa chỉ của nó. Cloudflare gọi là CNAME flattening, Route 53 gọi là bản ghi alias, DNSimple và NS1 gọi là ALIAS, DNS Made Easy gọi là ANAME. Bộ phân giải chỉ thấy A và AAAA, nên không lần tra cứu nào cho thấy được bí danh phía sau.

Không có chuẩn ANAME nào: bản dự thảo của IETF đã hết hạn năm 2019. Con đường theo chuẩn là bản ghi HTTPS ở AliasMode (RFC 9460), vốn chỉ được dùng bởi các client hỏi đến nó, nên tên miền gốc vẫn cần bản ghi A.

Vì sao tên miền gốc không thể dùng CNAMEgithub.com · đỉnh vùng của nó, 23 thg 10, 2026

github.com.đỉnh vùng

  • SOAdns1.p08.nsone.net. hostmaster.nsone.net. …
  • NS8 máy chủ: NS1 + Route 53
  • MX github-com.mail.protection.outlook.com.
  • A20.207.73.82
  • CNAMEanything.example.net.

CNAME phải đứng một mình, còn các bản ghi này bắt buộc phải có ở đây: vì vậy không có CNAME ở tên miền gốc.

Những gì nhà cung cấp DNS đưa ra thay thếBộ phân giải thấy

  • Cloudflare · CNAME flatteningbật mặc định ở tên miền gốc, trên mọi góiA · AAAA
  • Amazon Route 53 · bản ghi aliastới tài nguyên AWS hoặc một bản ghi trong cùng vùngA · AAAA
  • DNSimple · ALIAStra cứu đích khi được hỏiA · AAAA
  • NS1 (IBM) · ALIASA · AAAA
  • DNS Made Easy · ANAMEA · AAAA
  • Azure DNS · tập bản ghi aliasA · AAAA
  • bản ghi HTTPS ở AliasMode · RFC 9460chuẩn duy nhất: theo từng dịch vụ, cho các client hỏi đến nóHTTPS
Mọi tính năng của nhà cung cấp đều trả lời bằng địa chỉ thuần, nên không công cụ tra cứu nào thấy được bí danh phía sau.

Chuỗi CNAME, TTL và một thay đổi mất bao lâu

Một bí danh có thể trỏ tới một bí danh khác: www.microsoft.com đi qua hai, www.nytimes.com qua ba. Mỗi bản ghi trong chuỗi có TTL riêng và được lưu đệm riêng, nên các bản sao hết hạn vào những thời điểm khác nhau (RFC 1034 §5.3.3).

Đó là lý do TTL thấp nhất không phải là thời gian chờ. Địa chỉ cuối cùng của Microsoft chỉ sống 20 giây, nhưng một thay đổi ở bản ghi đầu tiên, bản ghi nằm trong chính vùng microsoft.com, phải chờ các bản sao của bản ghi đó: bản của Google còn 37 phút khi chúng tôi kiểm tra, bản của Cloudflare còn gần trọn một giờ, và bất kỳ bộ phân giải nào cũng có thể giữ nó tới một giờ.

Hãy giữ chuỗi ngắn. RFC 9460 khuyến nghị không quá 8 bí danh liên tiếp; BIND và Unbound bỏ cuộc sau 11, PowerDNS sau 10, Knot sau 13. Google và Cloudflare không công bố giới hạn.

Mỗi bản ghi chạy theo đồng hồ riêngwww.microsoft.com · kiểm tra lúc 07:22:26 UTC, 23 thg 10, 2026
  1. www.microsoft.comCNAME → www.microsoft.com-c-3.edgekey.netbản ghi mà chủ sở hữu sửa1 giờTTL tại vùng
    • Googlecòn 36:37 · đến 07:59:03
    • Cloudflarecòn 59:48 · đến 08:22:14

    Một thay đổi ở bản ghi này hiển thị tại Google trước 07:59:03 và tại Cloudflare trước 08:22:14 UTC, tại mọi bộ phân giải trong vòng 1 giờ.

  2. www.microsoft.com-c-3.edgekey.netCNAME → e13678.dscb.akamaiedge.net15 phútTTL tại vùng
    • Googlecòn 6:58 · đến 07:29:24
    • Cloudflarecòn 14:48 · đến 07:37:14
  3. e13678.dscb.akamaiedge.netA 23.2.78.94TTL thấp nhất20 giâyTTL tại vùng
    • Googlecòn 0:20 · đến 07:22:46
    • Cloudflarecòn 0:08 · đến 07:22:34

Giới hạn đã công bố, và chuỗi thực tế

www.github.com1 bí danhwww.microsoft.com2 bí danhwww.nytimes.com3 bí danhwww.apple.com3 bí danh
  • 8 RFC 9460: không khuyến nghị quá 8
  • 10 PowerDNS
  • 11 BIND, Unbound
  • 13 Knot
  • Google, Cloudflare: không công bố
Các thanh: phần còn lại của từng bản sao lưu đệm lúc chúng tôi kiểm tra. Một thay đổi hiển thị khi bản sao của bản ghi bạn đã sửa hết hạn; TTL thấp nhất chỉ cho biết phần đó được lấy lại thường xuyên đến mức nào.

CNAME mồ côi (dangling CNAME) và chiếm quyền tên miền phụ (subdomain takeover)

Một CNAME bị mồ côi (dangling) khi đích của nó không còn nữa: một ứng dụng đám mây đã bị xóa, một bucket đã bị làm trống, một tên miền đã hết hạn. Nếu người khác tạo được tài nguyên mang tên đó, họ sẽ phục vụ tên miền phụ của bạn và thậm chí lấy được chứng chỉ hợp lệ cho nó.

DNS thể hiện điều này bằng câu trả lời NXDOMAIN vẫn mang CNAME của bạn: đích bị thiếu, không phải tên của bạn (RFC 6604 §3). Cách này chỉ dùng được trên các nền tảng cấp cho mỗi tài nguyên một tên DNS riêng. Những nền tảng khác trả lời cho mọi tên, nên một trang đã bị xóa ở đó vẫn phân giải được: khi đó, hãy kiểm tra chính trang web.

Cách sửa là làm đúng thứ tự: xóa bản ghi DNS trước khi xóa tài nguyên, và xác minh tên miền của bạn trên các nền tảng có hỗ trợ việc này. Một đích đã được sửa vẫn có thể trông như bị thiếu trong một thời gian: bộ phân giải giữ câu trả lời phủ định theo giá trị nhỏ hơn giữa TTL của SOA của vùng đích và trường minimum của nó (RFC 2308 §5).

Khi nào NXDOMAIN cho bạn biếthành vi của các nền tảng, kiểm tra ngày 23 thg 10, 2026

Đích bị thiếu trả lời NXDOMAIN

Tên của một tài nguyên đã xóa ngừng phân giải: kết luận của chúng tôi là mồ côi.

  • *.azurewebsites.netApp Service
  • *.trafficmanager.netTraffic Manager
  • *.blob.core.windows.netBlob Storage
  • *.cloudapp.netCloud Services
  • *.elasticbeanstalk.comElastic Beanstalk
  • *.elb.amazonaws.comElastic Load Balancing
  • *.pages.devCloudflare Pages
  • *.edgekey.nettên edge
  • *.map.fastly.nettên map

Nền tảng trả lời mọi tên

Một trang đã xóa vẫn phân giải được: kết luận của chúng tôi là trỏ tới nền tảng: hãy kiểm tra trang vẫn là của bạn.

  • *.github.ioGitHub Pages
  • *.netlify.appNetlify
  • *.herokuapp.comHeroku
  • *.vercel.appVercel
  • *.myshopify.comShopify
  • *.pantheonsite.ioPantheon
  • *.go-vip.netWordPress VIP
  • *.webflow.ioWebflow
  • *.zendesk.comZendesk
  • *.s3.amazonaws.comAmazon S3
  • *.azurefd.netAzure Front Door
  • *.global.ssl.fastly.nettên TLS
Ví dụ giả định · tên theo RFC 2606
$ dig shop.example.com A
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN
;; ANSWER SECTION:     # bản ghi của bạn vẫn ở đó
shop.example.com.   3600  IN  CNAME  example-shop.example.net.
;; AUTHORITY SECTION:  # không có đích này; bộ phân giải có thể giữ kết quả thiếu 5 phút
example.net.         300  IN  SOA    ns1.example.net. …

Bước xác minh quyền sở hữu giúp ngăn chiếm quyền

  • GitHub PagesTXT _github-pages-challenge-<user>.<domain>
  • Azure App ServiceTXT asuid.<subdomain>
  • WebflowTXT _webflow one-time-verification=…
  • Cloudflare for SaaSxác thực hostname, bằng TXT hoặc HTTP
  • Netlifykhóa tên miền, qua bộ phận hỗ trợ
NXDOMAIN mà CNAME của bạn vẫn còn trong câu trả lời nghĩa là đích bị thiếu, không phải tên của bạn.

Cách thêm bản ghi CNAME (GoDaddy, Cloudflare, Namecheap, Squarespace)

Bảng điều khiển DNS nào cũng hỏi cùng ba thứ: loại (CNAME), host và đích mà nền tảng của bạn đưa ra. Trong ô host, chỉ nhập nhãn, www hoặc shop: bảng điều khiển tự thêm tên miền của bạn.

Nhập tên đầy đủ sẽ cho ra www.example.com.example.com, lý do phổ biến nhất khiến một CNAME mới “không hoạt động”. Điều tương tự xảy ra trong zone file, nơi một tên không có dấu chấm cuối là tên tương đối. Trên Cloudflare, bản ghi Proxied ẩn CNAME khỏi các lần tra cứu: hãy đặt nó thành DNS only khi một nền tảng cần xác minh nó.

Rồi kiểm tra tại đây. Các nhà cung cấp đưa ra con số từ một phút đến 72 giờ; thời gian chờ thực sự cho một bản ghi đã thay đổi là TTL của bản ghi cũ, còn một tên hoàn toàn mới thường hiển thị ngay.

Cùng một bản ghi trong bốn bảng điều khiểnô host = chỉ nhãn

GoDaddyĐích từ Shopify

TypeCNAMENamewwwValueshops.myshopify.com

Name: “không bao gồm tên miền như blog hay shop”; không bao giờ dùng @.

CloudflareĐích từ Webflow

TypeCNAMENamewwwTargetcdn.webflow.comProxy statusDNS only

Name: nhập tên miền phụ của bạn. DNS only giữ CNAME hiển thị khi tra cứu; Proxied ẩn nó.

NamecheapĐích từ Google

TypeCNAMEHostwwwValueghs.googlehosted.com

Host: chỉ nhập mysubdomain, không nhập dạng mysubdomain.domain.tld.

SquarespaceĐích từ Framer

TypeCNAMENamewwwDatasites.framer.app

Name: không thể thêm CNAME có @ trong ô Name.

Host đã nhập: www.example.comBảng điều khiển lưu thành www.example.com.example.com: hãy nhập www.

Nhà cung cấp nói gì so với TTL

  • Route 53trong vòng 1 phút, tới các máy chủ của chính họ
  • Namecheap30 phút
  • GoDaddy1 giờ, tối đa 48 giờTTL mặc định 1 giờ
  • Hostingertối đa 24 giờTTL mặc định 4 giờ
  • Squarespace24 giờ đến 48 giờTTL mặc định 4 giờ
  • Ganditối đa 72 giờ

nhà cung cấp nói gìTTL mặc định: bộ phân giải được giữ bản ghi cũ bao lâu

Mỗi đích hiển thị là đích CNAME có trong tài liệu của nền tảng đó. Các thanh dùng cùng một thang giờ; một tên hoàn toàn mới thường hiển thị ngay.

Lỗi 1014 của Cloudflare: CNAME Cross-User Banned

Lỗi 1014 xuất hiện khi một tên trên Cloudflare trỏ, bằng CNAME, tới một tên trong một tài khoản Cloudflare khác. Cloudflare chặn điều này để một khách hàng không thể định tuyến lưu lượng qua thiết lập của khách hàng khác.

Điều này được phép trong cùng một vùng, giữa các vùng của cùng một tài khoản, và qua Cloudflare for SaaS, nơi chủ sở hữu đích thêm tên của bạn làm custom hostname. Đó là cách sửa khi bạn trỏ một tên miền tới một dịch vụ SaaS chạy trên Cloudflare. Nguyên nhân khác: tên miền tùy chỉnh R2 có vùng đang bị tạm giữ, hoặc một vùng bị cấm.

Một lần tra cứu chỉ có thể gợi ý điều này: khi cả hai vùng dùng nameserver của Cloudflare, lỗi 1014 có thể xảy ra nếu chúng ở các tài khoản khác nhau. DNS cho thấy vùng, không bao giờ cho thấy tài khoản, và bản ghi được proxy ẩn chính CNAME, nên chỉ bản ghi DNS only mới hiện ra ở đây.

Hai tài khoản, một CNAMEví dụ giả định · tên theo RFC 2606

Tài khoản A

shop.example.comCNAME → shops.example.net

1014cross-user banned

Tài khoản B

shops.example.netđược proxy · vùng riêng của nhà cung cấp SaaS

  • Cùng vùngwww → example.com
  • Cùng tài khoảnmột vùng → vùng anh em của nó
  • Cloudflare for SaaSchủ sở hữu đích thêm hostname của bạn

Nguyên nhân khác: tên miền tùy chỉnh R2 có vùng đang bị tạm giữ (on hold), hoặc một vùng bị cấm.

Công cụ này nói được gì: khi cả hai vùng trả lời từ *.ns.cloudflare.com, lỗi 1014 có thể xảy ra nếu tài khoản khác nhau. DNS cho thấy vùng, không bao giờ cho thấy tài khoản. Đích *.cdn.cloudflare.net là CNAME setup (một phần) của Cloudflare, không phải SaaS.

CNAME và chuyển hướng (redirect) khác nhau thế nào?

CNAME không phải là chuyển hướng. Nó chỉ cho DNS biết tìm địa chỉ ở đâu; trình duyệt giữ nguyên tên bạn đã nhập trên thanh địa chỉ, gửi tên đó đến máy chủ và chờ một chứng chỉ cho tên đó.

Đó là lý do các nền tảng bắt bạn thêm tên miền ở phía họ nữa: máy chủ của họ phải nhận ra www.example.com và phục vụ chứng chỉ cho nó. CNAME trỏ tới một máy chủ không biết tên của bạn sẽ hiện trang mặc định của máy chủ đó hoặc lỗi chứng chỉ.

Để đưa khách truy cập từ một URL sang URL khác, hãy dùng chuyển hướng HTTP (301 hoặc 308) trên máy chủ web, hoặc tính năng chuyển tiếp (forwarding) của nhà cung cấp DNS, vốn chạy một máy chủ như vậy thay bạn. Công cụ Kiểm Tra Chuyển Hướng hiển thị từng chặng của một chuyển hướng.

Những gì trình duyệt thấyví dụ giả định · tên theo RFC 2606

CNAMEtên giữ nguyên

www.example.com

  • DNS: www.example.com → CNAME sites.example.net → địa chỉ của nó
  • TLS: chứng chỉ phải nêu tên www.example.com
  • HTTP: Host: www.example.com; máy chủ phải biết tên này

301URL thay đổi

www.example.net/

  • DNS: example.com → bản ghi A của một máy chủ web
  • HTTP: 301 Location: https://www.example.net/
  • Trình duyệt: tải URL mới, URL này có lần tra cứu DNS riêng

Tra cứu CNAME: câu hỏi thường gặp

Bản ghi CNAME là gì?

Bản ghi CNAME biến một tên thành bí danh của một tên khác, gọi là tên chuẩn (canonical name). Khi bộ phân giải hỏi bí danh, câu trả lời bảo nó tra cứu đích thay thế, và chính các bản ghi A hoặc AAAA của đích cho ra địa chỉ. Giá trị luôn là một tên, không bao giờ là địa chỉ IP, và một tên có CNAME không được giữ bản ghi nào khác.

Làm sao kiểm tra bản ghi CNAME?

Nhập tên vào công cụ Tra cứu CNAME ở trên: nó hỏi nameserver của chính từng vùng và hiển thị mọi bí danh kèm TTL, nền tảng phía sau và các địa chỉ cuối cùng. Trên máy tính, chạy dig www.example.com CNAME trên macOS hoặc Linux, nslookup -type=cname www.example.com trên Windows, hoặc Resolve-DnsName www.example.com -Type CNAME trong PowerShell.

CNAME và bản ghi A khác nhau thế nào?

Bản ghi A chứa một địa chỉ IPv4; CNAME chứa một tên khác và mượn địa chỉ của tên đó. Dùng bản ghi A ở tên miền gốc và cho máy chủ của chính bạn. Dùng CNAME khi một nền tảng như Vercel, GitHub Pages hay một CDN đưa cho bạn một tên để trỏ tới, để bản ghi của bạn đi theo họ khi họ chuyển máy chủ.

Có thể đặt CNAME ở tên miền gốc không?

Không. Tên miền gốc là đỉnh của vùng, nơi bắt buộc giữ bản ghi SOA và NS, còn CNAME không cho phép bản ghi nào khác nằm cạnh nó. Các nhà cung cấp DNS có cách lách, trả lời bằng địa chỉ thuần: CNAME flattening của Cloudflare, bản ghi alias của Route 53, ALIAS ở DNSimple và NS1, ANAME ở DNS Made Easy. Chuẩn duy nhất là bản ghi HTTPS ở AliasMode.

Vì sao tôi không thấy CNAME của mình?

Bốn lý do thường gặp: bản ghi được Cloudflare proxy hoặc làm phẳng, nên bộ phân giải chỉ thấy địa chỉ của Cloudflare; ô host bị nhập tên đầy đủ, tạo ra www.example.com.example.com; tên vẫn còn bản ghi A, thứ mà CNAME không thể nằm cạnh; hoặc bộ phân giải vẫn giữ câu trả lời cũ cho đến khi TTL hết. Công cụ tra cứu ở trên cho biết nhà cung cấp DNS của vùng, những gì tên đang giữ và thời gian còn lại của từng bản sao.

Thay đổi CNAME mất bao lâu?

Bằng TTL của bản ghi cũ, tính từ lần cuối mỗi bộ phân giải lấy nó. Mỗi bản ghi trong chuỗi được lưu đệm riêng, nên một thay đổi ở CNAME bạn sở hữu phải chờ các bản sao của chính bản ghi đó, kể cả khi địa chỉ cuối cùng có TTL chỉ vài giây. Một tên hoàn toàn mới thường hiển thị ngay, trừ khi có ai đó đã hỏi nó trước khi nó tồn tại.

CNAME mồ côi (dangling CNAME) là gì?

Là CNAME có đích không còn tồn tại: một ứng dụng đám mây đã bị xóa, một bucket đã bị làm trống hoặc một tên miền đã hết hạn. Nếu người khác tạo được tài nguyên mang tên đích đó, họ có thể phục vụ tên miền phụ của bạn. Ở nơi mỗi tài nguyên có tên DNS riêng, tra cứu hiển thị NXDOMAIN với CNAME của bạn vẫn còn trong câu trả lời; hãy xóa bản ghi hoặc trỏ nó tới nơi đang hoạt động.

Có thể nối bao nhiêu CNAME thành chuỗi?

DNS không đặt mức tối đa cố định, nhưng RFC 9460 khuyến nghị không quá 8 bí danh liên tiếp. Các bộ phân giải bỏ cuộc ở giới hạn riêng của chúng: BIND và Unbound sau 11, PowerDNS sau 10, Knot sau 13; Google và Cloudflare không công bố. Chuỗi thực tế đều ngắn: mười hai trang web nổi tiếng mà chúng tôi ghi lại dùng từ 0 đến 3 bí danh.

CNAME có thể trỏ tới địa chỉ IP không?

Không. Giá trị của CNAME phải là một tên host. Khi nhập vào CNAME, một địa chỉ như 192.0.2.1 bị đọc thành một tên gồm bốn nhãn số, tên này không tồn tại, nên bí danh không dẫn đến đâu cả. Để trỏ một tên tới một địa chỉ, hãy dùng bản ghi A cho IPv4 hoặc bản ghi AAAA cho IPv6.

CNAME có giống chuyển hướng (redirect) không?

Không. CNAME chỉ thay đổi nơi DNS tìm địa chỉ; trình duyệt giữ nguyên tên ban đầu trên thanh địa chỉ và hỏi máy chủ về tên đó, nên đích phải chấp nhận tên miền của bạn và có chứng chỉ cho nó. Để đưa khách truy cập sang URL khác, hãy dùng chuyển hướng HTTP 301 hoặc 308 trên máy chủ web, hoặc tính năng chuyển tiếp của nhà cung cấp DNS.

Lỗi 1014 của Cloudflare nghĩa là gì?

CNAME Cross-User Banned: một tên trên Cloudflare trỏ, bằng CNAME, tới một tên trong một tài khoản Cloudflare khác. Việc này được phép trong cùng một vùng, giữa các vùng của một tài khoản, hoặc qua Cloudflare for SaaS, nơi chủ sở hữu đích thêm hostname của bạn. Nếu bạn trỏ tới một dịch vụ SaaS chạy trên Cloudflare, hãy nhờ họ thiết lập tên miền của bạn làm custom hostname.

Vì sao selector DKIM dùng CNAME?

Các dịch vụ email công bố khóa DKIM trong vùng của chính họ và yêu cầu bạn trỏ một selector tới đó, để họ có thể xoay vòng khóa mà không cần bạn giúp. Microsoft 365 dùng selector1 và selector2, SendGrid dùng s1 và s2, Mailchimp dùng k2 và k3. CNAME kết thúc tại một bản ghi TXT, không phải một địa chỉ: chế độ Tên miền phụ phổ biến kiểm tra tất cả.

Còn thiếu điều gì?Đề xuất tính năng hoặc công cụ mới

Công cụ DNS khác