《RFC 1034》詳細定義了CNAME記錄的標準，並在《RFC 2181》的第十節中做了進一步規範。
CNAME記錄在域名系統中的使用有諸多限制。當一個DNS解析伺服器在查詢各類記錄時遇到一則CNAME記錄時，它會立即重啟查詢，查詢所映射到域名的對應記錄。（除非是要查詢CNAME記錄本身，在那種情況下會返回所映射到的域名。）CNAME記錄所映射的域名可以是域名服務中的任何域名。在同一伺服器上，在遠程伺服器上，甚至在屬於不同DNS zone（解析空間）的伺服器上，都可以。
假設有下述DNS zone：
NAME TYPE VALUE
--------------------------------------------------
bar.example.com. CNAME foo.example.com.
foo.example.com. A 192.0.2.23
當要查詢bar.example.com的A記錄時，域名解析器會查到對應的CNAME記錄，即foo.example.com，隨即開始查詢該域名的A記錄，查到192.0.2.23則返回結果。
誤會
編輯
可以使用CNAME記錄將「bar.example.com」指向「foo.example.com」。因此，可能會有人隨意的將bar.example.com稱作是foo.example.com的「CNAME」。然而事實並非如此，bar.example.com的「CNAME」是foo.example.com，因為CNAME的意思是真實名稱，而右側才是真實名稱，才是CNAME。
這則誤會在《RFC 2181》「DNS規範的解釋」一章中有提到。應當說左側標籤是右側真實名稱的一個同名。即下述CNAME記錄：
bar.example.com. CNAME foo.example.com.
應當讀作：
bar.example.com的真實名稱是foo.example.com。請求訪問bar.example.com的客戶端會得到foo.example.com返回的結果。
限制
編輯
CNAME記錄總是指向另一則域名，而非IP位址。
有CNAME記錄的域名不能有其他任何記錄（MX記錄、A記錄等，《RFC 1034》第3.6.2節、《RFC 1912》第 2.4節) 唯一的例外是在使用DNSSEC的情況下，這時可以設置相關的DNSSEC相關記錄，比如RRSIG，NSEC等（《RFC 2181》第10.1節）
為了保證效率，應當避免將CNAME記錄指向其他的CNAME記錄，但並非不可以。因此，可以通過CNAME記錄創造無法被解析的循環，比如：
foo.example.com. CNAME bar.example.com.
bar.example.com. CNAME foo.example.com.
MX記錄和NS記錄永遠都不應指向由CNAME記錄標記的域名（《RFC 2181》第10.3節）。因此，解析空間不應有下述結構：
example.com. MX 0 foo.example.com.
foo.example.com. CNAME host.example.com.
host.example.com. A 192.0.2.1
根據（《RFC1912》）第2.4節，根網域（Root Domain）不應該被添加 CNAME 紀錄。但部分 DNS 服務商（例如 DNSPod、NS1）可以忽略該 RFC 標準而針對根網域做出 CNAME 解析，比如：
example.com. CNAME foo.example.com.
但這樣做會導致該網域若有用於郵箱服務，則可能造成錯誤，詳見如下方。
而願意遵守 RFC 標準的 DNS 供應商 (例如 Neustar UltraDNS、Cloudflare DNS）則採用了 Apex Alias 或 CNAME flattening 技術，這個技術將使得由 DNS 服務商自行處理 CNAME 解析的過程，並將最終解析的 A 紀錄作為實際解析的結果，從而不與 RFC 標準抵觸，比如：
example.com. A 192.0.2.1
用於郵箱服務的域名不應有CNAME記錄。在實踐中，這或許不會出錯，但由於郵件服務的不同，可能會有意料之外的效果。[2]