DNS記錄類型列表
外觀
此條目翻譯自英語維基百科,需要相關領域的編者協助校對翻譯。 |
本網域名稱系統記錄類型列表提供網域名稱系統(DNS)記錄類型(數據庫記錄)的概覽,而這些記錄都是存儲在網域名稱系統(DNS)的區域文件(zone files)。
網域名稱系統實現將域名和IP 位址相互對映的一個分散式數據庫,能夠使人更方便的存取互聯網。在這些域名伺服器,不同的記錄類型有著不同的用途。
記錄類型
[編輯]代碼 | 號碼 | 定義的 RFC | 描述 | 功能 |
---|---|---|---|---|
A | 1 | RFC 1035 | IPv4地址記錄 | 傳回一個32位元的IPv4地址,最常用於映射主機名稱到IP地址,但也用於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、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。 |
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 | 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 記錄不包含的域名級別的人類可讀信息。
更多有關資訊
[編輯]- IANA DNS Parameters registry. [2008-05-25]. (原始內容存檔於2008-05-13)..
參考資料
[編輯]- ^ 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