ラジオの話題21：大きいDNS応答の方が、なぜ届く？

← ラジオの話題一覧 · 元の教材・詳しい解説

今日の話題：①受け取れるサイズと、通れるサイズ → ②大きすぎる方が成功する仮説 → ③ヘッダーの引き算をしてみる。

気になったところから自由に。順番や時間は決めず、話しやすい話題だけ拾って構いません。

1. 受け取れるサイズと、通れるサイズ

話を広げるメモ

• EDNSで大きく広告したら、途中の経路も通れる？
• トンネルで包む分のヘッダーは？

小ネタ：EDNSとMTU

EDNSのUDP payload sizeは受信側が扱えるDNSメッセージの大きさを示す。経路のMTUを測った結果ではない。トンネルの外側IPやGRE分も考える。

話の芯：受け手の能力と、経路の制約を分ける。

2. 大きすぎる方が成功する仮説

話を広げるメモ

• 中間サイズはUDPで送られて途中で失われる。
• さらに大きい応答は切り詰められてTCPへ切り替わる？

小ネタ：TCと無応答

TC=1を受け取ればTCP再試行へ進める一方、UDP応答が丸ごと失われるとTCも受け取れない。この違いで逆転が起こる仮説を立てられるが、本件の確定原因としては語らない。

話の芯：失敗の伝わり方が、次の動作を変える。

3. ヘッダーの引き算をしてみる

話を広げるメモ

• 演習：MTU1500、外IPv4 20、GRE 4、内IPv6 40、UDP 8 byte。
• この条件ならDNS payloadの目安は1428 byte。

小ネタ：GRE 24 byteの内訳

この例の24 byteは外側IPv4の20とGRE基本4の合計。GRE単体の固定長ではない。optionや別のIP版なら再計算する。これは他者事例を元にした概念例で、元の経路の実測ではない。

話の芯：数字より先に、何を包んだかを確認する。

最後に一言、話すなら

「この話を、次に調査や設計をするときどう思い出したいか？」

このメモの材料

既存の調査ケースにある技術補足から構成しました。当時の本人の発言・成果を再現した台本ではありません。思い出せる経験だけを本人の経験として話し、分からない経緯は補わずに使ってください。 DNSの回は他者の調査事例です。本人が調査した経験としては扱いません。

定義の詳細・前提・一次資料・対象版・確認日は元の教材を参照してください。今回の作成では新しい実験・学習評価は行っていません。