DNSSEC 驗證流程

第一步：RRSIG

前述提到，DNSSEC 的狀況下，每一個紀錄都應該要經過數位簽章做簽署的動作。所以 DNSSEC 裡面有提到一種 DNS 紀錄，這個紀錄叫做 RRSIG，會附在 DNS 請求的回覆當中。

內容大概像這樣：

   網域名稱       TTL  型別   內容
   a.z.w.example. 3600 IN MX  1 ai.example.
   a.z.w.example. 3600 RRSIG  MX 5 2 3600 20040509183619 (
                              20040409183619 38519 example.
                              OMK8rAZlepfzLWW75Dxd63jy2wswESzxDKG2
                              f9AMN1CytCd10cYISAxfAdvXSZ7xujKAtPbc
                              tvOQ2ofO7AZJ+d01EeeQTVBPq4/6KCWhqe2X
                              TjnkVLNvvhnc0u28aoSsG0+4InvkkOHknKxw
                              4kX18MMR34i8lC36SR5xBni8vHI= )

第一行是 ai.example 這個網域的 MX 紀錄。
第二行是給第一筆記錄使用的 RRSIG 紀錄。

RRSIG 的格式是這樣的：

[對應格式] [算法編號] [涵蓋數量]  [有效時間長短] [簽章期限] 
|            |         |              |           |
|   ---------/         |              |           |
|  /  -----------------/              |           |
|  | /  /-----------------------------/           |
|  | |  |   /-------------------------------------/
|  | |  |   |
|  | |  |   |
MX 5 2 3600 20040509183619 ( 20040409183619 38519 example. OM.....HI= ) 
                             |               |     |         |
  /--------------------------/               |     |         |
  |          /-------------------------------/     |         |
  |          |      /------------------------------/         |
  |          |      |            /---------------------------/
[簽署日期] [Tag] [簽署者名稱] [內容，base64]

圖有點簡陋。另外「涵蓋數量」，會在之後解釋。

DNSKEY

隨著 RRSIG 的出現，我們拿到憑證的內容了。不過我們需要驗證這個簽章是不是偽造的，然後是誰簽的。這個資訊，會在 DNSKEY 紀錄當中。

   example.com. 86400 IN DNSKEY 256 3 5 ( AQPSKmynfzW4kyBv015MUG2DeIQ3
                                          Cbl+BBZH4b/0PY1kxkmvHjcZc8no
                                          kfzj31GajIQKY+5CptLr3buXA10h
                                          WqTkF7H6RfoRqXQeogmMHfpftf6z
                                          Mv1LyBUgia7za6ZEzOJBOztyvhjL
                                          742iU/TpPSEDhm2SNKLijfUppn1U
                                          aNvv4w==  )

DNSKEY 裡面會包含拿去簽署 RRSIG 的公鑰。
不過，即使我們能夠確認「這個 RRSIG 和 DNSKEY 對得起來」，也還不能夠確認「這個 DNSKEY 真的屬於這個網域」。
所以我們會需要一個能夠信任方式，來驗證這個 DNSKEY。
就像前面提到的 HTTPS 憑證信任鏈的狀況，我們可能有幾種做法，可以驗證這個東西：

1. 用其他的方式去獲得「這個網域真正的公鑰」，例如 PGP、中華郵政寄隨身碟、用紙抄、用 scp 先下載一份
2. 叫別人證明你是合法的（參考 HTTPS 中介憑證機制）

信任鏈機制

前述提到，只拿到 DNSKEY 沒什麼用。然後若要將上述第一種取得真正公鑰的方式，放到 DNS 這種許多人用的協定之上，是不可行的。想像一下，你要聯網之前，必須要插隨身碟。這是一個多荒誕的事情？

所以，我們可以依賴上一級網域的 DNS 紀錄，把上一級憑證的公鑰放在那邊。在 DNSSEC 中，這個叫做 DS (Delegation Signer) 紀錄。由於你可以指定非常多的子網域，所以 DS 紀錄中，只會記載「這個憑證的指紋 (hash)」。

真的很短，他長得像這樣：

 dskey.example.com. 86400 IN DS 60485 5 1 ( 2BB183AF5F22588179A53B0A
                                            98631FAD1A292118 )

然後假設一筆 DNSKEY 是被上一級簽署過的話，他會看起來像這樣：

dskey.example.com. 86400 IN DNSKEY 256 3 5 ( AQOeiiR0GOMYkDshWoSKz9Xz
                                         fwJr1AYtsmx3TGkJaNXVbfi/
                                         2pHm822aJ5iI9BMzNXxeYCmZ
                                         DRD99WYwYqUSdjMmmAphXdvx
                                         egXd/M5+X7OrzKBaMbCVdFLU
                                         Uh6DhweJBjEVv5f2wwjM9Xzc
                                         nOf+EPbtG9DMBmADjFDc2w/r
                                         ljwvFw==
                                         ) ;  key id = 60485

其中，我們會發現 key id 和上面的 DS 紀錄是一樣的。另外，是可以通過 DNSKEY 去計算出 DS 的數值，所以我們可以透過證明這兩個之間的關係，來保證 DNSKEY 紀錄的可靠性。

特殊狀況: 找不到紀錄怎麼辦？ (NSEC)

在 DNS 的狀況下，基本上，若找不到東西，只要回覆 NXDOMAIN 就好了。不過在 DNSSEC 的狀況下，由於回覆的資料內容內也要證明這訊息不是偽造的，但這東西根本查不到，所以我們要想辦法告訴對方「我真的找不到」。

DNSSEC 想到了這個問題，所以又有一種紀錄叫做 NSEC (Next Secure)。這個紀錄裡面會記載說「下一筆紀錄是什麼」。

所以，假設今天有 A、B、D。有人問了 C，你找不到，但是你可以用 NSEC 和他說：「下一筆真的是 D，我知道他還有 A、RRSIG和NSEC，你可以看看D是不是真的有這些東西」來確保你沒有說謊。
由於 DNS 紀錄是以字母來做排序的，所以你可以確定「真的沒有那筆東西」。

另外，若某一個網域的紀錄是存在的，只是問錯類別（例如你有 A 但對方問 MX）的話，這時候的回覆裡面_會告訴對方這個網域所有的紀錄_。
不過，不管是不是這個狀況，NSEC 都有可能引起安全疑慮，之後會提到。

下一篇會提到：

• RRSIG 裡面的「涵蓋數量」
• NSEC 帶來的問題
• DNSSEC 目前的困難