跳转到内容

DNS记录类型列表

本页使用了标题或全文手工转换
维基百科，自由的百科全书

本網域名稱系統記錄類型列表提供網域名稱系統（DNS）記錄類型（數據庫記錄）的概覽，而這些記錄都是存儲在網域名稱系統（DNS）的區域文件（zone files）。

網域名稱系統實現將域名和IP 位址相互對映的一個分散式數據庫，能夠使人更方便的存取互聯網。在這些域名伺服器，不同的記錄類型有著不同的用途。

記錄類型

代碼 號碼 定義的 RFC 描述 功能
A		 1 RFC 1035 IPv4地址記錄 傳回一個32位元的IPv4地址，最常用於映射主機名稱到IP地址，但也用於DNSBL（英语：DNSBL）（RFC 1101）等。
AAAA		 28 RFC 3596 IPv6地址記錄 傳回一個128位元的IPv6地址，最常用於映射主機名稱到IP地址。
AFSDB		 18 RFC 1183 AFS檔案系統 （Andrew File System）資料庫核心的位置，於域名以外的 AFS 客戶端常用來聯繫 AFS 核心。這個記錄的子類型是被過時的的 DCE/DFS（DCE Distributed File System）所使用。
APL		 42 RFC 3123 地址字首列表 指定地址列表的範圍，例如：CIDR 格式為各個類型的地址（試驗性）。
CAA 257 RFC 6844 权威认证授权 DNS认证机构授权，限制主机/域的可接受的CA
CDNSKEY 60 RFC 7344 子關鍵記錄 關鍵記錄记录的子版本，用于转移到父级
CDS 59 RFC 7344 子委託簽發者 委託簽發者记录的子版本，用于转移到父级
CERT		 37 RFC 4398 憑證記錄 儲存 PKIX、SPKI（英语：SPKI）、PGP等。
CNAME		 5 RFC 1035 規範名稱記錄 一個主機名字的別名：網域名稱系統將會繼續嘗試查找新的名字。
DHCID		 49 RFC 4701 DHCP（動態主機設定協定）識別碼 用於將 FQDN 選項結合至 DHCP。
DLV		 32769 RFC 4431 DNSSEC（域名系統安全擴展）來源驗證記錄 為不在DNS委託者內發佈DNSSEC的信任錨點，與 DS 記錄使用相同的格式，RFC 5074 介紹了如何使用這些記錄。
DNAME		 39 RFC 2672 代表名稱 DNAME 會為名稱和其子名稱產生別名，與 CNAME 不同，在其標籤別名不會重覆。但與 CNAME 記錄相同的是，DNS將會繼續嘗試查找新的名字。
DNSKEY		 48 RFC 4034 DNSSEC所用公钥記錄 於DNSSEC內使用的公钥，與 KEY 使用相同格式。
DS		 43 RFC 4034 委託簽發者 包含DNSKEY的散列值，此記錄用於鑑定DNSSEC已授權區域的簽名密鑰。
HIP		 55 RFC 5205 主機鑑定協定 將端點標識符及IP 地址定位的分開的方法。
HTTPS		 65 RFC 9460 绑定HTTPS 与建立HTTPS连接相关的记录。详见DNSOP工作组和阿卡迈科技发布的草案。
IPSECKEY		 45 RFC 4025 IPSEC 密鑰 與 IPSEC 同時使用的密鑰記錄。
KEY		 25 RFC 2535[1]RFC 2930[2] 密钥記錄 只用於 SIG(0)（RFC 2931）及 TKEY（RFC 2930）。[3]RFC 3455 否定其作為應用程序鍵及限制DNSSEC的使用。[4]RFC 3755 指定了 DNSKEY 作為DNSSEC的代替。[5]
LOC記錄（LOC record） 29 RFC 1876 位置記錄 將一個域名指定地理位置。
MX記錄（MX record） 15 RFC 1035 電郵交互記錄 引導域名到該域名的郵件傳輸代理（MTA, Message Transfer Agents）列表。
NAPTR記錄（NAPTR record） 35 RFC 3403 命名管理指標 允許基於正則表達式的域名重寫使其能夠作為 URI、進一步域名查找等。
NS		 2 RFC 1035 名稱伺服器記錄 委託DNS區域（DNS zone）使用已提供的權威域名伺服器。
NSEC		 47 RFC 4034 下一个安全記錄 DNSSEC 的一部份 — 用來表示特定域名的记录并不存在，使用與 NXT（已過時）記錄的格式。
NSEC3		 50 RFC 5155 下一个安全记录第三版 DNSSEC 的一部份 — 用來表示特定域名的记录并不存在。
NSEC3PARAM		 51 RFC 5155 NSEC3 參數 與 NSEC3 同時使用的參數記錄。
OPENPGPKEY 61 RFC 7929 OpenPGP公钥记录 基于DNS的域名实体认证方法，用于使用OPENPGPKEY DNS资源记录在特定电子邮件地址的DNS中发布和定位OpenPGP公钥。
PTR		 12 RFC 1035 指標記錄 引導至一個規範名稱（Canonical Name）。與 CNAME 記錄不同，DNS「不會」進行處理程序，只會傳回名稱。最常用來執行反向DNS查找，其他用途包括引作 DNS-SD（英语：Zero_configuration_networking#Apple.27s_protocol:_Multicast_DNS.2FDNS-SD）。
RRSIG		 46 RFC 4034 DNSSEC 憑證 用于DNSSEC，存放某记录的签名，與 SIG 記錄使用相同的格式。
RP		 17 RFC 1183 負責人 有關域名負責人的資訊，電郵地址的 @ 通常寫為 a。
SIG		 24 RFC 2535 憑證 SIG(0)（RFC 2931）及 TKEY（RFC 2930）使用的憑證。[5]RFC 3755 designated RRSIG as the replacement for SIG for use within DNSSEC.[5]
SOA		 6 RFC 1035 權威記錄的起始 指定有關DNS區域的權威性資訊，包含主要名稱伺服器、域名管理員的電郵地址、域名的流水式編號、和幾個有關刷新區域的定時器。
SPF 99 RFC 4408 SPF 記錄 作為 SPF 協議的一部分，優先作為先前在 TXT 存儲 SPF 數據的臨時做法，使用與先前在 TXT 存儲的格式。
SRV記錄（SRV record） 33 RFC 2782 服務定位器 廣義為服務定位記錄，被新式協議使用而避免產生特定協議的記錄，例如：MX 記錄。
SSHFP		 44 RFC 4255 SSH 公共密鑰指紋 DNS 系統用來發佈 SSH 公共密鑰指紋的資源記錄，以用作輔助驗證伺服器的真實性。
TA		 32768 無 DNSSEC 可信权威 DNSSEC 一部份無簽訂 DNS 根目錄的部署提案，使用與 DS 記錄相同的格式[6][7]。
TKEY記錄（TKEY record）		 249 RFC 2930 秘密密鑰記錄 為TSIG提供密鑰材料的其中一類方法，that is 在公共密鑰下加密的 accompanying KEY RR。[8]
TSIG		 250 RFC 2845 交易憑證 用以認證動態更新（Dynamic DNS）是來自合法的用戶端，或與 DNSSEC 一樣是驗證回應是否來自合法的遞歸名稱伺服器。[9]
TXT		 16 RFC 1035 文本記錄 最初是為任意可讀的文本 DNS 記錄。自1990年起，些記錄更經常地帶有機讀數據，以 RFC 1464 指定：机会性加密（opportunistic encryption）、Sender Policy Framework（雖然這個臨時使用的 TXT 記錄在 SPF 記錄推出後不被推薦）、DomainKeys、DNS-SD等。
URI 256 RFC 7553 统一资源标识符 可用于发布从主机名到URI的映射。

其他類型及偽資源記錄

其他類型的資源記錄簡單地提供一些類型的訊息（如：HINFO 記錄提供電腦或作業系統的類型），或傳回實驗中之功能的數據。「type」欄位也使用於其他協議作各種操作。

代碼 號碼 定義的 RFC 描述 功能
* 255 RFC 1035 所有緩存的記錄 傳回所有伺服器已知類型的記錄。如果伺服器未有任何關於名稱的記錄，該請求將被轉發。而傳回的記錄未必完全完成，例如：當一個名稱有 A 及 MX 類型的記錄時，但伺服器已緩存了 A 記錄，就只有 A 記錄會被傳回。
AXFR（英语：AXFR） 252 RFC 1035 全域轉移 由主域名伺服器轉移整個區域文件至二級域名伺服器。
IXFR		 251 RFC 1995 增量區域轉移 請求只有與先前流水式編號不同的特定區域的區域轉移。此請求有機會被拒絕，如果權威伺服器由於配置或缺乏必要的資料而無法履行請求，一個完整的（AXFR）會被發送以作回應。
OPT		 41 RFC 2671 選項 這是一個「偽 DNS記錄類型」以支援 EDNS（英语：EDNS）。

過時的記錄類型

發展呈現廢棄一些最初定義的記錄類型。從 IANA 的記錄可見，一些記錄類型由於一些原因而被限制其使用、一些被標示為明顯過時的、有些是為了隱藏的服務、有些是為了舊版本的服務、有的有特別記錄指出它們是「不正確的」。

  • 由 RFC 973 定義為過時：MD(3)、MF (4)、MAILA (254)
  • 為了發佈郵件列表訂戶的 DNS 記錄：MB(7)、MG(8)、MR(9)、MINFO(14)、MAILB (253)。 在 RFC 883 標明的意圖是為了讓 MB 代替 SMTP VRFY 指令、MG 代替 SMTP EXPN 指令、及讓 MR 代替「551 User Not Local」SMTP 錯誤。其後，RFC 2505 提議將 VRFY 及 EXPN 指令兩者停用，使利用 MB 及 MG 永遠不可能獲得通過。
  • 在 RFC 1123 不提議使用「not to be relied upon」（RFC 1127 有更多的資訊）：WKS(11)[10]
  • 錯誤: NB(32)、NBSTAT(33)（自 RFC 1002）；號碼現已分配給 NIMLOC 及 SRV。
  • 由 RFC 1035 定義為過時：NULL(10)（RFC 883 定義「完成查詢」（操作碼二及可能是三）有在使用此記錄，後來 RFC 1035 重新分配操作碼二為「狀態」及保留操作碼三）。
  • 定義為早期的 IPv6 但其後由 RFC 3363 降級為試驗性：A6(38)
  • 由 DNSSEC 更新（RFC 3755） 定義為過時：NXT(30)。同一時間，為 KEY 及 SIG 域名的適用性限制為不包括 DNSSEC。
  • 第一版 DNSSEC（RFC 2230、RFC 2065）的一部份，現已過時：KX(36)
  • 目前沒有任何顯著的應用程序使用：HINFO(13)、RP(17)、X25(19)、ISDN(20)、RT(21)、NSAP(22)、NSAP-PTR(23)、PX(26)、EID(31)、NIMLOC(32)、ATMA(34)、APL(42)
  • 由 Kitchen Sink（页面存档备份，存于互联网档案馆） 互聯網草案（英语：Internet draft），但從未達至 RFC 水平：SINK(40)
  • 一個 LOC 記錄更有限的早期版本：GPOS(27)
  • IANA 保留，及後未有 RFC 記錄它們 [1] 而支援已由 BIND 於九零年初移除：UINFO(100), UID(101)、GID(102)、UNSPEC(103)

RP(17) 可能被使用於有關指定的主機的不同聯絡點、子網域其他 SOA 記錄不包含的域名級別的人類可讀信息。

更多有關資訊

參考資料

  1. ^ RFC 2535, §3
  2. ^ RFC 3445, §1. "The KEY RR was defined in [RFC 2930]..."
  3. ^ RFC 2931, §2.4. "SIG(0) on the other hand, uses public key authentication, where the public keys are stored in DNS as KEY RRs and a private key is stored at the signer."
  4. ^ RFC 3445, §1. "DNSSEC will be the only allowable sub-type for the KEY RR..."
  5. ^ 5.0 5.1 5.2 RFC 3755, §3. "DNSKEY will be the replacement for KEY, with the mnemonic indicating that these keys are not for application use, per [RFC3445]. RRSIG (Resource Record SIGnature) will replace SIG, and NSEC (Next SECure) will replace NXT. These new types completely replace the old types, except that SIG(0) [RFC2931] and TKEY [RFC2930] will continue to use SIG and KEY."
  6. ^ IANA database. [2010-06-15]. （原始内容存档于2010-05-02）. 
  7. ^ Weiler Spec (PDF). [2010-06-15]. （原始内容存档 (PDF)于2011-02-21）. 
  8. ^ RFC 2930, §6. "... the keying material is sent within the key data field of a TKEY RR encrypted under the public key in an accompanying KEY RR [RFC 2535]."
  9. ^ RFC 2845, abstract
  10. ^ RFC 1123 section 2.2, 5.2.12, 6.1.3.6
检索自“https://zh.wikipedia.org/w/index.php?title=DNS记录类型列表&oldid=82345001”