通過修改 glibc 支援 DNS 加密通過修改 glibc 支援 DNS 加密

從某種意義上來說，這個問題多年以前就解決了，我們可以配置一個本地域名服務實作完整的 dnssec 校驗verification并允許應用程式通過 glibc 函數來使用該服務。dnssec 甚至還可以用于提高其他領域的安全性，比如，它可以攜帶 ssh 或 tls 密鑰指紋，讓應用程式可以确認其在與正确的伺服器對話。不過，當我們希望确認這條自稱帶有 dnssec 校驗的 dns 結果是不是真的已認證認證的時候 - 也就是說，當我們想依賴 dnssec 所承諾的安全的時候，事情變得有點複雜。

<a></a>

從 glibc 的角度來看，這個問題一部分是因為 glibc 本身并沒有做 dnssec 校驗，而是引用 /etc/resolv.conf 檔案，從該檔案裡讀出的伺服器來做解析以及校驗，再将結果傳回給應用程式。如果應用程式使用底層 res_query() 接口，那結果中将會包含“已認證資料authenticated data”（ad）辨別（如果域名伺服器設定了的話）以表示 dnssec 校驗已經成功。但是 glibc 卻完全不知道提供這些結果的域名伺服器的信用，是以它其實并不能告訴應用程式結果是否真的可靠。

由 glibc 的維護者 carlos o'donell 提出的建議是在 resolv.conf 檔案裡增加一個選項（dns-strip-dnssec-ad-bit）告訴 glibc 無條件移除 ad 辨別。這個選項可以由各發行版設定，表示 dnssec 級别的 dns 查詢結果并不可靠。而一旦建立好合适的環境可以獲得可靠的查詢結果後，再移除這個選項。這樣一來，雖然問題還沒有完全解決，至少應用程式有依據來評價從 glibc 擷取的 dns 查詢結果的可靠性。

一個可靠的環境配置應該是什麼樣？标準情況應該和這個差不太多：有一個本地域名伺服器，通過環路loopback接口通路，作為通路 /etc/resolv.conf 檔案的唯一條目。這個域名伺服器應該配置來做校驗，而在校驗失敗後就隻是簡單地不傳回任何結果。絕大多數情況下，應用程式就不再需要關心 ad 辨別，如果結果不可靠，應用程式就根本看不到。一些發行版已經傾向于這種模型，不過情況仍然不像一些人所設想的那麼簡單。

如果 glibc 不使用明确的配置選項來通知應用程式它所用的域名解析是可信的，不會有什麼用……不改一下還有很大弊端，因為應用程式開發者将馬上認識到他們不能信任從 glibc 擷取的任何資訊，進而在處理 dnssec 相關資訊時就簡單地不用它。

要配置一個系統能正常使用 dnssec 需要改動該系統的很多元件 - 這是一個發行版範圍的問題，需要時間來完全解決。在這個轉變過程中 glibc 所扮演的角色很可能會比較小，但是很重要的一部分：如果應用程式不實作一套自己的域名解析代碼，glibc 很可能是保證 dns 結果可信的唯一方式。在一個系統中運作多個 dnssec 實作方式看起來不像是一種安全的方式，是以最好還是把事情做對了。

glibc 項目目前并沒有确定用哪種方式來做這個事情，雖然從 /etc/resolv.conf 檔案裡的某些标記看上去快好了。這種改動應該需要釋出新版本；考慮到 glibc 開發的保守天性，很可能來不及加入預計二月份釋出的 2.23 版本了。是以 glibc 中暫時還不會有更高安全性的 dnssec ，不過在這個方向上也有一些進展了。

本文來自雲栖社群合作夥伴“linux中國”

原文釋出時間為：2013-04-02.