はじめに
RFC 7871（DNS クエリのクライアント サブネット）- Google Public DNS などの再帰リゾルバが、部分的なクライアントの IP アドレス情報を権威 DNS ネームサーバーに送信するメカニズムを定義します。コンテンツ配信ネットワーク（CDN）やレイテンシの影響を受けやすいサービスは、パブリック DNS リゾルバを介した名前ルックアップに応答するときに、正確な位置情報を含むレスポンスを提供するためにこれを使用します。
RFC は、権威ネームサーバーが実装しなければならない ECS 機能について説明していますが、実装者は必ずしもこれらの要件に従うわけではありません。また、RFC で対処されていない ECS の運用とデプロイの問題もあり、権威ネームサーバーでの ECS のサポートを自動検出する Google Public DNS などのリゾルバや、OpenDNS などの ECS 許可リストを必要とするリゾルバで問題が発生する可能性があります。
以下のガイドラインは、権威 DNS の実装者とオペレーターが ECS の問題を引き起こす可能性のある、よくある間違いを防ぐことを目的としています。
用語の定義
ECS のオペレーションでは、次の用語を使用します。
ネームサーバーは、ECS オプションがグローバルに /0 のスコープ接頭辞を持つ場合でも、ECS レスポンスで ECS レスポンスが一致する ECS クエリに応答する場合、ECS を実装（またはサポート）します。
ゼロ以外のソース接頭辞で送信されたネームサーバーへの ECS クエリがスコープがゼロ以外の ECS レスポンスを受信した場合、ゾーンは ECS が有効になります。
権威ネームサーバーに関するガイドライン
ECS 対応ゾーンのすべての権威ネームサーバーは、そのゾーンで ECS を有効にする必要があります。
- 1 つのネームサーバーのみが ECS を実装または有効化しなくても、そのゾーンがほとんどのキャッシュ データのソースになります。レスポンスには（TTL が期限切れになるまで）グローバル スコープがあるため、（クライアントのサブネットに関係なく）同じ名前のすべてのクエリに対するレスポンスとして使用されます。ECS を実装し、有効にするサーバーからのレスポンスは、特定のスコープ内のクライアントからのクエリにのみ使用されるため、グローバル スコープのレスポンスよりも使用される可能性が大幅に低くなります。
ECS を実装した権威ネームサーバーは、IP アドレスまたは NS ホスト名から提供されるすべてのゾーンの ECS クエリに ECS レスポンスを送信します。ECS が有効になっていないゾーンであっても同様です。
- Google Public DNS は、ネームサーバーのホスト名や DNS ゾーンではなく、IP アドレスによって ECS のサポートを自動的に検出します。これは、アドレスの数がネームサーバー ホスト名の数よりも少なく、DNS ゾーンの数よりもはるかに少ないためです。権威ネームサーバーが ECS クエリに ECS レスポンスを常に送信しない場合（ECS が有効になっていないゾーンであっても）、Google Public DNS はその ECS クエリの送信を停止することがあります。
ECS が実装するすべてのECS クエリとともに、否定的レスポンスや参照レスポンスを含む ECS クエリに応答する権威ネームサーバー。
ECS サポートの自動検出に関する同じ問題がここでも適用されます。
ネガティブ レスポンス（NXDOMAIN と NODATA）は、キャッシュと RFC 7871 との互換性を高めるために、グローバル /0 スコープを使用する必要があります3。
NXDOMAIN と NODATA（空の回答セクションのある NOERROR）の他に、ECS クエリに対する他のエラー レスポンス（特に SERVFAIL と REFused）には、グローバル /0 スコープを持つ一致する ECS オプションを含める必要があります。
権威ネームサーバーが DoS 攻撃から負荷を減らそうとすると、ECS データのない SERVFAIL が返される場合があります。これを繰り返すと、Google Public DNS が ECS を含むクエリの送信を停止してしまいます（この場合、正当なクエリの数は減りますが、ランダムなサブドメイン攻撃のクエリには影響しません）。DoS 攻撃中の正当なクエリ負荷を軽減することで、正当なクエリの成功率が向上する場合があります（ただし、すべてのクライアントのキャッシュからレスポンスが提供される場合があります）。
より効果的な負荷制限アプローチでは、Google Public DNS が引き続き ECS クエリを送信できるように、グローバル /0 スコープですべてのレスポンスを送信します。 これにより、グローバル スコープ レスポンス TTL の有効期限が切れた後に再クエリするだけで ECS サポートを再検出する必要がなくなるため、Google Public DNS は攻撃が停止された後に位置情報レスポンスを返すことができます。
紹介（委任）レスポンスにも ECS データが一致する必要があり、必要4 はグローバル /0 スコープを使用すべきです。委任レスポンスは、アドレスが ECS データに含まれるクライアントに転送されないため、位置情報のある NS、A、AAAA レコードは、ECS データではなく、リゾルバのクライアント IP アドレスによって選択される必要があります。
ECS を実装する権威ネームサーバーには、ECS オプション付きで受信されるすべてのクエリタイプに応じて、それに対応する ECS オプションを含める必要があります。 IPv4 アドレス（A）クエリに対して ECS データを返すには不十分です。A、AAAA、PTR、MX、その他のクエリタイプに対するレスポンスは、一致する ECS データを持っている必要があります。そうでない場合、Google Public DNS は ECS データとともにクエリの送信を停止する可能性があります。
特に、SOA、NS、DS クエリに対する ECS レスポンスは、常にグローバル /0 スコープを使用してキャッシュを改善し、委任の整合性を保つ必要があります（ネームサーバー ホスト名の A/AAAA クエリに対する位置情報に関するレスポンスは問題ありません）。ECS データに基づいて変更されないクエリタイプ（TXT、PTR など）へのレスポンスでは、ソース プレフィックス長と同じスコープを使用しないでください。キャッシュの改善とクエリ負荷の軽減のために、グローバル /0 スコープを使用する必要があります。
ECS 対応の CNAME レスポンスを返す権威ネームサーバーは、5 チェーンの最初の CNAME のみを含めるべきであり、CNAME チェーンの最終ターゲットは同じスコープ プレフィックス長に ECS 対応にする必要があります。ECS 仕様の曖昧さにより、一部の再帰リゾルバ（特に Unbound6）は、最終的な非 CNAME ドメインのスコープ（ECS が有効になっていない場合は /0）を含むレスポンスを返すことがあります。
ECS データには IPv6 アドレスのみが含まれる場合があります（IPv4 のみのネームサーバーであってもまれです）。
ネームサーバーは、有効な ECS オプション データで応答する必要があります（スコープ /0 は有効ですが、送信元アドレスとプレフィックスの長さが一致している必要があります）。
ゾーンの ECS は、IPv4 アドレスと IPv6 アドレスに対して個別に有効にできます。
ECS 対応のレスポンスを返す権威ネームサーバーは、回答の中でスコープ接頭辞を重複してはなりません7。スコープのプレフィックスが重複している例は次のとおりです。
ソース接頭辞が
198.18.0.0/15のクエリ: スコープ接頭辞が198.0.0.0/8のレスポンス Aソース接頭辞が
198.51.100/24のクエリ: スコープ接頭辞が198.51.0.0/16のレスポンス B
クライアントが上記の順序で ECS 対応の再帰リゾルバをクエリすると、キャッシュに保存されたレスポンス A のスコープに 2 番目のクエリの接頭辞スコープが含まれるため、両方のクエリにレスポンス A が返される場合があります。クライアント クエリが逆の順序で行われ、両方のクエリが権威ネームサーバーに転送されても、キャッシュに保存されたレスポンスの有効期限が異なる場合があります。それ以降の重複する接頭辞
198.51.100/24の再帰リゾルバに対するクエリは、レスポンス A または B のいずれかになります。ネームサーバーに ECS サポートを初めて実装する場合は、これらの ECS に対応するゾーンに対応するネームサーバーに新しい IP アドレスを使用します。
ECS を実装したが、グローバル スコープの結果を返した権威ネームサーバーが、ゾーンに対して ECS の有効な回答を返し始めた場合、Google Public DNS は以前のグローバル スコープのレスポンスの TTL が期限切れになってすぐに、クエリに対する位置情報付きのレスポンスを返すようになります。
ECS サポートの Google Public DNS 自動検出は、ECS サポートの欠如（タイムアウト、FORMERR の返却、BADVERS、または ECS 以外のレスポンスの送信）を検出した場合に、IP アドレス（またはネームサーバー ホスト名）に対する ECS クエリを行うことはほとんどありません。これらの IP アドレス（または NS ホスト名）への新しい ECS 実装は、自動検出されるまでの時間が非常に遅いか、まったく検出されません。
ネットワーク接続の信頼性と、レスポンス レート制限が十分に高く設定されていて、ネームサーバーでクエリがドロップされないようにします（さらに悪いことに、一致する ECS オプションがないエラーで応答します）。
- ECS クエリに対するレスポンス レート制限を実装するネームサーバーの場合、最適な応答は、一致する質問セクションと一致する ECS オプションのみを含む切り捨て（TC）フラグが設定された NODATA です。
すべてのクエリにタイムリーなレスポンスを送信します（できれば 1 秒以内）。
- ECS クエリでオンラインの Geo-IP ルックアップ サービスを使用しても、DNS クエリとオンラインの Geo-IP サービスの累積レイテンシが 1 秒を超える可能性は低いため、確実に機能しません。Google Public 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 inSection 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 チェーン内の最終ドメインのスコープの使用は、Unbound では無害です。これは通常、ローカル スタブまたは転送リゾルバとしてデプロイされ、すべてのクライアントが同じサブネット内にあり、同じレスポンスを受け取るためです。
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:
Deaggregate the shorter prefix response into multiple longer prefix responses, or
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.