EDNS-Client-Subnet

1. RFC 7871 に書かれているもの

EDNS-Client-Subnet ( 以下 ECS ) クエリに対する挙動の定義が書かれている。権威サーバやリゾルバが ECS クエリをどう扱うか。

RFC 7871 - Client Subnet in DNS Queries https://tools.ietf.org/html/rfc7871

ENDS0 の知識が前提になっている部分があるので RFC 6891 を読んでおくと良い。

2. Terminology and Concept

最小構成だと以下のような形になる。フォワーダなどは省略している。

[Client] - [Resolver] - [Authoritative Nameserver]

また、単語は以下のように略記する。

Stub Resolver -> SR
Recursive Resolver -> RNS
Authoritative Nameserve -> ANS

3. 概要と抄訳

3.1. Overview

そもそも ECS は何をするものか。

ユーザの場所に応じて応答を変えたいとか、そういった要求に応えるもの。今まではトポロジ的にスタブとリゾルバが近い位置あったが、いまはそうとも言えない。 (Google Public DNS とか ISP の提供する DNS サーバとか) そこで、クライアント (originator) のネットワークの情報を運ぶような仕組みが ECS である。

3.2. フォーマット

OPT RR の Option に以下のような形で入れられる。

…
Additional records
    <Root>: type OPT
        Name: <Root>
        Type: OPT (41)
        UDP payload size: 4096
        Higher bits in extended RCODE: 0x00
        EDNS0 version: 0
        Z: 0x0000
        Data length: 11
        Option: CSUBNET - Client subnet
            Option Code: CSUBNET - Client subnet (8)
            Option Length: 7
            Option Data: 00011800503a3d
            Family: IPv4 (1)
            Source Netmask: 24
            Scope Netmask: 0
            Client Subnet: 80.58.61.0

また、実際のパケットフォーマットとしては以下の形を持つ。

こちらに登場する単語を説明しておく。

SOURCE PREFIX-LENGTH クライアント (originator) のネットワークの範囲レスポンスでは同じ値をそのまま返す
SCOPE PREFIX-LENGTH レスポンスの際に利用したネットワークの範囲リクエストでは 0 が入れられる
ADDRESS クライアント (originator) が提示するネットワークの IP アドレス

3.3. クエリの扱い

3.3.1. ECS の有効化

7.1. Originating the Option

The ECS option should generally be added by Recursive Resolvers when querying Authoritative Nameservers, as described in Section 12. The option can also be initialized by a Stub Resolver or Forwarding Resolver.

リゾルバにて有効化されるものである。ただ、スタブやフォワーダでも有効化できる。例えば dig 9.11 では subnet オプションが使える。 ( 例: +subnet=208.67.222.0/24 )

3.3.2. Recursive Resolvers の動作

7.1.1. Recursive Resolvers

In the usual case, where no ECS option was present in the client query, the Recursive Resolver initializes the option by setting FAMILY of the client's address. It then uses the value of its maximum cacheable prefix length to set SOURCE PREFIX-LENGTH. For privacy reasons, and because the whole IP address is rarely required to determine a tailored response, this length SHOULD be shorter than the full address, as described in Section 11.

通常、クライアントから ECS オプションが付加されずにリゾルバにリクエストがあった場合、リゾルバでクライアントの IP アドレスを使って付加する。この時、 maximum cacheable prefix の設定が可能で (プロトコル仕様ではなくソフトウェアの話) 、それが SOURCE PREFIX-LENGTH となる。プライバシー上の理由からまるまる /32 を利用するすべきではない。そもそも ANS 側でも /32 でレスポンスを分けている例なんて殆ど無いし。

7.1.1. Recursive Resolvers

If the triggering query included an ECS option itself, it MUST be examined for its SOURCE PREFIX-LENGTH. The Recursive Resolver's outgoing query MUST then set SOURCE PREFIX-LENGTH to the shorter of the incoming query's SOURCE PREFIX-LENGTH or the server's maximum cacheable prefix length.

リゾルバへのクエリに ECS オプションが含まれていた場合はその SOURCE PREFIX-LENGTH を確認しなくてはならない。リゾルバからのクエリは、「リゾルバに入ってきたクエリが持っていた SOURCE PREFIX-LENGTH 」か「 maximum cacheable prefix の長さ」かどちらかの短い方を SOURCE PREFIX-LENGTH にセットしないといけない。 (shorter ってのは prefix value が小さい、つまりネットワーク的には広い、方を意味していると理解。わかりにくい。)

7.1.1. Recursive Resolvers

Finally, in both cases, SCOPE PREFIX-LENGTH is set to 0 and ADDRESS is then added up to SOURCE PREFIX-LENGTH number of bits, with trailing 0 bits added, if needed, to fill the final octet. The total number of octets used MUST only be enough to cover SOURCE PREFIX- LENGTH bits, rather than the full width that would normally be used by addresses in FAMILY.

SCOPE PREFIX-LENGTH には 0 がセットされ、 ADDRESS には SOURCE PREFIX-LENGTH を満たすように末尾を 0 埋めする。

7.1.1. Recursive Resolvers

Subsequent queries to refresh the data MUST, if unrestricted by an incoming SOURCE PREFIX-LENGTH, specify the longest SOURCE PREFIX- LENGTH that the Recursive Resolver is willing to cache, even if a previous response indicated that a shorter prefix length was sufficient.

データをリフレッシュするような連続した問い合わせは、受信した SOURCE PREFIX-LENGTH による制限が無ければ、もし短いプレフィックス長で十分だと前のレスポンスが示していても、リゾルバがキャッシュしたい最長の SOURCE PREFIX-LENGTH を指定する必要がある。 (わかりにくい)

3.3.3. Stub の動作

7.1.2. Stub Resolvers

A SOURCE PREFIX-LENGTH value of 0 means that the Recursive Resolver MUST NOT add the client's address information to its queries. The subsequent Recursive Resolver query to the Authoritative Nameserver will then either not include an ECS option or MAY optionally include its own address information, which is what the Authoritative Nameserver will almost certainly use to generate any Tailored Response in lieu of an option. This allows the answer to be handled by the same caching mechanism as other queries, with an explicit indicator of the applicable scope. Subsequent Stub Resolver queries for /0 can then be answered from this cached response.

SOURCE PREFIX-LENGTH に 0 がセットされていたら、 RNS はクライアントの IP アドレスの情報を追加してはいけない。 (MUST NOT) ただ、後続の RNS から ANS への ECS オプションが含まれていないクエリや意図的に自分のアドレスを含めたクエリに対しては、 ANS は Tailored Response を返す可能性がある。つまり、リゾルバがキャッシュを持っていたとしたら SOURCE PREFIX-LENGTH が 0 のクエリにも Tailored Response が返されることがある。

3.4. レスポンス

基本的なところは想像通りというか EDNS0 と変わらない。 ECS が実装されていない ANS は、 ECS オプションを無視しないといけないとか、フォーマットがおかしければ FORMERR を返すとか、 ANS が ECS を実装しているなら ECS Option 付きの応答には ECS Option をつけて返すとか。注目ポイントは以下。

3.4.1. ANS からのレスポンス

7.2.1. Authoritative Nameserver

A SCOPE PREFIX-LENGTH value longer than SOURCE PREFIX-LENGTH indicates that the provided prefix length was not specific enough to select the most appropriate Tailored Response. Future queries for the name within the specified network SHOULD use the longer SCOPE PREFIX-LENGTH. Factors affecting whether the Recursive Resolver would use the longer length include the amount of privacy masking the operator wants to provide their users, and the additional resource implications for the cache.

SCOPE PREFIX-LENGTH が SOURCE PREFIX-LENGTH より長い場合 (ネットワーク的に SCOPE のほうが狭い場合) は、 RNS が渡したプレフィックス長が ANS が最も適切な Tailored Response を返すには不十分である事がわかる。 (これはつまり、例えば ANS が /24 括りで情報を持っているのに /16 で聞いてしまっているのでどれが適切か判断できないということ) このネットワーク範囲内へのクエリについては、より長い SCOPE PREFIX-LENGTH を使用するべきである。 (短く切り詰めて返してしまうとキャッシュに悪影響を及ぼす、ということか？よくわからん。) リゾルバがより長い length を利用するかどうかに影響する要素としては、管理者がプライバシーポリシー的にどれだけマスキングしたいかということと、キャッシュに対するリソースを追加で要することが含まれる。

7.2.1. Authoritative Nameserver

Conversely, a shorter SCOPE PREFIX-LENGTH indicates that more bits than necessary were provided, and the answer is suitable for a broader range of addresses. This could be as short as 0, to indicate that the answer is suitable for all addresses in FAMILY.

逆に SCOPE PREFIX-LENGTH が短い場合は、 RNS から渡された情報が必要以上に細かいということ。つまりボーダーレンジのアドレスに対する応答としてはふさわしい。または 0 (つまり全ての範囲に対する応答) にもなり得る。

7.2.1. Authoritative Nameserver

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.

/20 を持ちつつ別でそのレンジ内の /24 の情報を持ちたい、みたいなのは無理。リクエスト時のプレフィックス長がどうなるかは保証できないので、 ANS はプレフィックスをオーバーラップしてはいけない。

3.4.2. 中間サーバの処理

レスポンスの際は、そもそもクライアントからのリクエストについて考慮する必要がある。クライアントからのリクエストが ECS オプションを含んでいなければ、返してはいけない。 (MUST NOT) クライアントからのリクエストが ECS オプションを含んでいれば、返さないといけない。 (MUST)

If an Intermediate Nameserver receives a response that has a longer SCOPE PREFIX-LENGTH than SOURCE PREFIX-LENGTH that it provided in its query, it SHOULD still provide the result as the answer to the triggering client request even if the client is in a different address range. The Intermediate Nameserver MAY instead opt to retry with a longer SOURCE PREFIX-LENGTH to get a better reply before responding to its client, as long as it does not exceed a SOURCE PREFIX-LENGTH specified in the query that triggered resolution, but this obviously has implications for the latency of the overall lookup.

もし中間サーバが SCOPE のほうが長い (ネットワーク的に狭い) レスポンスを受け取ったら、それはそのままクライアントに返されるべきである。または SOURCE を長くしてリトライするという方法もある。

3.5. キャッシュ動作

まず、キャッシュ動作としてはそれぞれのネットワークレンジごとに Answer section がキャッシュされないといけない。 (MUST) これらは、 SOURCE PREFIX-LENGTH や SCOPE PREFIX-LENGTH および RNS の maximum cacheable prefix length に依存する。

7.3.1. Caching the Response

If SCOPE PREFIX-LENGTH is not longer than SOURCE PREFIX-LENGTH, store SCOPE PREFIX-LENGTH bits of ADDRESS, and then mark the response as valid for all addresses that fall within that range.

もし SCOPE が SOURCE より長くない場合 (ネットワーク的には SCOPE のほうが広いか同じ) は、 SCOPE PREFIX-LENGTH をプレフィックスとして使ってキャッシュする。また、そのレンジに対するリクエストに対しても妥当なものであるとマークしておく。 (SOURCE からより細かい情報が提供されてるからオーケーという感じ。より細かい情報を期待しても ANS が持ってないので。)

7.3.1. Caching the Response

Similarly, if SOURCE PREFIX-LENGTH is the maximum configured for the cache, store SOURCE PREFIX-LENGTH bits of ADDRESS, and then mark the response as valid for all addresses that fall within that range.

また、 SOURCE PREFIX-LENGTH がキャッシュ最大値に相当する場合は SOURCE PREFIX-LENGTH をキャッシュする。そのレンジに対するリクエストについても同様。

7.3.1. Caching the Response

If SOURCE PREFIX-LENGTH is shorter than the configured maximum and SCOPE PREFIX-LENGTH is longer than SOURCE PREFIX-LENGTH, store SOURCE PREFIX-LENGTH bits of ADDRESS, and then mark the response as valid only to answer client queries that specify exactly the same SOURCE PREFIX-LENGTH in their own ECS option.

もし SOURCE PREFIX-LENGTH がキャッシュ最大値より短く、 SCOPE PREFIX-LENGTH が SOURCE PREFIX-LENGTH より長い場合は、 SOURCE PREFIX-LENGTH をキャッシュするものの完全に同じ SOURCE PREFIX-LENGTH に対してしかそのキャッシュは使わない。

7.3.1. Caching the Response

Records that are cached as /0 because of a query's SOURCE PREFIX- LENGTH of 0 MUST be distinguished from those that are cached as /0 because of a response's SCOPE PREFIX-LENGTH of 0. The former should only be used for other /0 queries that the Intermediate Resolver receives, but the latter is suitable as a response for all networks.

SOURCE が /0 だから /0 でキャッシュされたものと、レスポンスの SCOPE が /0 だから /0 でキャッシュされたものは区別しないといけない。 (MUST) 前者は、中間のリゾルバが受け取った他の /0 のクエリに対してのみ使われるべきで、後者はすべてのネットワークに対してのレスポンスとして有効である。

3.5.1. キャッシュからの応答

キャッシュの検索は通常のクエリ同様 <name, type, class> のタプルで行われる。その後、 longest prefix matching により応答が選択される。クライアントアドレスについては以下のように中間サーバに決められる。

ECS Option が提供されていない場合クライアントの IP アドレスが使われる。 (7.1.1 で説明済み)
ECS Option が提供されており、 SOURCE PREFIX-LENGTH と ADDRESS がクライアント IP をカバーしている場合クライアントの IP アドレスが使われるが、 SOURCE PREFIX-LENGTH は無視される。その後、カバーしているエントリがなく、 SOURCE PREFIX-LENGTH がキャッシュ最大値より短い場合、 SOURCE PREFIX-LENGTH と完全一致するものを探す。 These special entries, which do not cover longer prefix lengths, occur as described in the previous section. (これがよくわからなかったので翻訳していない。)

4. キャッシュ動作に関して

キャッシュ動作がわかりにくいので、以下にまとめる。

4.1. 前提

SOURCE PREFIX-LENGTH の決め方についておさらい。

if ( リゾルバへのリクエストに ECS オプションが付加されている ) {
    SOURCE PREFIX-LENGTH =  min (「リゾルバに入ってきたクエリが持っていた SOURCE PREFIX-LENGTH」,「maximum cacheable prefix の長さ」)
} else {
    SOURCE PREFIX-LENGTH = maximum cacheable prefix
}

こうなる。この前提が無いと RFC 7871 の「7.3.1. Caching the Response」が意味不明で超大変。いや、この前提がわかってても読みにくいに変わりない。

4.2. 動作

以下 3 パターンに大別される。

4.2.1. パターン 1

もし SCOPE が SOURCE より長くない (ネットワーク的には SCOPE のほうが広いか同じ) 場合は、 SCOPE PREFIX-LENGTH をプレフィックスとして使ってキャッシュする。また、そのレンジに対するリクエストに対しても妥当なものであるとマークしておく。

なぜ？ SOURCE からより細かい情報が提供されてるからオーケーという感じ。より細かい情報を期待しても ANS が持ってないので。

4.2.2. パターン 2

SOURCE PREFIX-LENGTH が maximum cacheable prefix length に相当する場合は SOURCE PREFIX-LENGTH をキャッシュする。また、そのレンジに対するリクエストに対しても妥当なものであるとマークしておく。

なぜ？ 「maximum cacheable prefix length に相当する」＝「in-coming query に ECS オプションが無かったか、 in-coming query の SOURCE PREFIX-LENGTH が maximum cacheable prefix より長くて(ネットワーク的に細かくて)切り詰められたか」となる。 (下の例では in-coming query にて /28 で聞かれたものを /24 として聞いてる) この時 /28 を持つことはできない。なぜならその名の通り maximum cacheable prefix が /24 なので、これより大きい値は持てない。

仮に SCOPE が /16 とかであればパターン 1 に該当するので SCOPE がキャッシュされる(はず)。 RFC に明記されていないのでとてもわかりにくいが、そういうことだと理解している…。

4.2.3. パターン 3

もし SOURCE PREFIX-LENGTH が maximum cacheable prefix より短く、 SCOPE PREFIX-LENGTH が SOURCE PREFIX-LENGTH より長い場合は、 SOURCE PREFIX-LENGTH をキャッシュする。注意点として、完全に同じ SOURCE PREFIX-LENGTH に対してしかそのキャッシュは使わない。

なぜ？ /28 をキャッシュしない理由としてはリゾルバへの in-coming query が /24 なので、もっと細かい値で聞かれたときに ANS はもっと細かい情報を知っている可能性があり、それをキャッシュで返すのは良くない。そのため、完全に同じ SOURCE PREFIX-LENGTH に対してしかそのキャッシュは使わないという注意書きがある。

※ /0 について 上に書いた、この文章も、 /0 を上のものに適用するとマッチする。つまり、 /0 でもこの考え方は変わらない。

SOURCE が /0 だから /0 でキャッシュされたものと、レスポンスの SCOPE が /0 だから /0 でキャッシュされたものは区別しないといけない。 (MUST) 前者は、中間のリゾルバが受け取った他の /0 のクエリに対してのみ使われるべきで、後者はすべてのネットワークに対してのレスポンスとして有効である。

PreviousENDS Options in dig NextNSID Option

Last updated 21 hours ago

Good night

1. RFC 7871 に書かれているもの

2. Terminology and Concept

3. 概要と抄訳

3.1. Overview

3.2. フォーマット

3.3. クエリの扱い

3.3.1. ECS の有効化

3.3.2. Recursive Resolvers の動作

3.3.3. Stub の動作

3.4. レスポンス

3.4.1. ANS からのレスポンス

3.4.2. 中間サーバの処理

3.5. キャッシュ動作

3.5.1. キャッシュからの応答

4. キャッシュ動作に関して

4.1. 前提

4.2. 動作

4.2.1. パターン 1

4.2.2. パターン 2

4.2.3. パターン 3