維基百科

CNAME記錄

真實名稱記錄（英語：Canonical Name Record），即CNAME記錄，是域名系統（DNS）的一種記錄。CNAME記錄用於將一個域名（同名）映射到另一個域名（真實名稱），域名解析伺服器遇到CNAME記錄會以映射到的目標重新開始查詢。[1]

這對於需要在同一個IP位址上運行多個服務的情況來說非常方便。若要同時運行文件傳輸服務和Web服務，則可以把ftp.example.com和www.example.com都指向DNS記錄example.com，而後者則有一個指向IP位址的A記錄。如此一來，若伺服器IP位址改變，則只需修改example.com的A記錄即可。

CNAME記錄必須指向另一個域名，而不能是IP位址。

細節

編輯

《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]

DNAME記錄

編輯

DNAME記錄，即代理名稱記錄，由《RFC 6672》定義（原《RFC 2672》已經廢棄）。一條DNAME記錄會將某個域名的整個解析子樹映射到另一域名，而CNAME只映射設定的域名，不映射子域名。如同CNAME一樣，在DNS查詢過程中，會查找所映射到的新域名的地址。域名解析伺服器會為每一個被查詢的子域名生成一則CNAME記錄。為某個域名設置DNAME記錄和為該域名的所有子域名設置CNAME記錄的效果是一樣的。

例如下述記錄： 

foo.example.com.        DNAME  bar.example.com.
bar.example.com.        A      192.0.2.23
xyzzy.bar.example.com.  A      192.0.2.24
*.bar.example.com.      A      192.0.2.25

查詢foo.example.com的A記錄不會返回任何結果。不同於CNAME記錄，DNAME不會直接影響所設置域名的解析。

如果我們需要查詢xyzzy.foo.example.com，則由於DNAME記錄的映射會返回xyzzy.bar.example.com的A記錄，即192.0.2.24。而如果將DNAME記錄換成是CNAME記錄的話，這樣的請求則會報錯提示無法找到。

由此，查詢foobar.foo.example.com會由於DNAME記錄映射返回192.0.2.25。

ANAME記錄

編輯

部分DNS平台支持尚未被標準化的ALIAS[3]或ANAME記錄類型。此類偽記錄由DNS伺服器維護，類似於CNAME記錄，但在（某些）客戶端解析時等同於A記錄。ANAME記錄通常會被設置指向另一域名。但在被客戶端請求時候，則會直接返回對應的IP位址。ANAME記錄的標準化過程正在進行中[4]，但已經有許多不同的實現，所以由於平台的不同，效果也多種多樣。有些存在於域名解析區的頂端，有些則為了提供郵件服務而存在。ANAME記錄相對CNAME記錄的一大優勢是速度。服務端解析A記錄的速度通常比客戶端快，同時可以緩存對應的IP位址以備查詢。IETF正在討論和考慮ANAME記錄的標準化。[5]

參見

編輯

參考資料

編輯
  1. ^ Mockapetris. RFC 1035 - Domain names - implementation and specification. Internet Engineering Task Force. [2019-03-16]. （原始內容存檔於2011-02-12）. 
  2. ^ Bernstein, D.J. CNAME records in mail. [2011-06-03]. （原始內容存檔於2011-12-04）. 
  3. ^ DNS Alias. [2019-06-14]. （原始內容存檔於2019-02-20）. 
  4. ^ IETF DNSOP ANAME Draft by ISC, PowerDNS and DNSimple. [2019-06-14]. （原始內容存檔於2019-07-13）. 
  5. ^ Address-specific DNS Name Redirection (ANAME). 2018-01-11 [2019-06-14]. （原始內容存檔於2019-07-13）. 

外部連結

編輯
取自「https://zh.wikipedia.org/w/index.php?title=CNAME记录&oldid=73214435」