EDNS 用戶端子網路 (ECS) 指南

引言

RFC 7871：DNS 查詢中的用戶端子網路，定義遞迴解析器 (例如 Google 公用 DNS) 的機制，可將部分用戶端 IP 位址資訊傳送至權威的 DNS 名稱伺服器。內容傳遞聯播網 (CDN) 和容易受到延遲時間影響的服務會在透過公開 DNS 解析器回覆名稱查詢時，提供正確的地理位置回應。

RFC 會說明權威名稱伺服器必須實作的 ECS 功能，但實作者不一定會遵循這些要求。另外，RFC 也會處理 ECS 作業和部署問題，這可能會導致問題發生 (例如 Google 公用 DNS) 會自動偵測權威名稱伺服器中的 ECS 支援，以及需要 ECS 許可清單的解析器 (例如 OpenDNS)。

這些指南旨在協助具公信力的 DNS 實作者和運算子避免產生許多常見的 ECS 錯誤。

條款定義

以下字詞用於說明 ECS 作業：

  • 如果名稱伺服器以含有相符 ECS 選項的 ECS 回應回覆，則名稱伺服器會實作 (或支援) ECS，即使 ECS 選項一律具有全域 /0 範圍前置字串長度也一樣。

  • 若 ECS 查詢到使用非零來源前置字串傳送的名稱伺服器，而可用區已啟用 ECS，則您會收到非零範圍的 ECS 回應。

權威名稱伺服器指南

  1. 對於已啟用 ECS 的可用區，所有權威名稱伺服器都必須為該可用區啟用 ECS。

    • 即使只有一個名稱伺服器「實作」 ECS 或為可用區啟用該 IP 位址，它仍會迅速成為大部分快取資料的來源。因為其回應具有全域範圍，因此使用它們 (直到存留時間到期) 做為對相同名稱「所有」查詢的回應 (無論用戶端子網路為何)。如果伺服器的回應「已」實作並啟用 ECS，該回應只會用於特定範圍內用戶端的查詢，因此使用頻率遠低於全域範圍回應。

  2. 實作 ECS 的權威名稱伺服器 MUST2 可為所有從 IP 位址或 NS 主機名稱提供服務的 ECS 查詢傳送 ECS 回應，即使是未啟用ECS 的區域亦然。

    • Google如果權威名稱伺服器不會將 ECS 回應傳送至 ECS 查詢 (即使未啟用 ECS 的區域)，Google 公用 DNS 可能會停止傳送 ECS 查詢。

  3. 實作 ECS 的權威名稱伺服器必須透過 ECS 回應回應所有 ECS 查詢，包括負面和參照連結網址回應。

    • 這也同樣適用於 ECS 支援自動偵測的問題。

    • 負面回應 (NXDOMAIN 和 NODATA) SHOULD3 使用全域 /0 範圍，以獲得更好的快取與 RFC 7871 相容性。

    • 除了 NXDOMAIN 和 NODATA (含有空白答案部分的 NOERROR) 之外，對 ECS 查詢的其他錯誤回應 (尤其是 SERVFAIL 和 REFUSE) 應含有具有全域 /0 範圍的 ECS 選項。

      • 如果權威名稱伺服器嘗試從 DoS 攻擊中載入負載，即可傳回不含 ECS 資料的 SERVFAIL；重複以上步驟會導致 Google 公用 DNS 停止傳送 ECS 查詢 (這可能會降低傳送的合法查詢數量，但不會影響隨機子網域攻擊)。在 DoS 攻擊期間減少合法查詢負載，但不一定有助於改善有效查詢的成功率 (但可透過所有用戶端的快取提供回應)。

        更有效的負載清除方法，就是以全域 /0 範圍傳送「所有」回應，讓 Google 公用 DNS 繼續傳送 ECS 查詢。這樣一來，Google 公用 DNS 很快就會在攻擊停止後傳回地理位置資訊回應，因為您不需要在全域範圍回應 TTL 結束後重新查詢。

    • 推薦 (委派) 回應也必須有相符的 ECS 資料，且 SHOULD4 使用全域 /0 範圍。請注意，委派回應一律不會轉送至地址位於 ECS 資料中的用戶端，因此任何地理位置的 NS、A 或 AAAA 記錄都應由 Resolver's 用戶端 IP 位址選取，而非 ECS 資料。

  4. 實作 ECS 的權威名稱伺服器必須包含透過 ECS 選項接收的所有查詢類型。無法回應包含 ECS 資料的 IPv4 位址 (A) 查詢不足；針對 A、AAAA、PTR、MX 或任何其他查詢類型的回覆必須含有相符的 ECS 資料或解析器，以免回應偽造的結果，而 Google 公用 DNS 可能會停止傳送含有 ECS 資料的查詢。

    特別是，對 SOA、NS 和 DS 查詢的 ECS 回應應一律使用全域 /0 範圍，以獲得更好的快取效果，並享有一致的委派檢視畫面 (對於名稱伺服器主機名稱，用於 A/AAAA 查詢的地理位置回應正常)。 任何查詢類型 (例如 TXT、PTR 等等) 的回應不會根據 ECS 資料變更，都不應使用與來源前置字串長度相同的範圍，因此應該使用全域 /0 範圍，以獲得更好的快取量並減少查詢負載。

  5. 傳回已啟用 ECS 的 CNAME 回應的權威名稱伺服器 SHOULD5 只包含鏈結中的第一個 CNAME，且 CNAME 鏈結的最終目標也應啟用與 ECS 相同的範圍前置字串。由於 ECS 規格中的歧義，某些遞迴解析器 (尤其是 Unbound6) 可能會傳回包含最終非 CNAME 網域範圍的回應 (如果未啟用 ECS，則為 /0)。

  6. ECS 資料可能包含 IPv6 位址，即使是僅限 IPv4 的名稱伺服器，反之亦然。不過，很少的 IPv6 名稱伺服器很少見。

    • 名稱伺服器須搭配有效的 ECS 選項資料進行回應 (/0 範圍可正常，但來源地址和前置字串長度「必須」相符)。

    • 您可以為 IPv4 和 IPv6 位址個別啟用區域的 ECS。

  7. 傳回已啟用 ECS 回應的權威名稱伺服器不得7在答案中重疊範圍前置字串。以下是重疊範圍前置字串的範例：

    • 來源前置字串為 198.18.0.0/15 的查詢：回應 A 的範圍為 198.0.0.0/8

    • 來源前置字串為 198.51.100/24 的查詢：回應 B 的範圍範圍為 198.51.0.0/16

    即使用戶端查詢以相反的順序執行，而且這兩項查詢都會轉送至權威名稱伺服器，快取回應的時間則有可能在不同時間；後續在前置字串 198.51.100/24 中對遞迴解析器的查詢可能會取得回應 A 或 B。

  8. 首次在名稱伺服器實作 ECS 支援時，請為提供這些 ECS 啟用區域的名稱伺服器使用新 IP 位址。

    • 當「實作」ECS 但傳回全域範圍結果的權威名稱伺服器開始傳回已啟用區域的 ECS 答案時，Google 公用 DNS 會隨即在地理位置傳回回應，直到先前全域範圍回應的存留時間到期為止。

    • 如果 Google 公用 DNS 自動偵測為 ECS 支援，在 IP 位址自動偵測到 ECS 支援 (逾時、傳回 FORMERR、BADVERS 或傳送非 ECS 回應) 時，幾乎很少嘗試對 IP 位址 (或名稱伺服器主機名稱) 進行 ECS 查詢。系統會自動偵測這些 IP 位址 (或 NS 主機名稱) 的新 ECS 實作執行速度非常慢，甚至完全偵測不到。

  9. 請確認網路連線穩定，且任何回應頻率限制夠高，名稱伺服器才能捨棄查詢 (或傳回錯誤來缺少缺少的 ECS 選項)。

    • 如果名稱伺服器在 ECS 查詢中實作回應頻率限制，最佳回應方式為 NODATA 的截斷 (TC) 標記集，其中僅包含相符的問題區段和相符的 ECS 選項。

  10. 及時傳送所有查詢 (最好在 1 秒內)。

    • 針對 ECS 查詢使用線上 Geo-IP 查詢服務會很不穩定，因為 DNS 查詢和線上 Geo-IP 服務的累計延遲時間不可能在一秒內。Google 公開 DNS 支援偵測 ECS 支援會將延遲回應視為 ECS 支援不佳或不完整，並且減少日後透過 ECS 傳送查詢的可能性。一旦回應超過足夠的時間，系統就會停止傳送 ECS 查詢。

RFC 7871 參考資料和其他註腳

1。https://tools.ietf.org/html/rfc7871#page-12

FAMILY, SOURCE PREFIX-LENGTH, and ADDRESS in the response MUST match those in the query. Echoing back these values helps to mitigate certain attack vectors, as described in Section 11.

2。https://tools.ietf.org/html/rfc7871#section-7.2.1

An Authoritative Nameserver that implements this protocol and receives an ECS option MUST include an ECS option in its response to indicate that it SHOULD be cached accordingly, regardless of whether the client information was needed to formulate an answer.

3。https://tools.ietf.org/html/rfc7871#section-7.4

It is RECOMMENDED that no specific behavior regarding negative answers be relied upon, but that Authoritative Nameservers should conservatively expect that Intermediate Nameservers will treat all negative answers as /0; therefore, they SHOULD set SCOPE PREFIX-LENGTH accordingly.

4 https://tools.ietf.org/html/rfc7871#section-7.4

The delegations case is a bit easier to tease out. In operational practice, if an authoritative server is using address information to provide customized delegations, it is the resolver that will be using the answer for its next iterative query. Addresses in the Additional section SHOULD therefore ignore ECS data, and the Authoritative Nameserver SHOULD return a zero SCOPE PREFIX-LENGTH on delegations.

5 https://tools.ietf.org/html/rfc7871#page-12

For the specific case of a Canonical Name (CNAME) chain, the Authoritative Nameserver SHOULD only place the initial CNAME record in the Answer section, to have it cached unambiguously and appropriately. Most modern Recursive Resolvers restart the query with the CNAME, so the remainder of the chain is typically ignored anyway.

6 https://unbound.net/pipermail/unbound-users/2015-May/003875.html

在 CNAME 鏈結中，使用最終網域範圍是無害的，因為其通常會部署為本機虛設常式或轉送解析器，因為所有用戶端都位於同一個子網路中，且會獲得相同的回應。

7。https://tools.ietf.org/html/rfc7871#page-13

Authoritative Nameservers might have situations where one Tailored Response is appropriate for a relatively broad address range, such as an IPv4 /20, except for some exceptions, such as a few /24 ranges within that /20. Because it can't be guaranteed that queries for all longer prefix lengths would arrive before one that would be answered by the shorter prefix length, an Authoritative Nameserver MUST NOT overlap prefixes.

When the Authoritative Nameserver has a longer prefix length Tailored Response within a shorter prefix length Tailored Response, then implementations can either:

  1. Deaggregate the shorter prefix response into multiple longer prefix responses, or

  2. Alert the operator that the order of queries will determine which answers get cached, and either warn and continue or treat this as an error and refuse to load the configuration.

…

When deaggregating to correct the overlap, prefix lengths should be optimized to use the minimum necessary to cover the address space, in order to reduce the overhead that results from having multiple copies of the same answer. As a trivial example, if the Tailored Response for 1.2.0/20 is A but there is one exception of 1.2.3/24 for B, then the Authoritative Nameserver would need to provide Tailored Responses for 1.2.0/23, 1.2.2/24, 1.2.4/22, and 1.2.8/21 all pointing to A, and 1.2.3/24 to B.