作者 主題: DNSSEC 入門介紹  (閱讀 21222 次)

0 會員 與 1 訪客 正在閱讀本文。

HaWay

  • 大隻佬!
  • 老人組
  • 俺是博士!
  • *****
  • 文章數: 3980
    • 檢視個人資料
DNSSEC 入門介紹
« 於: 2010-02-07 12:46 »

有鑑於 DNSSEC 的中文文章實在很少,在網路上搜尋根本甚鬼都沒有,
很多都只是 ref 到其他 rfc, 台灣資源真的落後很多。

最近剛好在學 DNSSEC, 就整了一些東西分享給大家

如果你覺得這邊文章不錯, 可以再不經告知的情況下轉載,只需標明出處

不可擅自修改
可自行附加說明於後端
可自行轉錄

*************************************
* Author: HaWay@Study-Area
* Date: 2010/2/7
*************************************
特別說明:
此篇文章是工作需求下所研讀,但發表此篇文章屬我個人言論。
( 如果我說錯了,才不會丟公司的臉 XD )


1. DNSSEC 簡介

DNSSEC 其實就是 DNS + 數位簽章, 數位簽章其實網路上文章一堆,我簡單的說明一下,

1.1 數位簽章
   數位簽章是用兩把 key, private key & public key 對資料加密
   private key 加密的東西只有 public key 解的開, 亦反之。

   先產生兩把 key , private key & public key, 還有你要加密的資訊(簡稱 msg)
   把 msg 做雜湊演算,會得到一個 hash 值,把 hash 用 private key
   做加密,就會得到一串加密的字串,這串字串就是數位簽章,然後把public key 公開。

   當 client 取得 msg 並非加密後的樣子,而使原始資料,而 user 如何驗證這個
   msg 非偽造來源, 就是透過數位簽章, user 除了原始資料外,還會額外取得數位簽章跟來源端的
   public key, user 用 public key 去解開數位肩章, 會得到一個 hash 值,
   把 msg 也做一次雜湊演算,也會取得一個 hash 值(hash2), 比對兩個 hash & hash2 一步一樣
   就知道了來源是正確

   圖片引用自 O'reilly DNS & BIND9

2. DNSSEC 新增的東西
   把 DNS 封包加上數位簽章,來避免來源詐騙,DNS 為了完成 DNSSEC 的實做,增加了四種 RRsets,
   就像 NS, A, MX 一樣的意思:

   DNSKEY 就是 public key 公佈的地方
   RRSIG 就是儲存數位簽章
   DS 是上層對下層的 DNSKEY 驗證(稍後解釋)
   NSEC 回應負面消息.

   兩個 header bit
   AD bit
   CD bit
   DO ( EDNS0 )

   DNSSEC 還必須要有 EDNS0 的支援,讓 udp 封包能擴展到 4,096 bytes,
   不然容不下 RRSIG, EDNS0 封包也新增 DO flag.

   關於四種 RRset 的封包格式,這邊先不說,RFC4034 裡面一堆,這邊先定位在入門。

2.1 DNSKEY
   DNSKEY 就是公佈 public key 的地方,解析器會透過查詢 DNSKEY 來取得 public key.

2.2 RRSIG
   一個 RR,譬如 www.abc.com.tw 7200 IN A 192.168.1.1 會先透過雜湊算出 hash 值,
   接者用 private key 對這個 hash 值做加密,變成數位簽章,假設最後的數位簽章是 'abc1234',
   RRSIG 就是紀錄數位簽章的地方,所以最後看起來就像這樣:

   www.abc.com.tw 7200 IN A 192.168.1.1
   www.abc.com.tw 7200 IN RRSIG A 5 3 7200 20060219233605 20060120233605 3674 abc.com.tw abc1234

   因為雜湊的 hash 值其實會把相同資料一起做雜湊,所以當你有很多相同的 NS RR 時,NS 的 RRSIG 也指會有一個,譬如:
   
   abc.com.tw 7200 IN NS ns1.abc.com.tw
   abc.com.tw 7200 IN NS ns2.abc.com.tw
   abc.com.tw 7200 IN NS ns5.abc.com.tw
   abc.com.tw 7200 IN RRSIG NS 5 3 7200 20060219233605 20060120233605 3674 abc.com.tw xxxxxxxxxxxxx
   (domain TTL IN RRSIG NS 演算法 固定3 原本的TTL 簽署開始日期 簽署到期日期 keyID ownerdomain rdata)

   同一個網域的同一種型態只會有一筆 RRSIG.

2.3 DS
   如果你已經在 DNSSEC 的世界裡正常運作了,你的解析器會先透過 DNSKEY 去取得 public key,
   可是你怎麼確定你取得的 public key 不是假的呢?
   假設你取得 abc.com.tw 的 DNSKEY 是走 ip 1.2.3.4, 可是 1.2.3.4 可能已經是偽造的 DNS server,
   所以你取得的 DNSKEY 可能就已經是假的,那怎麼確定你取得的 KEY 是正常的呢?就是靠上層幫你認證,也就是 com.tw 。

   當你產生 public key 之後,必須傳給你上層的管理單位,同時附上證明文件能證明你是 abc.com.tw
   的管理者,上層就會將這個 public key 做一次 hash ,存放在 com.tw 的 DS 紀錄裡面,指向 abc.com.tw。
   
   因為你的 public key 已經被上層紀錄了,所以當解析器查詢 abc.com.tw 的時候,
   會透過 com.tw 去查詢 abc.com.tw 的 DS 紀錄,並跟 abc.com.tw 取得 DNSKEY 做 hash,
   兩個一筆對就知道了。

   如果你的 DNS server 被入侵了,DNSKEY 被重新簽過換掉,但由於上層已經紀錄過你的 key, 所以會不一樣。

   整個 DNSSEC 的驗證鍊都是走 DNSKEY & DS 來確定每一層是正確的,從 root(.) 開始一直到 abc.com.tw
   每一層都是 DNSKEY & DS 驗證,一直到該 DNSKEY 可以解開 RRSIG 為止。

   所以你送一筆 KEY 給上層,上層就會有一筆 DS 紀錄,送兩個 key , 兩個 DS 紀錄....

2.4 NSEC
   NSEC 其實就是負面訊息的 DNSSEC 而已。
   在 DNSSEC 中,要把所有的網域做排序 由右至左,不存在的優先,所以網域排序後會變這樣

   net.tw.
   0.net.tw.
   twnic.net.tw.
   a.twnic.net.tw.
   web.twnic.net.tw.
   
   假如你查詢 def.twnic.net.tw 的話,會獲得回應

   web.twnic.net.tw IN NSEC net.net.tw ( A MX RRSIG DNSKEY )

   表示你查詢的 def.twnic.net.tw 剛好在 web.twnic.net.tw 與 net.tw 的 "縫" 之間之間
   NSEC 會告訴你前一個(web.twnic.net.tw)跟後一個(net.tw),如果後一個已經到底了,則回到最前面一個,形成一個鏈( chain )。所以你查詢的 domain 不存在,你可以查 web.twnic.net.tw 來驗證是否正確。

3.KSK & ZSK
   前面有提到 DS 的運作,就是讓你的 public key 給上層作一個紀錄,以便驗證 key 的正確性。

   即使是 private key & public key 的模式,如果黑客透過手法,還是可以一直收集你的 dnssec 封包去破解你的數位簽章
   所以 key 還是要常常換.

   在 DNSSEC 實做的時候,會把 private key 拿去對 zone file 做加密, 把 public key 公開並給上層作 DS 驗證. 這對 key 稱為 Zone singing key (ZSK) 照字面上的意思就是拿來簽署 zone 的 key, 而為了怕被破解, 所以其實 ZSK 需要時常更換, 但是當 key 更新時,public key 同時也要給上層重新產生 DS 驗證,如果你上層管理單位,下層有 10 個 subdomian 那可還還好, 如果你是 tw. 管理者, 我看你怎麼簽這個 DS ..... Orz

   所以就有了 key singing key(KSK) 的出現,原本你的 ZSK 的 public key 要給上層,現在再產生一把 key(先簡稱 key2), 用 key2 private key 去簽 ZKS 的 public key , 產生出來的就是 DNSKEY, 而把 key2 的 public key 往上層送變成 DS.

   這有什麼好處呢? 當你的 ZSK 要更換的時候,只要重新將 key2 的 private key 再簽一次 ZSK 的 public key, 就不需要再向上更新,但並不是說這輩子都不用更新,KSK 還是要更新並且重新產生 DS, 只是可能 ZSK 是每 1 個月更新一次,而 KSK 可能是半年或一年。

   基本上幾個重點就是這些,rfc4034 & rfc4035 才是重點,有機會再整理上來。
我做人那麼 nice, 肯定有什麼誤會.....

HaWay

  • 大隻佬!
  • 老人組
  • 俺是博士!
  • *****
  • 文章數: 3980
    • 檢視個人資料
回覆: DNSSEC 入門介紹
« 回覆 #1 於: 2010-02-11 17:25 »
我做人那麼 nice, 肯定有什麼誤會.....

LPJ

  • 懷疑的國中生
  • **
  • 文章數: 81
    • 檢視個人資料
回覆: DNSSEC 入門介紹
« 回覆 #2 於: 2010-11-25 15:24 »
RFC 4035 中文版

已經被BOT修改過了,請再檢查,謝謝您。