DNS・MTU調査の経験と学び

職務経歴書の8エピソード一覧から、今回は一つだけ選ぶ。同じページの他の経験には広げず、関連知識の補強もこのエピソードに沿って行う。

振り返り・解説：EDNS・GRE・pcapの観測へ — 回答記録、ヒント、次回課題と補強教材をまとめて読む。

セッション：DNS応答の一部失敗を調査・原因特定

IPv6が関わる経路で一部のDNS応答が失敗し、EDNSとPMTUに着目して調査・検証した本人の経験。

https://github.com/MFQWKMR4/tech2026 のAGENTS.md、CHATGPT.md、
src/content/docs/projects/dns-mtu-case.md、reviews/network-dns-mtu.yaml、
src/content/docs/career/interview-tips.md、.github/ISSUE_TEMPLATE/session-sync.md、reviewが参照する必要な過去sessionを読んでください。
読めた資料とcommit SHAを示し、読めない場合は読んだとせずsession packを求めてください。
今回はtopic: network-dns-mtu、session_type: experienceです。
選択エピソード：DNS応答の一部失敗を調査・原因特定。1エピソード1セッションとし、他の開始文は実行しないでください。
対象：IPv6が関わる経路で一部のDNS応答が失敗し、EDNSとPMTUに着目して調査・検証した本人の経験。
既存needs_revisitのうち今回の話に関係するものを優先し、無関係な項目は次回に残してください。
なければ最初の一問は「失敗するDNS応答と成功する応答の違いを、当時どのように確認しましたか。」。一度に一問だけ尋ね、回答を待ってください。
当時の課題・観測→自分の担当と行動→判断理由と代案→検証・結果を、回答に応じて思い出す手助けをしてください。
覚えていない事実はunknownで止め、今知りたい仕組みを一つ選んで学び直してください。
技術補強の候補：EDNSで知らせる受信可能サイズと経路MTU、IPv6のPTB、UDP応答とTCP切替、経路上の観測と仮説の対応。
前提知識を短く説明し、一次資料のURLと対象バージョンを示してから、条件を一つ変えた問いで理解を確かめてください。
注意：元ノートは他者事例、9月15日のsessionはlearnです。今回の本人経験とは分け、GRE構成・pcap取得・具体的な原因や対策を私の実績として流用しないでください。
当時の経験、今の学び、AIの補足・演習条件を分け、経験・成果・不足を推測で補完しないでください。
会社名・顧客情報・非公開情報・職務経歴書の連絡先は教材や同期Issueへ転載しないでください。
最後に私自身がこのエピソードを短く説明し、根拠のある担当・判断・結果と、まだ確認が必要な点を整理します。模範回答を先に出さないでください。
開始時刻が分かれば記録し、40分付近で区切りを提案。時刻不明なら経過を推測しないでください。
終了時は既存形式の[Session Sync]（YAML＋Session narrative）を作成し、summaryとnarrativeに選択エピソード名、実際の回答・ヒント、当時の経験と今の学びを残してください。
フィードバックではtipsから今回に関係する観点を選び、実際の回答を根拠に伝わった点・説明を補う点・未確認を分け、narrativeに残してください。全問の消化は目標にしません。
repository_requestsにはこのprojectページへ戻す想起内容・技術解説を指定し、別エピソードの記録を上書きしないでください。
Issueを作成できなければ未作成と明示し、コピーできるタイトルと本文を返してください。

GitHubを読めない場合は npm run session:pack -- network-dns-mtu の出力を渡す。パック内に複数の開始文があっても、選択した一件だけを扱う。

このページの使い方

2026-09-16、本人からもIPv6が関わるDNS応答の一部失敗についてEDNS・PMTUに着目した調査・検証を担当したと確認した。上の開始文は、この本人の経験を具体化する入口。担当した観測・実験・判断の詳細はまだunknown。

一方、以下の元ノートは他のエンジニアの事例であり、2026-09-15のlearnもその教材を基にした学習記録として保持する。本人の担当経験へ読み替えない。対話はChatGPT、編集と同期はCodexで行う。ケース一覧から別のケースも選べる。

2026-09-14、Issue #16としてObsidianの Untitled. 4 から整理した初稿。元ノートの要約であり、全ログ・コードの独立確認や今回の再実験ではない。2026-09-15に初回learnを実施し、回答記録は振り返りへ同期した。原文の観測と解釈、AIによる補足を分ける。

他者の事例：元ノートにあること

元ノートに「他のエンジニアの対応ケースを学習目的で整理」と明記されている。本人の担当実績・顧客対応・成果として扱わない。 一般化したケースから仕組みと調査判断を学ぶ。

問題と調査の経緯

DNS ResolverからオンプレミスDNSへの問い合わせで、一部のSRV応答がタイムアウトした。経路にはIPv6とGREを使う区間があった。元ノートは、応答サイズ・UDP広告サイズ・TCPへの切替が関係する事例としてまとめている。

段階	ノートが報告する観測	当時の仮説と限界
対象の偏り	同じ経路でも特定の問い合わせだけ失敗	経路が同じでもパケットサイズで差は起き得る。これだけで経路要因を除外しない
サイズを比較	小さい応答は成功し、ある中間サイズは失敗、さらに大きい応答は成功	「大きいほど失敗」から、サイズとプロトコル切替を含む仮説へ変えた
通信を照合	成功例にはTCP/53の往復があり、失敗例ではUDP復路の欠落が記録される	TCPフォールバックの有無に着目。Flow Logだけで断片化やドロップ箇所まで一意に確定しない
上限を調整	DNS側のUDP応答上限を下げる回避案と、送信元を限定する方法を記録	元ノートの数値は経路固有。現在のResolver仕様や推奨設定値にはしない

元ノートにはResolverのリトライ時の広告値や非公開実装の説明もある。ここでは非公開の内部情報を転載せず、標準仕様から検証できる仕組みを教材にする。完全なpcap、MTUを測った位置、GREの外側IP版とoptionはunknown。

AIによる技術補足：入口から学ぶ

EDNSのUDP payload sizeはDNSメッセージの受信上限の広告で、経路MTUの測定値ではない。GREではouter IPとGRE headerの分だけinner側の実効MTUが減る。この違いから、中間サイズがUDPで失敗し、より大きい応答がTCを経てTCPで成功する仮説を考える。

既存の技術補足を 振り返り・解説 にまとめ、今回のセッションに合わせて補強した。

次の対話：現在の理解から設計へ

仕組み：EDNSの広告サイズとMTUが別の値であることを、包みを重ねる例で説明する。
観測：TCを受けた再試行と、無応答のタイムアウトをどう識別するか。
今なら：境界の前後で一条件ずつ変え、どの観測なら仮説を棄却するか。
設計判断：経路を直す案とDNS応答サイズを抑える案を、適用範囲・運用負担・遅延で比較する。

この他者事例の節から面接へ使えるのは、本人が対話で説明した一般的な知識・判断である。他者の調査を本人が実施した経験談にはしない。

出典・対象環境

元ノートは他者のDNS/IPv6/GRE事例。製品の正確な版・経路の全条件はunknown。一次資料は2026-09-14確認のRFC 6891（EDNS）、2784（GRE）、8200（IPv6）、7766（DNS over TCP）。RFCの一般仕様からの学習であり、特定サービスの現在の広告値や内部実装の確認ではない。

セッションと次の更新

元資料の参照は2026-09-14。原文は変更せず、顧客情報・内部情報を転載していない。Issue #19のlearnを記録した。解説後の回答と提示条件下の計算を保存し、実pcap調査・短い面接説明は次回へ残した。本人の実務経験としては扱わず、教材補強を習得の証拠にはしない。