文章目錄
- 1. 引言
- 2. DNSKEY資源記錄
- 2.1 DNSKEY RDATA 有線格式
- 2.1.1 標誌(Flags)字段
- 2.1.2 協議(Protocol)字段
- 2.1.3 算法(Algorithm)字段
- 2.1.4 公鑰(Public Key)字段
- 2.1.5 關於DNSKEY RDATA設計的說明
- 2.2 DNSKEY RR 的表現形式
- 2.3 DNSKEY RR 例子
- 3. RRSIG 資源記錄
- 3.1 RRSIG RDATA 有線格式
- 3.1.1 類型覆蓋字段
- 3.1.2 算法編號字段
- 3.1.3 標籤(label)字段
- 3.1.4 原始TTL字段
- 3.1.5 簽名過期和初始字段
- 3.1.6 Key Tag 字段
- 3.1.7 簽名者名字字段
- 3.1.8 簽名字段
- 3.2 RRSIG RR 表現形式
- 3.3 RRSIG RR 例子
- 4 NSEC資源記錄
- 5 DS 資源記錄
- 6 資源記錄的規範形式和順序
- A. DNSSEC算法和摘要類型
- B. Key Tag計算
1. 引言
DNS安全擴展(DNSSEC)引入了4種新的DNS資源記錄類型:DNS公鑰(DNSKEY)、資源記錄簽名(RRSIG)、Next Secure (NSEC)和委託簽名者(DS)。本文檔定義了每個資源記錄(RR)、RR的RDATA格式及其表示格式(ASCII表示)的用途。
1.1 背景和相關文檔
這個文檔是定義DNSSEC的文檔系列的一部分，應該作爲一個集合一起閱讀。
[RFC4033]包含對DNSSEC的介紹和常用術語的定義;讀者應該熟悉這份文件。[RFC4033]還包含由本文檔集更新和廢止的其他文檔列表。
[RFC4035]定義了DNSSEC協議操作。
讀者還應該熟悉[RFC1034]、[RFC1035]中描述的基本DNS概念，以及隨後更新它們的文檔，特別是[RFC2181]和[RFC2308]。
本文檔定義了DNSSEC資源記錄。本文檔中給出的所有數字DNS類型代碼都是十進制整數。
1.2 關鍵字
本文件中“必須”、“不得”、“必須”、“必須”、“不得”、“應當”、“不應當”、“建議”、“可以”、“可選”等關鍵詞的解釋見[RFC2119]。
2. DNSKEY資源記錄
DNSSEC使用公鑰加密對DNS資源記錄集(RRset)進行簽名和身份驗證。公鑰存儲在DNSKEY資源記錄中，並用於[RFC4035]中描述的DNSSEC身份驗證過程:區域使用私鑰簽署其權威RRset，並將相應的公鑰存儲在DNSKEY RR中。然後，解析器可以使用公鑰驗證區域中覆蓋rrset的簽名，從而對它們進行身份驗證。
DNSKEY RR不是用來存儲任意公鑰的記錄，也不能用來存儲與DNS基礎設施沒有直接關係的證書或公鑰。
DNSKEY RR類型的是48。
DNSKEY RR與class無關。
DNSKEY RR沒有特殊的TTL要求。
2.1 DNSKEY RDATA 有線格式
DNSKEY RR的RDATA由2個八字節標記字段、1個八字節協議字段、1個八字節算法字段和公鑰字段組成。
1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags | Protocol | Algorithm |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ /
/ Public Key /
/ /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2.1.1 標誌(Flags)字段
flag字段的第7位是區域key tag。如果第7位爲1,那麼DNSKEY記錄就有一個DNS區域key,而DNSKEY RR的所有者名稱必須是一個區域的名稱。如果第7位爲0,那麼DNSKEY記錄就會保留其他類型的DNS公鑰,不能用來驗證該值的RRSIGs。
Flags字段的第15位是安全入口點標誌，在[RFC3757]中有描述。如果第15位的值爲1，那麼DNSKEY記錄持有一個密鑰，該密鑰將用作安全入口點。此標誌僅爲區域簽名或調試軟件使用此DNSKEY記錄的提示;在簽名驗證過程中，驗證器不能根據這個位的設置以任何方式改變它們的行爲。這也意味着帶有SEP位集的DNSKEY RR也需要設置區域密鑰標誌，以便能夠合法地生成簽名。帶有SEP設置和未設置區域密鑰標誌的DNSKEY RR不能用於驗證覆蓋rrset的RRSIGs。
0-6位和8-14位被保留:這些位在創建DNSKEY RR時值必須爲0，在接收時必須被忽略。
2.1.2 協議(Protocol)字段
協議字段必須爲3，如果在簽名驗證期間發現DNSKEY RR是3以外的值，則必須將其視爲無效。
2.1.3 算法(Algorithm)字段
算法字段標識公鑰的加密算法，並確定公鑰字段的格式。DNSSEC算法類型的列表可以在附錄A.1中找到
2.1.4 公鑰(Public Key)字段
公鑰字段包含公鑰材料。格式取決於存儲密鑰的算法，並在單獨的文檔中進行描述。
2.1.5 關於DNSKEY RDATA設計的說明
儘管Protocol字段的值始終爲3，但保留它是爲了向後兼容密鑰記錄的早期版本。
2.2 DNSKEY RR 的表現形式
RDATA部分的表示格式如下：
標記字段必須表示爲無符號的十進制整數。給定當前定義的標誌，可能的值是:0、256和257。
協議字段必須表示爲值爲3的無符號十進制整數。
算法字段必須表示爲無符號十進制整數，或者表示爲附錄A.1中指定的算法助記符。
公鑰字段必須表示爲公鑰的Base64編碼。Base64文本中允許有空格。有關Base64編碼的定義，請參見[RFC3548]。
2.3 DNSKEY RR 例子
下面的DNSKEY RR存儲example.com的DNS區域key。
example.com. 86400 IN DNSKEY 256 3 5 ( AQPSKmynfzW4kyBv015MUG2DeIQ3
Cbl+BBZH4b/0PY1kxkmvHjcZc8no
kfzj31GajIQKY+5CptLr3buXA10h
WqTkF7H6RfoRqXQeogmMHfpftf6z
Mv1LyBUgia7za6ZEzOJBOztyvhjL
742iU/TpPSEDhm2SNKLijfUppn1U
aNvv4w== )
前四個文本字段指定所有者名稱、TTL、類和RR類型(DNSKEY)。值256表示Flags字段中的區域鍵位(第7位)的值爲1。值3是固定的協議值。值5表示公鑰算法。附錄A.1將算法類型5標識爲RSA/SHA1，並指出RSA/SHA1公鑰字段的格式定義在[RFC3110]中。剩下的文本是公鑰的Base64編碼。
3. RRSIG 資源記錄
DNSSEC使用公鑰加密對RRset進行簽名和身份驗證。數字簽名存儲在RRSIG資源記錄中，並用於[RFC4035]中描述的DNSSEC身份驗證過程。驗證器可以使用這些RRSIG RRs來驗證區域中的rrset。RRSIG RR只能用於攜帶用於保護DNS操作的驗證材料(數字簽名)。
RRSIG記錄包含具有特定名稱、類和類型的RRset的簽名。RRSIG RR指定簽名的有效間隔，並使用算法、簽名者的名稱和key tag來標識包含公鑰的DNSKEY RR，驗證器可以使用公鑰來驗證簽名。
因爲區域中的每個權威RRset都必須受到數字簽名的保護，所以對於包含CNAME RR的名稱，必須提供RRSIG RRs。這是對傳統DNS規範[RFC1034]的一個更改，該規範規定，如果一個名稱存在CNAME，那麼它是該名稱中唯一允許的類型。RRSIG和NSEC(參見第4節)必須與已簽名區域中的CNAME資源記錄具有相同的名字。
RRSIG RR類型的Type value是46。
RRSIG RR與class無關。
RRSIG RR必須與它所覆蓋的RRset具有相同的類。
RRSIG記錄包含具有特定名稱、類和類型的RRset的簽名。RRSIG RR指定簽名的有效間隔，並使用算法、簽名者的名稱和key tag來標識包含公鑰的DNSKEY RR，驗證器可以使用公鑰來驗證簽名。
3.1 RRSIG RDATA 有線格式
RRSIG RR的RDATA由2字節的類型覆蓋字段,1字節的算法字段,1字節的標籤,4字節的原始TTL字段，字節的簽名到期字段,4字節的簽名起始字段,2字節的key tag字段，以及簽名者的名字字段和簽名字段。
1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type Covered | Algorithm | Labels |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Original TTL |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Signature Expiration |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Signature Inception |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Key Tag | /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Signer's Name /
/ /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ /
/ Signature /
/ /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3.1.1 類型覆蓋字段
3.1.2 算法編號字段
3.1.3 標籤(label)字段
3.1.4 原始TTL字段
3.1.5 簽名過期和初始字段
3.1.6 Key Tag 字段
Key Tag字段包含驗證此簽名的DNSKEY RR的Key Tag值，以網絡字節順序排列。附錄B解釋瞭如何計算鍵標籤值。
3.1.7 簽名者名字字段
3.1.8 簽名字段
3.2 RRSIG RR 表現形式
3.3 RRSIG RR 例子
4 NSEC資源記錄
NSEC資源記錄列出了兩個單獨的東西:下一個所有者名稱(在區域的規範順序中)，它包含權威數據或委託點NS RRset，以及NSEC RR的所有者名稱[RFC3845]處的RR類型集。區域中的完整NSEC RRs集指示區域中存在哪些權威rrset，並在區域中形成權威所有者名稱鏈。如[RFC4035]所述，此信息用於爲DNS數據提供經過身份驗證的否認存在。
因爲區域中的每個權威名稱都必須是NSEC鏈的一部分，所以對於包含CNAME RR的名稱，NSEC RRs必須出現。這是對傳統DNS規範[RFC1034]的一個更改，該規範規定，如果一個名稱存在CNAME，那麼它是該名稱中唯一允許的類型。RRSIG(參見第3節)和NSEC必須與帶簽名區域中的CNAME資源記錄具有相同的名稱。
請參閱[RFC4035]，以瞭解區域簽名者如何精確地確定它必須在區域中包含哪些NSEC RRs。
NSEC RR的Type value是47。
NSEC RR與class無關。
NSEC RR應該具有與SOA最小TTL字段相同的TTL值。這就是負緩存的精神([RFC2308])。
4.1 NSEC RDATA有線格式
NSEC RR的RDATA如下圖所示:
1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ Next Domain Name /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ Type Bit Maps /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
4.1.1 下一個域名字段
4.1.2 類型比特映射字段
4.1.3 NSEC RDATA中包含通配符名稱
4.2 NSEC RR 表現形式
4.3 NSEC RR 示例
5 DS 資源記錄
DS RR引用一個DNSKEY RR，並在DNS DNSKEY身份驗證過程中使用。通過存儲key tag、算法編號和DNSKEY RR的摘要，DS RR引用DNSKEY RR。請注意，雖然摘要應該足以識別公鑰，但存儲key tag和密鑰算法有助於提高標識過程的效率。通過對DS記錄進行身份驗證，解析器可以對DS記錄指向的DNSKEY RR驗證。密鑰認證過程在[RFC4035]中有描述。
DS RR及其對應的DNSKEY RR擁有相同的所有者名稱，但是它們存儲在不同的位置。DS RR只出現在委託的上級(父級)側，是父區中的權威數據。例如，“example.com”的DS RR存儲在“com”區域(父區域)中，而不是存儲在 “example.com” 區域(子區域)中。對應的DNSKEY RR存儲在“example.com”區域(子區域)中。這簡化了DNS區域管理和區域簽名，但爲DS RR引入了特殊的響應處理需求;這些在[RFC4035]中有描述。
DS記錄的Type value是43。
DS資源記錄是class獨立的。
DS RR沒有特殊的TTL要求。
5.1 DS RDATA有線格式
一個DS RR的RDATA包含一個2字節的key tag字段、一個1字節的算法字段、一個1字節的摘要類型字段和一個摘要字段。
1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Key Tag | Algorithm | Digest Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ /
/ Digest /
/ /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
5.1.1 Key Tag 字段
Key Tag字段以網絡字節順序列出DS記錄引用的DNSKEY RR的key tag。
DS RR使用的key tag與RRSIG RRs使用的key tag相同。附錄B描述瞭如何計算key tag。
5.1.2 算法字段
算法字段列出DS記錄引用的DNSKEY RR的算法編號。
DS RR使用的算法編號與RRSIG和DNSKEY RRs使用的算法編號相同。附錄A.1列出了算法編號類型。
5.1.3 摘要類型字段
通過包含DNSKEY RR的摘要，DS RR引用DNSKEY RR。摘要類型字段標識用於構造摘要的算法。附錄A.2列出了可能的摘要算法類型。
5.1.4 摘要字段
DS記錄通過包含DNSKEY RR的摘要來引用DNSKEY RR。
通過將DNSKEY RR的完全限定所有者名的規範形式與DNSKEY RDATA連接起來，然後應用摘要算法，計算摘要。
// “|” 表示連接
digest = digest_algorithm( DNSKEY owner name | DNSKEY RDATA);
DNSKEY RDATA = Flags | Protocol | Algorithm | Public Key.
摘要的大小取決於摘要算法和DNSKEY RR大小。在撰寫本文時，唯一定義的摘要算法是SHA-1，它生成一個20字節的摘要。
5.2 驗證響應時對DS RRs的處理
DS RR跨區域邊界鏈接身份驗證鏈，因此在處理時需要格外小心。在DS RR中引用的DNSKEY RR必須是DNSSEC區域key。DNSKEY RR標誌必須設置第7位標誌。如果DNSKEY標誌沒有指明DNSSEC區域key，那麼在驗證過程中不能使用DS RR(和它引用的DNSKEY RR)。
5.3 DS RR 的表現形式
RDATA部分的表示格式如下：
key tag字段必須表示爲無符號十進制整數。
算法字段必須表示爲無符號十進制整數或附錄A.1中指定的算法助記符。
摘要類型字段必須表示爲無符號十進制整數。
摘要必須表示爲不區分大小寫的十六進制數字序列。允許在十六進制文本中使用空格。
5.4 DS RR 的例子
下面的例子顯示了一個DNSKEY RR和它對應的DS RR。
dskey.example.com. 86400 IN DNSKEY 256 3 5 ( AQOeiiR0GOMYkDshWoSKz9Xz
fwJr1AYtsmx3TGkJaNXVbfi/
2pHm822aJ5iI9BMzNXxeYCmZ
DRD99WYwYqUSdjMmmAphXdvx
egXd/M5+X7OrzKBaMbCVdFLU
Uh6DhweJBjEVv5f2wwjM9Xzc
nOf+EPbtG9DMBmADjFDc2w/r
ljwvFw==
) ; key id = 60485
dskey.example.com. 86400 IN DS 60485 5 1 ( 2BB183AF5F22588179A53B0A
98631FAD1A292118 )
前四個文本字段指定名稱、TTL、類和RR類型(DS)。值60485是對應的“dskey.example.com”的key tag。值5表示這個“dskey.example.com”使用的算法。DNSKEY RR。值1是用來構造摘要的算法，其餘的RDATA文本是十六進制的摘要。
6 資源記錄的規範形式和順序
本節定義了資源記錄的規範形式、DNS名稱的規範排序和RRset內的資源記錄的規範排序。構造NSEC名稱鏈需要一個規範的名稱順序。爲了構造和驗證RRSIG RRs，需要一個規範的RR表單和RRset中的排序。
6.1 DNS名字順序規範
出於DNS安全的目的，通過將單個標籤視爲無簽名左對齊的字節串來對所有者名進行排序。如果沒有一個八位元，則在零值八位元之前進行排序，並且大寫的US-ASCII字母被視爲小寫的US-ASCII字母。
要計算一組DNS名稱的規範順序，首先要根據最重要(最右邊)的標籤對名稱進行排序。對於最重要的標籤相同的名稱，繼續按照它們的下一個最重要的標籤排序，依此類推。
例如，以下名稱按規範DNS名稱順序排序。最重要的標籤是“example”。在這個級別，“example”首先排序，然後是以“a.example”結尾的名字，然後以"z.example"結尾的名字。每一層的名稱都以相同的方式排序。
example
a.example
yljkjljk.a.example
Z.a.example
zABC.a.EXAMPLE
z.example
\001.z.example
*.z.example
\200.z.example
6.2 RR格式規範
出於DNS安全的考慮，RR的規範形式是RR的連線格式：
- RR中的每個域名都是完全展開的(沒有DNS名稱壓縮)，並且是完全限定的
- RR所有者名稱中的所有大寫US-ASCII字母都被相應的小寫US-ASCII字母替換
- 如果NS RR的類型,醫學博士,曼氏金融CNAME, SOA, MB, MG,先生,PTR, HINFO, MINFO, MX, HINFO, RP, AFSDB, RT,團體,PX, NXT, NAPTR, KX,深水救生艇,DNAME, A6, RRSIG,或NSEC,所有大寫us - ascii字母的DNS名稱中包含RDATA替換爲相應的小寫us - ascii字母
- 如果RR的所有者名稱是通配符名稱，則所有者名稱是原始的未擴展形式，包括“*”標籤(沒有通配符替換);並且，
- RR的TTL被設置爲它在原始權威區域或覆蓋RRSIG RR的原始TTL字段中出現的原始值。
6.3 一個RRser中RR順序的規範
出於DNS安全的目的，對具有相同所有者名稱、類和類型的RRs進行排序，方法是將每個RR的規範形式的RDATA部分視爲左對齊的無符號八字節序列，其中在零八字節之前沒有八字節。
[RFC2181]指定RRset不允許包含重複的記錄(具有相同所有者name、class、type和RDATA的多個RRs)。因此，如果實現在將RRset置於規範形式時檢測到重複的RRs，則必須將其視爲協議錯誤。如果實現選擇在健壯性原則的精神下處理這個協議錯誤(它接受的內容是自由的)，那麼爲了計算RRset的規範形式，它必須刪除所有的重複RR(s)，只有一個例外。
A. DNSSEC算法和摘要類型
A.1 DNSSEC算法類型
DNSKEY、RRSIG和DS RRs使用8位數字來識別所使用的安全算法。這些值存儲在資源記錄RDATA中的“Algorithm Number”字段中。
有些算法只適用於區域簽名(DNSSEC)，有些只適用於事務安全機制(SIG(0)和TSIG)，有些同時適用於兩者。可用於區域簽名的可能出現在DNSKEY、RRSIG和DS RRs中。如[RFC2931]所述，那些可用於事務安全的將在SIG(0)和密鑰RRs中出現。
Zone
Value Algorithm [Mnemonic] Signing References Status
----- -------------------- --------- ---------- ---------
0 reserved
1 RSA/MD5 [RSAMD5] n [RFC2537] NOT RECOMMENDED
2 Diffie-Hellman [DH] n [RFC2539] -
3 DSA/SHA-1 [DSA] y [RFC2536] OPTIONAL
4 Elliptic Curve [ECC] TBA -
5 RSA/SHA-1 [RSASHA1] y [RFC3110] MANDATORY
252 Indirect [INDIRECT] n -
253 Private [PRIVATEDNS] y see below OPTIONAL
254 Private [PRIVATEOID] y see below OPTIONAL
255 reserved
6-251 可供IETF標準行動分配。
A.1.1 私有算法類型
算法編號253保留給私人使用，永遠不會分配給特定的算法。DNSKEY RR中的公鑰區域和RRSIG RR中的簽名區域以有線編碼的域名開始，該域名不能被壓縮。域名錶示要使用的私有算法，公鑰區域的其餘部分由該算法確定。實體應該只使用它們控制的域名來指定它們的私有算法。
算法編號254保留給私人使用，永遠不會分配給特定的算法。DNSKEY RR中的公鑰區域和RRSIG RR中的簽名區域以一個無符號長度字節開始，後跟該長度的BER編碼的對象標識符(ISO OID)。OID表示正在使用的私有算法，其餘的區域是該算法所需要的區域。實體應該只使用它們控制的oid來指定它們的私有算法。
A.2 DNSSEC摘要類型
DS資源記錄類型中的“Digest Type”字段標識資源記錄使用的加密摘要算法。下表列出了當前定義的摘要算法類型。
VALUE Algorithm STATUS
0 Reserved -
1 SHA-1 MANDATORY
2-255 Unassigned -
B. Key Tag計算
RRSIG和DS資源記錄類型中的key tag字段提供了一種有效選擇公鑰的機制。在大多數情況下，所有者名稱、算法和key tag的組合可以有效地識別DNSKEY記錄。RRSIG和DS資源記錄都有相應的DNSKEY記錄。當有多個候選DNSKEY RR可用時，可以使用RRSIG和DS記錄中的Key tag字段來幫助有效地選擇相應的DNSKEY RR。
但是，必須注意，key tag不是惟一的標識符。從理論上講，兩個不同的DNSKEY RRs可能具有相同的所有者名稱、相同的算法和相同的key tag。key tag用於限制可能的候選鍵，但它不能唯一地標識DNSKEY記錄。實現不能假設key tag唯一地標識DNSKEY RR。
除了算法1外，所有DNSKEY算法類型的key tag都是相同的(算法1的key tag定義見附錄B.1)。首先，將RDATA(有線格式)分成一系列的2個字節組。然後將這些組相加，忽略任何進位。
key tag算法的一個參考實現是一個ANSI C函數，如下所示，使用DNSKEY RR的RDATA部分作爲輸入。沒有必要逐字使用下面的參考代碼，但是key tag的數值必須與參考實現爲相同的輸入生成的數值相同。
請注意，計算key tag的算法與我們所熟悉的其他Internet協議中使用的校驗和算法幾乎相同，但並不完全相同。key tag必須使用這裏描述的算法來計算，而不是使用互補校驗和。
下面的ANSI C參考實現計算key tag的值。此參考實現適用於除算法1之外的所有算法類型(參見附錄B.1)。輸入是DNSKEY RR的RDATA部分的連線格式。代碼是爲了清晰而不是效率而編寫的。
/*
* Assumes that int is at least 16 bits.
* First octet of the key tag is the most significant 8 bits of the
* return value;
* Second octet of the key tag is the least significant 8 bits of the
* return value.
*/
unsigned int
keytag (
unsigned char key[], /* the RDATA part of the DNSKEY RR */
unsigned int keysize /* the RDLENGTH */
)
{
unsigned long ac; /* assumed to be 32 bits or larger */
int i; /* loop index */
for ( ac = 0, i = 0; i < keysize; ++i )
ac += (i & 1) ? key[i] : key[i] << 8;
ac += (ac >> 16) & 0xFFFF;
return ac & 0xFFFF;
}
B.1 算法1（RSA/MD5）的Key Tag
由於歷史原因，算法1 (RSA/MD5)的key tag的定義與所有其他算法的key tag不同。對於使用算法1的DNSKEY RR，key tag被定義爲公鑰模量(即公鑰模量的第4到最後一個字節和第3到最後一個字節)中24位中最有效的16位。
請注意，不推薦使用算法1。