--subnet accepts an out-of-range prefix length without validation

[toshi0806]

現象

--subnet の prefix 長が検証されていない。負の値がそのまま EDNS Client Subnet オプションの source_prefix になる。

$ # Tdig.CLI.parse_subnet_option/1 の実測
192.0.2.1/24:   source_prefix: 24
192.0.2.1/-5:   source_prefix: -5     ← 負値がそのまま通る
192.0.2.1/999:  source_prefix: 32     ← 上限だけは効く
2001:db8::1/-1: source_prefix: -1

原因

lib/tdig/cli.ex の parse_subnet_option/1 が

prefix = String.to_integer(prefix_str)
...
source_bits = min(prefix, 32)   # IPv6 側は min(prefix, 128)

としており、min/2 は上限しか抑えない。下限のチェックが無く、String.to_integer/1 は "-5" を素直に -5 にする。

RFC 7871 の SOURCE PREFIX-LENGTH は 8 bit の符号なし整数なので、負値は表現できない。

影響

パケット組み立て側の扱い次第だが、いずれにせよ利用者の意図しないクエリが送られる。dig は +subnet=192.0.2.1/-5 を invalid prefix length で拒否する。

検討事項

挙動の変更を伴うため、方針を決める必要がある。

1. 範囲外をエラーにする（dig に合わせる。既存の Invalid subnet format と同じく stderr + System.halt(1)）
2. 0 にクランプする

dig 互換を掲げているので 1 が素直だと考える。

あわせて String.to_integer/1 は "abc" で ArgumentError を投げるため、--subnet 192.0.2.1/abc がスタックトレースを出す点も同時に見るとよい。

経緯

PR #85（Dialyzer の contract_supertype 解消）のレビューで source_prefix を non_neg_integer() にできないかという指摘があり、実測したところ実装が負値を返し得ることが分かった。spec は実装に忠実な integer() に据え置き、入力検証の欠落は挙動変更を伴うため本 issue に分離した。

https://claude.ai/code/session_01YAjSJR67tWTvYDJLcQThbQ

[toshi0806]

着手します。実装前に dig の実挙動を測ったところ、本 issue の「検討事項」に書いた案 1 は dig の挙動と違っていましたので、仕様を測定結果に置き換えます。あわせて --subnet 周りで別の不具合を 2 件見つけたので記録します。

1. dig の実挙動（DiG 9.20.26 実測）

$ dig +subnet=<arg> ... example.com
192.0.2.1/24     => （エラー無し）
192.0.2.1/-5     => dig: invalid prefix length in '192.0.2.1/-5': not a valid number
192.0.2.1/999    => （エラー無し）        ← 拒否しない
192.0.2.1/abc    => dig: invalid prefix length in '192.0.2.1/abc': not a valid number
192.0.2.1/33     => （エラー無し）        ← 拒否しない
192.0.2.1/       => dig: invalid prefix length in '192.0.2.1/': not a valid number

実際に送られるオプションを +qr で確認すると、範囲超過はエラーにせずファミリ幅にクランプしていました。

192.0.2.1/24    => ; CLIENT-SUBNET: 192.0.2.0/24/0
192.0.2.1/999   => ; CLIENT-SUBNET: 192.0.2.1/32/0
192.0.2.1/33    => ; CLIENT-SUBNET: 192.0.2.1/32/0
2001:db8::1/200 => ; CLIENT-SUBNET: 2001:db8::1/128/0

つまり dig は「数値として妥当でないものは拒否、範囲超過はクランプ」という二段構えです。issue 本文の案 1 は「範囲外をエラーにする」でしたが、それは dig 非互換になります。

したがって直すのは負値と非数値だけで、min(prefix, 32) によるクランプは既に dig と同じであり、そのまま維持します。この方針で進めます。

2. 併せて見つけた不具合（本 issue のスコープ内として直す）

--subnet は 3 通りの指定のうち 2 通りで黙って捨てられます。

["example.com", "--subnet", "192.0.2.1/24"]
  edns=false options=nil                      ← ECS が送られない
["example.com", "--edns", "--subnet", "192.0.2.1/24"]
  edns=true  options=[edns_client_subnet: %{...}]
["example.com", "--bufsize", "1232", "--subnet", "192.0.2.1/24"]
  edns=true  options=[]                       ← ECS が送られない

check_edns/1 の節の順序が原因です。

def check_edns(%{bufsize: size} = arg) when is_integer(size), do: mk_edns(arg)
def check_edns(%{edns: false} = arg), do: arg                    # ← ここで止まる
def check_edns(%{subnet: subnet} = arg) when is_binary(subnet),  # ← 到達しない
  do: arg |> Map.put(:bufsize, DNS.edns_max_udpsize()) |> mk_edns_with_subnet

parse_args/1 が Map.put_new(:edns, false) するため :edns キーは常に存在し、--edns を付けない限り 2 番目の節が一致してしまいます。

prefix の検証を足しても、この経路が死んでいる限り効きません（--subnet 192.0.2.1/abc 単体では parse_subnet_option/1 自体が呼ばれない）。本 issue の目的を達成するには順序の修正が必要なので、同じ PR で扱います。3 番目の節は自分で bufsize を設定して mk_edns_with_subnet を呼んでおり、--subnet が EDNS を含意する意図は明らかなので、挙動の設計変更ではなく順序の取り違えの修正と判断しました。

3. スコープ外として分離するもの

ECS のアドレスがマスクされていません。 dig は 192.0.2.1/24 を 192.0.2.0/24 として送りますが、tdig は client_subnet: {192, 0, 2, 1} とホスト部を残したまま送ります。RFC 7871 は SOURCE PREFIX-LENGTH を超えるビットを 0 にすることを求めており、prefix で精度を落とすという ECS の目的そのものに反します。

prefix 検証とは独立した別の不具合なので、別 issue に分けます。

作業予定

• 非数値・負値の prefix を、既存の Invalid subnet format と同じ流儀（stderr + 終了コード 1）で拒否する
• 範囲超過のクランプが dig と一致することをテストで固定する
• check_edns/1 の節順を直し、--subnet 単体・--bufsize 併用でも ECS が付くことをテストで固定する
• アドレス未マスクの件を別 issue に起票する

https://claude.ai/code/session_01YAjSJR67tWTvYDJLcQThbQ

[toshi0806]

PR #87 を作成しました。レビュー指摘も収束済みです（merge 待ち）。

対応内容

着手コメントに書いた方針どおり、dig の実測を仕様の基準にしました。

• 負値・非数値の prefix を拒否（parse_prefix_length/1）。Integer.parse/1 は符号を許すため使わず、数字のみを受理する。dig は +24 を拒否し先頭ゼロは許容するので、それに一致
• 範囲超過はクランプのまま維持。issue 本文の案 1「範囲外をエラーにする」は dig 非互換だったので採用しなかった
• check_edns/1 の節順を修正。--subnet が単体および --bufsize 併用で黙って捨てられていた問題を解消
• source_prefix の型を integer() → non_neg_integer()（PR fix(cli): narrow parse_subnet_option/1 spec to the value it returns #85 のレビュー指摘が本 PR で成立）

利用者に見える変化です。

$ ./tdig example.com A --subnet 192.0.2.1/abc
Invalid prefix length in 192.0.2.1/abc: not a valid number   （exit=1、以前はスタックトレース）

$ ./tdig example.com A --subnet 192.0.2.1/24/8
Invalid subnet format. Use: address/prefix (e.g., 192.0.2.1/24)   （exit=1）

レビューで追加検証したこと

• --bufsize が OPT レコードまで届くか → 届く。テストを parse_args 出力ではなく Tdig.check_edns/1 が作る OPT レコード（payload_size / rdata）まで伸ばした
• 複数スラッシュの扱い → 形式エラー側に落ちる。String.split/2 の戻り値を assert していた不適切なテストを、tdig 自身の分岐（split_subnet/1）を検証する形に直した
• 巨大な prefix 値 → dig は 2^32 以上を out of range で拒否するが、これは C の整数幅由来の実装上の産物。tdig はクランプのままとし、テストで固定した（dig が受理する全ての値で送出オプションは一致する）
• \d の Unicode 対応 → Elixir の正規表現は既定で Unicode off なので全角数字等は既に弾かれる（実測確認）

別 issue に分離

#88 — ECS のアドレスが prefix でマスクされていない。dig は 192.0.2.1/24 を 192.0.2.0/24 として送るが、tdig はホスト部を残す。RFC 7871 違反であり、prefix で精度を落とすという ECS の目的にも反する。

検証

mix test       → 75 passed（着手時 60）
mix dialyzer   → 未処理 0（done passed successfully）
mix credo --strict → no issues
mix format --check-formatted → OK

CI 全 green・MERGEABLE/CLEAN。escript を実際にビルドして終了コードと stderr も確認済みです。

https://claude.ai/code/session_01YAjSJR67tWTvYDJLcQThbQ