本網域名稱系統記錄類型列表提供網域名稱系統(DNS)記錄類型(數據庫記錄)的概覽,而這些記錄都是存儲在網域名稱系統(DNS)的區域文件(zone files)。
網域名稱系統實現將域名和IP 位址相互對映的一個分散式數據庫,能夠使人更方便的存取互聯網。在這些域名伺服器,不同的記錄類型有著不同的用途。
記錄類型
其他類型及偽資源記錄
其他類型的資源記錄簡單地提供一些類型的訊息(如:HINFO 記錄提供電腦或作業系統的類型),或傳回實驗中之功能的數據。「type」欄位也使用於其他協議作各種操作。
代碼
|
號碼
|
定義的 RFC
|
描述
|
功能
|
* |
255 |
RFC 1035 |
所有緩存的記錄
|
傳回所有伺服器已知類型的記錄。如果伺服器未有任何關於名稱的記錄,該請求將被轉發。而傳回的記錄未必完全完成,例如:當一個名稱有 A 及 MX 類型的記錄時,但伺服器已緩存了 A 記錄,就只有 A 記錄會被傳回。
|
AXFR |
252 |
RFC 1035 |
全域轉移 |
由主域名伺服器轉移整個區域文件至二級域名伺服器。
|
IXFR |
251 |
RFC 1995 |
增量區域轉移
|
請求只有與先前流水式編號不同的特定區域的區域轉移。此請求有機會被拒絕,如果權威伺服器由於配置或缺乏必要的資料而無法履行請求,一個完整的(AXFR)會被發送以作回應。
|
OPT |
41 |
RFC 2671 |
選項
|
這是一個「偽 DNS記錄類型」以支援 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(页面存档备份,存于互联网档案馆) 互聯網草案,但從未達至 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