DNS记录类型列表
外观
此條目翻譯自其他語言維基百科,需要相關領域的編者協助校對翻譯。 |
本網域名稱系統記錄類型列表提供網域名稱系統(DNS)記錄類型(數據庫記錄)的概覽,而這些記錄都是存儲在網域名稱系統(DNS)的區域文件(zone files)。
網域名稱系統實現將域名和IP 位址相互對映的一個分散式數據庫,能夠使人更方便的存取互聯網。在這些域名伺服器,不同的記錄類型有著不同的用途。
如要了解更多有關域名伺服器的資訊,請移至網域名稱系統。
記錄類型
| 代碼 | 號碼 | 定義的 RFC | 描述 | 功能 |
|---|---|---|---|---|
A |
1 | RFC 1035 | IP 地址記錄 | 傳回一個 32 位元的 IPv4 地址,最常用於映射主機名稱到 IP 地址,但也用於 DNSBLs(RFC 1101)等。 |
AAAA |
28 | RFC 3596 | IPv6 IP 地址記錄 | 傳回一個 128 位元的 IPv6 地址,最常用於映射主機名稱到 IP 地址。 |
AFSDB |
18 | RFC 1183 | AFS 檔案系統 | AFS(Andrew File System)資料庫核心的位置,於域名以外的 AFS 客戶端常用來聯繫 AFS 核心。這個記錄的子類型是被過時的的 DCE/DFS(DCE Distributed File System)所使用。 |
APL |
42 | RFC 3123 | 地址字首列表 | 指定地址列表的範圍,例如:CIDR 格式為各個類型的地址(試驗性)。 |
CERT |
37 | RFC 4398 | 憑證記錄 | 儲存 PKIX、SPKI、PGP等。 |
| 5 | RFC 1035 | 規範名稱記錄 | 一個主機名字的別名:網域名稱系統將會繼續嘗試查找新的名字。 | |
DHCID |
49 | RFC 4701 | 動態主機設定協定識別碼 | 用於將 FQDN 選項結合至 DHCP。 |
DLV |
32769 | RFC 4431 | 域名系統安全擴展來源驗證記錄 | 為不在網域名稱系統委託者內發佈域名系統安全擴展的信任錨點,與 DS 記錄使用相同的格式,RFC 5074 介紹了如何使用這些記錄。 |
| 39 | RFC 2672 | 代表名稱 | DNAME 會為名稱和其子名稱產生別名,與 CNAME 不同,在其標籤別名不會重覆。但與 CNAME 記錄相同的是,網域名稱系統將會繼續嘗試查找新的名字。 | |
DNSKEY |
48 | RFC 4034 | DNS 關鍵記錄 | 於域名系統安全擴展內使用的關鍵記錄,與 KEY 使用相同格式。 |
DS |
43 | RFC 4034 | 委託簽發者 | 此記錄用於鑑定域名系統安全擴展(DNSSEC)已授權區域的簽名密鑰。 |
HIP |
55 | RFC 5205 | 主機鑑定協定 | 將端點標識符及IP 地址定位的分開的方法。 |
IPSECKEY |
45 | RFC 4025 | IPSEC 密鑰 | 與 IPSEC 同時使用的密鑰記錄。 |
KEY |
25 | RFC 2535[1] RFC 2930[2] | 關鍵記錄 | 只用於 SIG(0)(RFC 2931)及 TKEY(RFC 2930)。[3] RFC 3455 否定其作為應用程序鍵及限制域名系統安全擴展的使用。[4] RFC 3755 指定了 DNSKEY 作為域名系統安全擴展 的代替。[5] |
| LOC | 29 | RFC 1876 | 位置記錄 | 將一個域名指定地理位置。 |
| MX | 15 | RFC 1035 | 電郵交互記錄 | 引導域名到該域名的郵件傳輸代理(Mail Transfer Agent)列表。 |
| NAPTR | 35 | RFC 3403 | 命名管理指標 | 允許基於正則表達式的域名重寫使其能夠作為 URI、進一步域名查找等。 |
NS |
2 | RFC 1035 | 名稱服務器記錄 | 委託 DNS 區域使用已提供的權威域名伺服器。 |
NSEC |
47 | RFC 4034 | 下一代安全記錄 | DNSSEC 的一部份 — 用來驗證一個未存在的伺服器,使用與 NXT(已過時)記錄的格式。 |
NSEC3 |
50 | RFC 5155 | NSEC 記錄第三版 | 一個用作允許未經允許的區域行走以證明名稱不存在性的 DNSSEC 擴展。 |
NSEC3PARAM |
51 | RFC 5155 | NSEC3 參數 | 與 NSEC3 同時使用的參數記錄。 |
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 | 33 | RFC 2782 | 服務定位器 | 廣義為服務定位記錄,被新式協議使用而避免產生特定協議的記錄,例如:MX 記錄。 |
SSHFP |
44 | RFC 4255 | SSH 公共密鑰指紋 | DNS 系統用來發佈 SSH 公共密鑰指紋的資源記錄,以用作輔助驗證伺服器的真實性。 |
TA |
32768 | 無 | DNSSEC 信任當局 | DNSSEC 一部份無簽訂 DNS 根目錄的部署提案,,使用與 DS 記錄相同的格式,詳細資料請見 IANA database 及 Weiler Spec。 |
| 249 | RFC 2930 | 秘密密鑰記錄 | 為 TSIG 提供密鑰材料的其中一類方法,that is 在公共密鑰下加密的 accompanying KEY RR。[6] | |
| 250 | RFC 2845 | 交易憑證 | 用以認證動態更新是來自合法的用戶端,或與 DNSSEC 一樣是驗證回應是否來自合法的遞歸名稱服務器。[7] | |
TXT |
16 | RFC 1035 | 文本記錄 | 最初是為任意可讀的文本 DNS 記錄。自一九九零年起,些記錄更經常地帶有機讀數據,以 RFC 1464 指定:opportunistic encryption、Sender Policy Framework(雖然這個臨時使用的 TXT 記錄在 SPF 記錄推出後不被推薦)、DomainKeys、DNS-SD等。 |
其他類型及偽資源記錄
其他類型的資源記錄簡單地提供一些類型的訊息(如: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)[8]
- 錯誤: 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]..
參考資料
- ^ 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."
- ^ 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