本人の経験の開始文・他者事例の元ノートへ
2026-09-15に他者事例から学んだ現在の知識を振り返るページ。今回確認した本人の担当経験は、上のリンク先のexperience開始文で別に具体化する。元ケースの調査を本人の実務経験として扱わない。以下の数値・図は演習上の追加条件・概念図 で、実測結果ではない。
https://github.com/MFQWKMR4/tech2026 のAGENTS.md、CHATGPT.md、
src/content/docs/career/index.mdと、次のファイルを読んでください。
- src/content/docs/projects/dns-mtu-case.md
- src/content/docs/projects/dns-mtu-reflection.mdx
- reviews/network-dns-mtu.yaml
- sessions/2026-09-15-network-dns-mtu-01.yaml
- diagrams/network-dns-mtu/ptb.json
- public/diagrams/network-dns-mtu/headers.svg
reviewに新しいsessionがあればそれも確認してください。
参照できたファイルとcommit SHAを示し、読めないものはunknownとしてください。
この教材には実pcap・Flow Log・SQL実測ファイルはありません。
図JSONを読めたことと、HTML/SVGを描画して確認したことは区別してください。
今回はnetwork-dns-mtuのlearnです。他者事例を私の経験として補完しないでください。
まず希望する節を一つ聞き、回答を待ってください。指定がなければ、前回希望した
pcap/Flow LogでGRE/PMTU仮説を確かめる節から始めてください。
既存needs_revisitを短い想起の問いで確認し、一節ずつ説明→追加疑問→理解確認へ進めてください。
EDNS・PMTUの整理は解説後の回答であり、独力で定着済みと扱わないでください。
実観測・演習上の追加条件・未確認を分け、一問ずつ進めてください。
開始時刻を確認できれば記録し、40分付近で区切りを提案してください。
終了時は実際の回答・ヒントを根拠に、既存テンプレートのYAML＋Session narrativeで
MFQWKMR4/tech2026に[Session Sync] Issueを作成し、URLを返してください。
作成できなければ未作成と明示し、コピーできるタイトルと本文を返してください。
最終レビュー：2026-09-15 · 説明した（Explained）。ヒント後の理解と自力の説明を区別して記録しています。
次回、自力で確かめたいこと 2026-09-15 [2026-09-15-network-dns-mtu-01] 次回、pcapとFlow Logを使って、問い合わせ/応答サイズ、TC、UDP/TCP、ICMPv6 Packet Too Big、fragmentation、capture位置をどの区間で観測するかを具体化する。 根拠: Issue #19「次回」の本人希望と未確認事項。実pcap・面接説明は未実施、今回の仕組み説明にはヒントあり。 2026-09-15 [2026-09-15-network-dns-mtu-01] 元ケースで『大きい成功例にTCP/53があった』『失敗例でUDP復路欠落』という観測から、どの追加観測ならGRE/PMTU仮説を支持・棄却できるかを整理する。 根拠: Issue #19「次回」の本人希望と未確認事項。実pcap・面接説明は未実施、今回の仕組み説明にはヒントあり。 2026-09-15 [2026-09-15-network-dns-mtu-01] GRE outer IPv4のDF、outer fragmentation、inner IPv6 PMTUD、tunnel MTUの関係を、pcap上でどのheader/flagを見るかまで確認する。 根拠: Issue #19「次回」の本人希望と未確認事項。実pcap・面接説明は未実施、今回の仕組み説明にはヒントあり。 2026-09-15 [2026-09-15-network-dns-mtu-01] 他者事例から学んだこととして、HTTP/HTTPSを支えるネットワーク、クラウド接続、可用性、観測に基づく仮説修正の観点で短い面接説明を本人が試す。実務経験としては扱わない。 根拠: Issue #19「次回」の本人希望と未確認事項。実pcap・面接説明は未実施、今回の仕組み説明にはヒントあり。 2026-09-15のセッション 他者事例を題材に、EDNS(0)のUDP payload size、TCビットとTCPフォールバック、UDP/IP fragmentationとTCP segmentationの違い、IPv6 PMTUD、GREカプセル化による実効MTU低下を学習した。本人の実務経験としては扱わず、元ノートの観測・AI補足・今回の自力回答・解説後の理解を区別した。初回はEDNSを未認知だったが、最終的に『EDNSはDNSレイヤでUDP応答サイズの判断に効き、PMTUはIPレイヤで配送可否に効く』『中間サイズだけUDPで送れてPMTU問題を踏み、大きい応答は小さいTC=1通知を経てTCPへ切り替わることで成功し得る』『GREではouter header分だけinner側の実効MTUが小さくなる』ことを説明できた。元ケースの完全なpcap、MTU測定位置、GRE outer IP/option、どの層でfragmentationしたか、ICMPv6 Packet Too Bigの実観測は未確認のまま。
他者事例によるlearn。EDNSは初見。header長提示後に1450+40+8+20+4=1522を本人が計算。fragment欠落・TC/TCP・PTBは解説後の回答。AIの誤設定への指摘はナラティブに記載。元ケースの実pcap、独力での再確認、面接説明は未実施。
問い・回答の流れをIssueで読む
回答で示せたこと（ヒントの有無を含む） 2026-09-15 [2026-09-15-network-dns-mtu-01] 解説後、UDPデータグラムの一部fragmentが欠落すると、IP層で再構成できずDNS応答として上位へ届かないことを説明した。回答:『UDPデータグラムとして正しく届かないので、一部だけでもDNS応答が届くということにもなりません』。ヒント: あり（UDP datagramとIP fragmentationのレイヤ分離を事前説明）。 2026-09-15 [2026-09-15-network-dns-mtu-01] 解説後、TC=1を受けたResolverがTCPで再問い合わせし、TCP/53がFirewallで遮断されると最終的にtimeoutする流れを説明した。回答:『UDPでTCビット立って返るから、リゾルバーがTCPで問い合わせしに来るんだけど、ファイアウォールで遮断なのでリゾルバーはタイムアウトしてしまいそう』。ヒント: あり（TC=TruncatedとResolver側TCP再問い合わせを事前説明）。 2026-09-15 [2026-09-15-network-dns-mtu-01] GRE演習で、underlay MTU 1500、outer IPv4 20、GRE 4、inner IPv6 40、UDP 8の条件から、DNS payload 1450Bは合計1522Bとなり収まらないことを自力計算した。回答:『1450…IPv4とUDPで48でしょ。そこに24つくから収まらないですね。1522になるか』。ヒント: あり（各headerサイズは提示済み）。 同期補足: 提示条件はinner IPv6 40B+UDP8B。引用のIPv4という語の由来はunknown。 2026-09-15 [2026-09-15-network-dns-mtu-01] 解説後、outer IPv4 fragmentation禁止・inner IPv6 packet 1522B・tunnel MTU 1476Bの条件で、GRE ingressがinner IPv6を勝手にfragmentせず、inner IPv6送信元へICMPv6 Packet Too Bigを返してPMTUを下げさせる方向を説明した。回答:『IPv6送信側にパケットToo Bigを返して1476トンネルMTUを教えてあげて、1476で作り直して来いっていう感じ』。ヒント: あり（inner/outerのfragmentation責任を事前説明）。 2026-09-15 [2026-09-15-network-dns-mtu-01] ナラティブ「TCビットとTCPフォールバック」に基づき、EDNS内の中間応答はUDP配送でPMTU問題を踏み得る一方、上限超過時の小さいTC=1 UDP通知からTCPへ再問い合わせすれば成功し得ると説明。回答:「TCBITがつくのは…EDNSの広告超えてたから…それ未満の場合は最初からUDPで送ろうとする」。ヒント: あり（AIの誤設定を修正後、TC通知自体は小さく返せると説明）。すべてのTCが広告超過だけで生じるという一般則の習得は認定しない。 自力では説明しきれなかったこと 記録された項目はありません。
理由・設計を詰めたいこと 2026-09-15 [2026-09-15-network-dns-mtu-01] 当初、EDNS広告値とpath MTUの役割を混同し、『UDPでは大きすぎるという判断は広告値ではなくpath MTUが原因』と捉えた。回答:『UDPでは大きすぎるという判断は…広告値ではなくてパスMTUが原因だよね』。ヒント: あり（その後、EDNSはDNSレイヤのUDP応答判断、PMTUはIPレイヤの配送制約と分離して説明）。 解説後の変化は同sessionのdemonstrated/summaryを参照。別条件での独力再確認は未実施。 2026-09-15 [2026-09-15-network-dns-mtu-01] TCP/UDPの分割単位について、なぜTCPはtransport層でsegmentationしUDPはIP fragmentationに依存しやすいのか直感が曖昧だった。回答:『TCPはパケット配送が保証される…でもしっくりこない。本質的にそのレイヤーで分割する合理性が直感的に理解したい』。ヒント: あり（UDPのmessage boundaryとTCP byte stream、再送単位の違いを説明）。 解説後の変化は同sessionのdemonstrated/summaryを参照。別条件での独力再確認は未実施。 2026-09-15 [2026-09-15-network-dns-mtu-01] GREトンネル入口でinner IPv6が大きい場合、最初はGRE ingressがinner IPv6を1428B程度にfragmentしてから包むイメージを持った。回答:『1428で分割をしてIPv6 Inner Packetを生成する。でそれぞれにOuterのGREをつけて1500で送る感じか』。ヒント: あり（IPv6中間routerはinner packetを勝手にfragmentせず、ICMPv6 Packet Too Big/PMTUDとouter IPv4 fragmentationを分離して説明）。 解説後の変化は同sessionのdemonstrated/summaryを参照。別条件での独力再確認は未実施。 修正が必要な説明 記録された項目はありません。
今回の計算回答はheader長の提示後、仕組みの説明は主に解説後。元ケースのouter IP版・option・DF・fragmentation位置・PTBの実観測はunknownで、pcap調査はまだ行っていない。
EDNS(0)のUDP payload sizeは、問い合わせ側が受け取れるDNSメッセージ全体のサイズ の広告で、UDP/IP headerは含めない。PMTUはIPパケットが経路を通る際の制約。EDNS広告はPMTUの測定でも、配送成功の保証でもない。応答側にもUDPサイズ方針があり、広告値より小さい制限を選ぶことがある。RFC 6891 §6.2 。
演習上の追加条件 ：問い合わせ側のEDNS広告値は4096B、応答側もこれをUDP上限に採用。inner IPv6経路のPMTUは1280B、IPv6 headerは40Bで拡張headerなし、UDPは8B。DNS以外の損失・遮断は除き、下表の中間サイズではPMTU超過からの回復が成立しない（PTBが送信元へ届かず、再送でも適切なサイズへ変わらない、または送信元によるfragmentの一部が失われる）と仮定する。TCP/53は許可され、TCP側はPMTUに収まるsegmentで配送できるものとする。
完全なDNS応答サイズ
DNSレイヤの判断
配送されるもの・演習での結果
800B
4096B以下なのでUDPで返す
800+8+40=848B。1280B内で成功
1400B
4096B以下なのでUDPで返す
1400+8+40=1448B。1280Bを超え、上記の回復失敗条件でtimeout
5000B
4096Bを超えるため完全応答をUDPで返せない
例として200BのTC=1 DNS通知を返す。200+8+40=248Bで届き、問い合わせ側がTCPで再問い合わせして完全応答を受け取る
200Bは、この演習で質問部等を含めた切り詰め応答が収まるという仮定で、TC応答の固定長ではない。5000BのUDPパケットが経路を通るわけではない。TCはDNS側の切り詰め通知であり、途中のrouterがMTU超過を検出してTCを付けるものではない。 TCPによるDNSはメッセージ長を示す2Bのprefixを持ち、5000Bの応答を一つのIPパケットに載せる必要はない。RFC 7766 §5・§6.1 。
「PMTUを超えたら必ず失敗」でも「EDNS広告内なら必ずTC=0」でもない。送信元のfragmentationと再構成が成功する場合もあり、DNS側のより小さい上限でTCが返る場合もある。上表は、元ケースの大小逆転を説明し得る仮説の一例 である。TCなしのtimeoutからの再試行方針も実装依存なので、TCPを観測しただけでTCを契機としたと断定しない。
TCPはbyte streamを扱い、アプリケーションの一回のwriteとsegment境界は一致しない。受信側はsequence number等で順序を組み立て、欠落したデータを再送で補える。MSSとPMTUを考慮したsegmentでも、経路変更などで配送に失敗し得るので「TCPならMTU問題がなくなる」とは言えない。RFC 9293 §3.7・§3.8 。
UDPはdatagramの境界を保つ。IP fragmentationが起きた場合はIP層で全体を再構成してからUDPへ渡すため、一部fragmentだけで部分的なDNS応答を届けることはできない。UDP自身にTCP相当の分割・再送はなく、アプリケーションで分割するなら識別や再構成も設計する。通常はPMTUを超えるUDP datagramを避ける。RFC 8085 §3.2・§3.3 。
図で確かめる問い：同じDNS応答を包んだとき、innerとouterのどちらが何Bになるか。 上のPMTU1280例とは別の演習として、underlay PMTU1500B、outer IPv4 20B、GRE基本header 4B、inner IPv6 40B、UDP8B、追加optionなしとする。GRE overheadはouter IPとGREの合計24B。fragmentationなしで運べるinner IPパケットの上限（GMTU）は1476B、DNS payloadの上限は1428Bとなる。RFC 2784 §2 、RFC 7676 §1.2 。
header図を拡大する
図の1428BはDNS payloadの上限 であり、inner IPv6パケットの上限ではない。1450Bの例ではinnerは1498B、outerは1522B。セッション後半の「inner IPv6=1522B」は別の設問条件で、そこに24Bを足すとouterは1546Bとなる。二つの1522Bを混ぜず、毎回測定する層を添える。
GRE ingressはinner IPv6の送信元ではないとする。RFC 7676 §3.3では、GMTUが1280B以上でinnerがGMTUを超えれば、そのinnerを破棄し、inner送信元へGMTUを記載したICMPv6 Packet Too Big（PTB）を返す。この演習なら1498Bを破棄し、MTU=1476を通知 する。DF=0なら必ずouterを分割して救済する、という二択にはしない。
通信順序を見る図 ：GRE ingressから送信元へのPTBと、その後の配送 。JSON正本 も参照できる。
図の後半は、PTBが届き送信元がPMTUへ適応できた場合の概念的な継続。既存UDP datagramをどう作り直すかはアプリケーション・stackの動作次第で、同じDNS応答が自動的に小さくなるという意味ではない。IPv6のfragmentationをするなら送信元 が行い、Fragment headerの分も必要になる。PTBの到達と、送信元が実際にサイズ・送信方式を変えたかを別々に観測する。RFC 8200 §4.5・§5 、RFC 8201 §4・§5 。
条件
仕様上の扱い・確かめること
GMTU1476、inner1498（今回の基本演習）
RFC 7676ではinnerを破棄しPTB1476。innerの途中fragmentationはしない
GMTUが1280未満でIPv6を運ぶGRE
IPv6の最低1280Bを運ぶための例外。トンネルがdelivery packetのfragment/reassemblyを支援する必要があり、RFC 7676 §3.2–3.3の要件を確認する
既に送出したouter IPv4が途中のMTUを超える
IPv4としてDF等に従う。DF=0ならouter fragmentationが可能、DF=1なら破棄とICMPv4 fragmentation neededの対象。ICMPv6 PTBとは別物
outerがfragmentされた場合、再構成を行う先はouter宛先のGRE egressである。outer DF/MF/fragment offsetと、inner IPv6のFragment headerを別々に読む。元ケースがこのどの状態だったかはunknown。RFC 7676 §3 、RFC 791 §2.3 。
DNSのUDP応答上限を小さくすればfragmentationを避けやすくなるが、TCP接続数・再利用・処理負荷・遅延を測る必要がある。TCP/53が遮断されていれば、TCを届けても完了しない。一方、トンネルMTUやICMP配送を直す案はDNS以外にも効き得るが、経路全体の設定と運用責任の調整が要る。EDNS広告値を経路全体に効くMTU設定として扱わず、変更後のUDP/TCP比率、timeout、latencyを比較する。特定サービスの推奨値は、この演習の1428Bから決めない。
次回の問い：UDP応答が消えた区間を、どの二地点の記録で挟むか。 ここからは調査計画で、取得済みpcapの解析結果ではない。まず同じ問い合わせ条件・時刻・経路で小/中/大の応答を比較する。キャッシュ状態やDNS応答のsection構成、DNSSEC関連条件が異なれば、それも記録する。resolverのクライアント側と上流DNS側は別のDNS交換で、IDが同一とは限らない。
観測位置
pcapで残すもの
検証する仮説
上流DNSと問い合わせ元resolverの両端
QNAME/QTYPE、DNS ID、時刻、EDNS広告値、DNS実バイト数、UDP length、TC、UDP/TCP、TCP SYN/再送・応答
大きい成功例は小さいTC通知の受信後にTCPへ切り替わったか。TCP成功だけでは契機は不明
応答方向のGRE ingress直前（inner側）
inner src/dst、IPv6全長、Next Header、Fragment header、UDP/DNSのサイズ
そもそも大きすぎる応答がDNSから出て、トンネル入口まで届いたか
GRE ingress直後とegress直前（outer側）
outer IP版・全長、IPv4 DF/MF/fragment offset/ID、GRE option、ICMPv4 type3/code4
カプセル化後のサイズ、outer fragmentationの有無と欠落区間
GRE egress直後（inner側）とresolver
復元されたinner、DNS応答、fragment再構成の成否
outerは全片届いても、egress以降で応答が消えていないか
inner送信元へ向かう戻り経路
ICMPv6 type2（PTB）、広告MTU、引用された元パケット、送信元での受信、以後のサイズ
PTB生成・配送・送信側のPMTU適応のどこで止まったか
後続fragmentにはUDP portやGRE headerがない場合があるので、port53だけのcapture filterでは見落とし得る。inner/outerのinterfaceを分け、ICMPとfragmentも含めて取得する。IPv6の全長は通常、基本header40BとPayload Lengthの合計で読む。captureのsnaplen・drop統計・offloadによる見かけのサイズも確認し、端末上の巨大パケットだけでwire上のMTU違反を断定しない。
追加観測
仮説への意味
ingressでinner超過と対応するPTB1476を観測、送信元ではPTBが見えない
その区間のPTB配送問題を支持。ただし両地点のcapture漏れも確認
outerの同一IDのfragment群が送出され、egressで一部だけ欠ける
outer fragmentの配送失敗を支持。IPv4 headerと時刻で対応付ける
大きい成功例でTC受信→TCP SYN→DNS応答を両端で対応付け
TCを契機としたTCPフォールバック仮説を支持
問題のUDP応答が再構成済みでresolverまで完全に到着
その試行のGRE配送喪失仮説に反する。DNS内容・処理・照合・timeout判定へ進む
すべてのサイズでTCP SYNが遮断される
TCP側の到達性問題を支持。UDPのPMTU問題を同時に否定はしない
EDNS上限を下げた後だけ成功
サイズ/方式の関与は支持するが、PMTU・fragment drop・TCP切替のどれが原因かは単独では確定しない
Flow Logの提供元は元ケースの詳細ではunknown。AWS VPC Flow Logsを使う場合 、ENI・方向・時刻・protocol・bytes/packets・ACCEPT/REJECT・log-status等で対象フローを絞れるが、集約レコードであり個々のDNSサイズ、EDNS、TC、PTB内容、DF/MF/offsetは読めない。bytesを一応答のサイズとして使わない。ACCEPTも相手への到達証明ではなく、記録なしもdropの証明ではない。Amazon提供DNSへの通信は記録対象外などの制約があるため、対象ENIでその通信を観測できるかを最初に確認する。AWS VPC Flow Logsの制約 、record fields 。
次回はこの表の全項目を一度に埋めず、元ノートの「大きい成功例にTCP/53」「失敗例でUDP復路欠落」から、必要な追加観測を一つずつ選ぶ。未取得のpcapを想像で埋めない。
補強元は2026-09-15-network-dns-mtu-01（Issue #19 ）。疑問は「EDNSとPMTUの違い」「GREのどの層で分割するか」「どの観測なら仮説を支持・棄却できるか」。入口の既存技術補足をこのページへ統合した。対象はEDNS(0)、IPv6、GRE、DNS over TCPの上記RFC、AWS VPC Flow Logsの版番号なしの現行文書（2026-09-15確認）。元ケースの製品版・実設定はunknown。図は概念図、コマンド実行・パケット取得・再実験は未実施。
