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 記錄不包含的域名級別的人類可讀信息。

參考資料

^ RFC 2535, §3
^ RFC 3445, §1. "The KEY RR was defined in [RFC 2930]..."
^ 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."
^ RFC 3445, §1. "DNSSEC will be the only allowable sub-type for the KEY RR..."
^ ^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."
^ IANA database. [2010-06-15]. （原始内容存档于2010-05-02）.
^ Weiler Spec (PDF). [2010-06-15]. （原始内容存档 (PDF)于2011-02-21）.
^ 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]."
^ RFC 2845, abstract
^ RFC 1123 section 2.2, 5.2.12, 6.1.3.6

[1] RFC 2535, §3

[rfc3445_sec1_def-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."

[rfc3445_sec1_subtype-4] RFC 3445, §1. "DNSSEC will be the only allowable sub-type for the KEY RR..."

[rfc3755_sec3-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

[1]

[2]

[3]

[4]

[5]

[6]

[7]

[8]

[9]

[10]

DNS记录类型列表

記錄類型

其他類型及偽資源記錄

過時的記錄類型

更多有關資訊

參考資料

Portal di Ensiklopedia Dunia