DNS 簡介
網域名稱系統 是「網際網路的電話簿」。 DNS 將網域名稱轉換為 IP 位址，以便瀏覽器和其他服務可以通過分散的伺服器網路載入網路資源。
什麼是 DNS？¶
當您訪問一個網站時，會傳回一個數字地址。 以訪問 privacyguides.org網站為例，它傳回的地址為 192.98.54.105 。
DNS 從網際網路的 早期 就存在了。 來往 DNS 伺服器的 DNS 請求通常 不是 加密的。 一般家用的網路中，客戶的伺服器通常是由 ISP 透過 DHCP給予的。
未經加密的 DNS 請求很容易被監視 或在傳輸過程中遭到修改modified。 在某些地區， ISP 被要求做初級的 DNS 過濾。 當您要求被封鎖網域的IP位址時，伺服器可能不會回應，或可能會使用其他IP位址回應。 由於DNS通訊協定沒有加密， ISP （或任何網路營運商）可以使用 DPI 來監控請求。 網路服務供應商也可以根據共同特徵封鎖請求，無論你使用哪種 DNS 伺服器。 未加密的 DNS 總是使用 53 號端口 ，並且總是使用UDP。
接下來，我們將討論並提供一個教程來證明外部觀察者可以使用普通的未加密 DNS 和 加密 DNS 看到什麼。
未加密的 DNS¶
-
使用
tshark(Wireshark專案）可以監控和記錄網路封包。 此命令記錄符合指定規則的封包：tshark -w /tmp/dns.pcap udp port 53 and host 1.1.1.1 or host 8.8.8.8 -
然後我們可以使用
dig（ Linux ， MacOS 等）或nslookup（ Windows ）將 DNS查詢發送到兩個伺服器。 Web 瀏覽器等軟體會自動執行這些查詢，除非它們被配置為使用加密的DNS。dig +noall +answer privacyguides.org @1.1.1.1 dig +noall +answer privacyguides.org @8.8.8.8nslookup privacyguides.org 1.1.1.1 nslookup privacyguides.org 8.8.8.8 -
接下來，分析結果：
wireshark -r /tmp/dns.pcaptshark -r /tmp/dns.pcap
如果執行上面的 Wireshark 命令，頂部窗格會顯示「frame」，底部窗格會顯示所選框架的所有資料。 企業過濾和監控解決方案（例如政府購買的解決方案）可以自動執行此過程，而無需人工交互，並且可以聚合這些框架以產生對網路觀察者有用的統計數據。
| 不。 | 時間 | 來源 | 目的地 | 協議 | 長度 | 資訊 |
|---|---|---|---|---|---|---|
| 1 | 0.000000 | 192.0.2.1 | 1.1.1.1 | DNS | 104 | Standard query 0x58ba A privacyguides.org OPT |
| 2 | 0.293395 | 1.1.1.1 | 192.0.2.1 | DNS | 108 | Standard query response 0x58ba A privacyguides.org A 198.98.54.105 OPT |
| 3 | 1.682109 | 192.0.2.1 | 8.8.8.8 | DNS | 104 | Standard query 0xf1a9 A privacyguides.org OPT |
| 4 | 2.154698 | 8.8.8.8 | 192.0.2.1 | DNS | 108 | Standard query response 0xf1a9 A privacyguides.org A 198.98.54.105 OPT |
觀察者可以修改這些封包。
什麼是「加密後的 DNS」 ？¶
加密 DNS 可以引用許多協議之一，最常見的是：
DNSCrypt¶
DNSCrypt 是第一種查詢加密 DNS 的方法之一。 DNSCrypt 在 443 端口上運作，與 TCP 或 UDP 傳輸協議一起使用。 DNSCrypt 從未向 Internet Engineering Task Force (IETF)提交文件 ，也未通過 Request for Comments (RFC) 流程，因此 實用少並未被廣泛使用。 因此，它大量被更受歡迎的 DNS over HTTPS 取代。
通過 TLS 的 DNS)¶
DNS over TLS 是另一種加密 DNS 通訊方式，其定義於 RFC 7858。 首次於 Android 9、iOS 14 和 Linux 上的 systemd-resolved 在版本237 提供支援。 近年來，業界偏好已經從 DoT 轉移到 DoH ，因為 DoT 協議複雜 ，並且在實現中對RFC 的遵照狀況各不相同。 DoT 還在專用端口 853 上運行，但很容易被限制性防火牆阻止。
通過 HTTPS 的 DNS)¶
DNS over HTTPS 定義在 RFC 8484 文件，封包查詢透過HTTP/2 協議，以 HTTPS 提供安全性。 最初使用於 Firefox 60 和 Chrome 83 等網頁瀏覽器。
DoH 原生執行出現在 iOS 14, macOS 11, Microsoft Windows, 與 Android 13 (不過其並未預設啟動 )。 一般 Linux 桌面支援仍待 systemd 實現， 所以 還是得安裝第三方軟體。
原生作業系統支援¶
Android¶
Android 9 以上版本支持 DoT (DNS over TLS)。 設定方式可以在以下位置找到： 設定 → 網路 & 網際網路 → 私人 DNS。
Apple裝置¶
最新版本的 iOS、iPadOS、tvOS 和 macOS 都支持 DoT 和 DoH。 這兩個通訊協議都透過 組態檔 或透過 DNS 設定 API 獲得原生支援。
安裝設定設定檔或使用 DNS 設定API 的應用程式後，即可選擇 DNS 設定。 如果啟用 VPN， 隧道內的解析將使用 VPN 的 DNS 設置，而不是設備系統的設置。
Apple不提供用於建立加密DNS設定檔的原生介面。 Secure DNS profile creator 是一款非正式工具用以建立您自己的加密 DNS 設定檔。不過這個軟體並未得到簽署。 最好是簽署過個人資設定檔；簽署會驗證個人資料的來源，並有助於確保個人資料的完整性。 綠色的「已驗證」標籤會提供給已簽署的配置文件。 代碼簽名的詳細資訊，請參閱 關於代碼簽名。
Linux¶
systemd-resolved, which many Linux distributions use to do their DNS lookups, doesn't yet support DoH. If you want to use DoH, you'll need to install a proxy like dnscrypt-proxy and configure it to take all the DNS queries from your system resolver and forward them over HTTPS.
外部人士可以看到什麼？¶
在此範例中，我們將記錄當我們提出 DoH 請求時發生的事情：
-
首先，打開
tshark：tshark -w /tmp/dns_doh.pcap -f "tcp port https and host 1.1.1.1" -
其次，使用
curl提出請求：curl -vI --doh-url https://1.1.1.1/dns-query https://privacyguides.org -
提出請求後，快速鍵 CTRL + C可停止封包捉取。
-
在 Wireshark 中分析結果：
wireshark -r /tmp/dns_doh.pcap
可看到連接建立和TLS 握手發生在加密連線時。 當查看隨後的“應用程序數據”封包時，都不包含所請求的域名或它的 IP 地址。
什麼時候 不該 使用加密的 DNS ？¶
在有網路過濾（或審查）的地方，訪問被禁止的資源可能會產生某些後果，您應該在 威脅模型中考慮這些後果。 非常 不建議把加密 DNS 用在此目的上。 使用 Tor 或 VPN 代替。 如果您使用的是VPN ，則應使用 VPN 的 DNS 伺服器。 使用 VPN 時，您已經信任它們與您的所有網路活動。
當我們進行 DNS 查詢時，通常是因為我們想要存取資源。 接下來，我們將討論一些即使在使用加密 DNS 時也可能會披露您的瀏覽活動的情況：
IP 位址¶
確定瀏覽活動的最簡單方法可能是查看您的設備正在訪問的 IP 位址。 例如，如果觀察者知道 privacyguides.org 位於 198.98.54.105，而您的裝置正在請求 198.98.54.105的數據，則很有可能您正在訪問隱私指南。
此方法僅在 IP 位址屬於僅託管少數網站的伺服器時才有用。 如果網站託管在共享平臺(例如 Github Pages ， Cloudflare Pages ， Netlify ， WordPress ， Blogger等)，它就不太有用。 如果服務器託管在 反向代理之後，這也不是很有用，這在現代互聯網上非常常見。
伺服器名指示(SNI)¶
伺服器名稱指示通常用於IP位址託管多個網站時。 這可能是像 Cloudflare 的服務，或者其他 阻斷服務攻擊 保護。
-
再次開始捕捉
tshark。 我們添加了一個自身IP 地址的過濾器，因此您不會捕獲過多封包：tshark -w /tmp/pg.pcap port 443 and host 198.98.54.105 -
在訪問網站後，以 CTRL + C停止封包捕捉。
-
接下來分析結果：
wireshark -r /tmp/pg.pcap連接建立後與 privacyguides 網站的TLS 握手。 大約在第5 幀附近。 你會看到一個“客戶你好”。
-
展開每個字段旁邊的三角形 ▸ ：
▸ Transport Layer Security ▸ TLSv1.3 Record Layer: Handshake Protocol: Client Hello ▸ Handshake Protocol: Client Hello ▸ Extension: server_name (len=22) ▸ Server Name Indication extension -
我們可以看到我們正在訪問的網站的SNI值。
tshark命令可以直接爲所有包含 SNI 封包提供值：tshark -r /tmp/pg.pcap -Tfields -Y tls.handshake.extensions_server_name -e tls.handshake.extensions_server_name
即便使用「加密 DNS」伺服器，網域也可能會透過 SNI 披露。 TLS v1.3 協議帶來 加密的 Client Hello，可防止這種洩漏。
各國政府，特別是中國< /a> 和俄羅斯，已經開始阻止它，或表達出企圖這樣做的想法。 近來俄羅斯 開始屏蔽使用 HTTP/3的外國網站。 這是因為作為HTTP/3的一部分的 QUIC 協議要求 ClientHello 也被加密。
線上憑邆狀態協議 (OCSP)¶
瀏覽器會披露瀏覽活動的另一種方式是使用 線上憑證狀態協議 (Online Certificate Status Protocol)。 訪問有 HTTPS 網站時，瀏覽器會檢查網站的 憑證 是否已被撤銷。 這是透過 HTTP 協議完成的，這意味著它不是 加密的。
OCSP 請求包含憑證，其帶有獨特的"序列號"。 它被發送到 “OCSP 回應器”去檢查其狀態。
利用 openssl 命令模擬瀏覽器會做什麼。
-
取得伺服器憑證並使用
sed來保留重要部分並將其寫入檔案：openssl s_client -connect privacyguides.org:443 < /dev/null 2>&1 | sed -n '/^-*BEGIN/,/^-*END/p' > /tmp/pg_server.cert -
取得中間憑證。 憑證授權機構(CA) 通常不會直接簽署憑證；他們使用所謂的「中間」憑證。
openssl s_client -showcerts -connect privacyguides.org:443 < /dev/null 2>&1 | sed -n '/^-*BEGIN/,/^-*END/p' > /tmp/pg_and_intermediate.cert -
pg_and_intermediate.cert中的第一個憑證實際上是步驟1 的伺服器憑證。 我們可以再次使用sed來刪除直到 END 第一個實例：sed -n '/^-*END CERTIFICATE-*$/!d;:a n;p;ba' \ /tmp/pg_and_intermediate.cert > /tmp/intermediate_chain.cert -
取得伺服器憑證的OCSP 回應器：
openssl x509 -noout -ocsp_uri -in /tmp/pg_server.cert
我們的憑證顯示 Lets Encrypt 憑證回應器。 如果我們想查看憑證的所有細節，我們可以使用：
```bash
openssl x509 -text -noout -in /tmp/pg_server.cert
```
-
開始捕取封包:
tshark -w /tmp/pg_ocsp.pcap -f "tcp port http" -
提出 OCSP 要求：
openssl ocsp -issuer /tmp/intermediate_chain.cert \ -cert /tmp/pg_server.cert \ -text \ -url http://r3.o.lencr.org -
打開捕捉資料：
wireshark -r /tmp/pg_ocsp.pcap
將會有兩個帶有「OCSP」通訊協定的封包：「Request」和「Response」。 對於“Request” ，可以通過擴展每個字段旁邊的三角形 ▸ 來看到“序列號” ：
```bash
▸ Online Certificate Status Protocol
▸ tbsRequest
▸ requestList: 1 item
▸ Request
▸ reqCert
serialNumber
```
對於“回應” ，我們也可以看到“序列號” ：
```bash
▸ Online Certificate Status Protocol
▸ responseBytes
▸ BasicOCSPResponse
▸ tbsResponseData
▸ responses: 1 item
▸ SingleResponse
▸ certID
serialNumber
```
-
或者使用
tshark來過濾序列號的封包：tshark -r /tmp/pg_ocsp.pcap -Tfields -Y ocsp.serialNumber -e ocsp.serialNumber
如果網路觀察者拿到可公開取得的公共憑證，就可將序列號與該憑證作匹配，從而確定您正在訪問的網站。 這個過程可以自動化，並且可以將IP地址與序列號相關聯。 也可檢查 憑證透明度 日誌的序列號。
我應該用加密 DNS 嗎？¶
這個流程圖描述了何時 應該使用 加密 DNS:
graph TB
Start[Start] --> anonymous{Trying to be<br> anonymous?}
anonymous--> | Yes | tor(Use Tor)
anonymous --> | No | censorship{Avoiding<br> censorship?}
censorship --> | Yes | vpnOrTor(Use<br> VPN or Tor)
censorship --> | No | privacy{Want privacy<br> from ISP?}
privacy --> | Yes | vpnOrTor
privacy --> | No | obnoxious{ISP makes<br> obnoxious<br> redirects?}
obnoxious --> | Yes | encryptedDNS(Use<br> encrypted DNS<br> with 3rd party)
obnoxious --> | No | ispDNS{Does ISP support<br> encrypted DNS?}
ispDNS --> | Yes | useISP(Use<br> encrypted DNS<br> with ISP)
ispDNS --> | No | nothing(Do nothing)與第三方合作的加密 DNS 應限於避開重定向和基本的 DNS 封鎖 ，也就是確定無後顧或對供應商的基本過濾感興趣時才用第三方。
什麼是 DNSSEC ？¶
Domain Name System Security Extensions (DNSSEC)是 DNS 的一項功能，域名查找的回應予以驗證。 它無法為查詢者提供隱私保護，而是防止攻擊者操縱或毒害對DNS 請求的回應。
換句話說， DNSSEC 對資料進行數位簽名，幫助確保其有效性。 為了確保安全查找，過程中的每個層級都會簽名。 因此，DNS 全部的回答都可以被信任。
DNSSEC 簽署過程類似於無法仿製的個人獨特簽名於法律文件，法院專家透過簽名驗證該文件效力須依據簽名的真假判定。 這些數位簽名確保資料不會被篡改。
DNSSEC 在所有 DNS 層中實施分級數位簽名政策。 例如，查詢 privacyguides.org ，根 DNS 伺服器將簽署尾綴 .org 伺服器密鑰，然後 .org 伺服器再簽署 privacyguides.org的授權名稱伺服器的密鑰。
改編自 Google 的 DNS 安全擴充 (DNSSEC) 概述 和 Cloudflare 提供的[DNSSEC：簡介](https://blog.cloudflare.com/dnssec- an -introduction），兩者皆以 CC BY 4.0 授權。
什麼是QNAME最小化？¶
QNAME 指 "合格域名"，例如 discuss.privacyguides.net. 過去，在解析網域名稱時， DNS 解析器會要求鏈中各伺服器提供關於此查詢的全部資訊。 在下面範例中，每個 DNS 伺服器提供者都會被詢問尋找 discuss.privacyguides.net IP 位址的請求：
| 伺服器 | 問題請求 | 回應 |
|---|---|---|
| 根伺服器 | Discuss.privacyguides.net 的 IP 是多少? | 不知道，請求 .net 伺服器 |
| .net 伺服器 | Discuss.privacyguides.net 的 IP 是多少? | 不知道，請求 Privacy Guides 伺服器... |
| Privacy Guides 伺服器 | Discuss.privacyguides.net 的 IP 是多少? | 5.161.195.190! |
透過“QNAME 最小化”，DNS 解析器現在只需要足夠的資訊來尋找鏈中的下一個伺服器。 在範例中，僅要求根伺服器提供足夠的資訊來尋找 .net TLD 的適當名稱伺服器等，而無需知道您嘗試造訪的完整網域：
| 伺服器 | 問題請求 | 回應 |
|---|---|---|
| 根伺服器 | 什麼是 .net 域名伺服器? | 提供 .net 伺服器 |
| .net 伺服器 | Privacyguides.net 的域名伺服器是什麼? | 提供 Privacy Guides 伺服器 |
| Privacy Guides 伺服器 | discuss.privacyguides.net 的域名伺服器是什麼? | 此伺服器 |
| Privacy Guides 伺服器 | Discuss.privacyguides.net 的 IP 是多少? | 5.161.195.190 |
雖然此過程可能稍減低效率低，但中央根網域伺服器和 TLD 網域伺服器都不會收到有關您的完整查詢的資訊，從而減少了資訊量傳輸您瀏覽習慣。 進一步的技術描述在 RFC 7816。
什麼是 EDNS 客戶端子網(ECS ) ？¶
EDNS Client Subnet 是遞歸DNS 解析器為DNS 查詢的 主機或客戶端，指定 子網絡 的方法。
它的目的是回答客戶端距離最靠近的伺服器以“加快”資料的傳遞，類似內容傳遞網絡，後者通常用於視頻串流和 JavaScript Web 應用程序。
This feature does come at a privacy cost, as it tells the DNS server some information about the client's location, generally your IP network. For example, if your IP address is 198.51.100.32 the DNS provider might share 198.51.100.0/24 with the authoritative server. Some DNS providers anonymize this data by providing another IP address which is approximately near your location.
If you have dig installed you can test whether your DNS provider gives EDNS information out to DNS nameservers with the following command:
dig +nocmd -t txt o-o.myaddr.l.google.com +nocomments +noall +answer +stats
Note that this command will contact Google for the test, and return your IP as well as EDNS client subnet information. If you want to test another DNS resolver you can specify their IP, to test 9.9.9.11 for example:
dig +nocmd @9.9.9.11 -t txt o-o.myaddr.l.google.com +nocomments +noall +answer +stats
If the results include a second edns0-client-subnet TXT record (like shown below), then your DNS server is passing along EDNS information. The IP or network shown after is the precise information which was shared with Google by your DNS provider.
o-o.myaddr.l.google.com. 60 IN TXT "198.51.100.32"
o-o.myaddr.l.google.com. 60 IN TXT "edns0-client-subnet 198.51.100.0/24"
;; Query time: 64 msec
;; SERVER: 9.9.9.11#53(9.9.9.11)
;; WHEN: Wed Mar 13 10:23:08 CDT 2024
;; MSG SIZE rcvd: 130
You're viewing the English copy of Privacy Guides, translated by our fantastic language team on Crowdin. If you notice an error, or see any untranslated sections on this page, please consider helping out! 訪問 Crowdin
You're viewing the English copy of Privacy Guides, translated by our fantastic language team on Crowdin. If you notice an error, or see any untranslated sections on this page, please consider helping out!