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

這對於需要在同一個IP位址上運行多個服務的情況來說非常方便。若要同時運行文件傳輸服務和Web服務,則可以把ftp.example.comwww.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 服務商(例如 DNSPodNS1)可以忽略該 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). 

外部連結 編輯