要約

  • TCは、メッセージが伝送路で許された長さを超えて切り詰められたことを示す。RFC 2181は、必要なRRsetを丸ごと入れられない場合の印だと明確化し、クライアントにその応答を無視して再問い合わせするよう求めた。
  • 大きな答えにはTCPが使われたが、単なる非常口ではなくなった。RFC 7766は汎用DNSにUDPとTCPの双方を要求し、TCPから始める選択も認めた。RFC 9210は容量、通過性、監視を通常運用の責務にした。

入らなかった記録を「ない」ことにしない

RFC 1035は1987年、53番ポートのDNSをUDPとTCPの双方に定めた。通常問い合わせでは、接続を作らず状態も少ないUDPが軽い。ただしIP・UDPヘッダーを除くDNSメッセージは512バイトまでだった。

長ければ切り詰め、TC=1を立てる。TCが述べるのは名前の状態ではない。「この伝送路の長さでは全部を運べなかった」という配送側の事実だ。名前が存在しないとも、見えているアドレスだけが有効だとも言っていない。

もし5件のうち3件だけが入ったパケットを完全な答えとして扱えば、パケット容量が名前空間を書き換えてしまう。TCはその誤変換を止めた。

RRsetは途中で意味を変えない

1997年のRFC 2181は、同じ所有者名・クラス・型の記録をRRsetと定義し、集合全体を応答単位にした。必要なRRsetを完全には入れられない場合にTCを立てる。

一方、Additional節の補助情報だけが入らない場合は違う。その追加RRsetを丸ごと省き、TCを立てずに返せる。必要ならクライアントが別に問い合わせる。

TC付き応答を受けたクライアントは、その応答を無視し、TCPなど大きな返答を許す仕組みで聞き直す。パケット内に部分RRsetが残っていても、キャッシュへ足したり古い値と合成したりしてはいけない。

ここで守られたのは、完全性を判断する権限である。受信側の都合で「この3件なら十分」と決めても、権威側が持つ集合の代わりにはならない。

TCは次の経路まで命令しない

典型的にはUDPで質問し、TCを受けてTCPで同じサーバーに再問い合わせする。TCP上のDNSは2バイトの長さを先頭に置き、1つのデータグラムより大きいメッセージを運べる。

ただしTCが直接接続を開くわけではない。リゾルバーは再試行、別サーバー、接続再利用を選び、サーバーは受け入れる接続数やアイドル時間を決める。TCPの状態コストを負う主体が、その運用制限を持つ。

その制限はDNSデータを編集する権限ではない。サーバーは「この運搬は未完了」と狭く表明し、完全な証拠を必要とするリゾルバーが次を選ぶ。

EDNSの数字は経路全体の保証ではなかった

RFC 6891のEDNS(0)により、要求側は受け取れるUDPペイロードサイズを広告できた。512バイトを超える多くの応答がUDPのまま返せるようになった。

しかし、その広告値は途中のリンク、トンネル、ファイアウォールのMTUを証明しない。IPフラグメントは失われたり遮断されたりする。DNSSECの署名や否定証明も応答を大きくした。

EDNSは受信側の提示する予算、TCは実際の応答が使える予算に収まらなかったという報告である。大きな値を提示しても、経路が領収書を返したことにはならない。大きなUDP応答が無言で落ちればTCさえ届かないため、タイムアウトと権威ある否定応答を分けて観測する必要がある。

TCPは例外扱いを終えた

長く「TCPはゾーン転送か切り詰め時だけ」と要約された結果、TCP/53を不要とみなす実装やネットワークが生まれた。回復を示すビットはあるのに、回復路が閉じられる矛盾である。

2016年のRFC 7766は、権威サーバー、再帰サーバー、フォワーダー、stub resolverを含む汎用DNS実装にUDPとTCPの両方を要求した。通常問い合わせを必ずUDPから始める旧要件も緩和し、ローカル運用上の理由でTCPを先に使えるとした。開いている接続は再利用する。

したがって、TCからTCPへの切り替えは重要な歴史だが、永遠の唯一手順ではない。TCPは独立した選択肢になり、後には別のDNSトランスポートも加わった。不変なのは、必要なデータの一部を完全な応答にしないことだ。

ストリームにも節度が必要だった

質問ごとに接続を作れば、ハンドシェイクの遅延と状態が積み重なる。RFC 7766は接続再利用とパイプラインを勧めた。複数問い合わせを待たずに送り、サーバーは並行処理し、応答は順不同でもよい。

クライアントは各応答を未完了の問い合わせに照合する。サーバーや監視器はTCPストリームを再構成し、1 segmentを1 DNSメッセージだと誤認しない。

同時接続数、クライアント別の受け入れ、アイドルタイムアウトは制御できる。信頼できる経路を維持する義務と、資源枯渇を防ぐ権限は両立する。

運用と監視もTCPを無視できない

RFC 9210は2022年、DNSサーバーとリゾルバーがUDP・TCPの両方をサービスし、ネットワーク運用者も原則として両方を通すよう求めた。別トランスポートなら成功したというだけで問い合わせを拒否してはならない。

監視はストリーム再構成、接続再利用、パイプライン、順不同応答を理解する必要がある。UDPだけのダッシュボードでは、TCの後に完全な応答が得られたのか、TCPで止まったのか判断できない。

フラグメントを避ける時代にもTCは残った

2025年のRFC 9715はDNS/UDPでIPフラグメンテーションを避け、より小さい制約がなければ1400バイトを推奨上限とした。断片化は配送を脆くし、キャッシュ汚染の危険も増やす。

同文書はTCの因果を変更していない。安全に入らなければ切り詰めを示し、断片が失われるなら要求側は最終的に別トランスポートを試す。TCPにも遮断や過負荷はある。それでも「不完全な証拠を完全と呼ばない」という退路は残る。

1ビットの主張は狭かった

TCはDNSSEC失敗、検閲、攻撃、不存在、所有権を証明しない。省略された補助情報のすべてがTCを必要とするわけでもなく、将来の全状況でTCPだけを命じるものでもない。

狭いからこそ信頼できる。このチャネルでは必要な応答を全部運べなかった。DNSは最初の封筒が小さいことを許し、封筒が内容について嘘をつくことを許さなかった。

情報源と限界

元の仕様はRFC 1035、RRset規則はRFC 2181、EDNSはRFC 6891、TCP要件はRFC 7766とRFC 9210、断片回避はRFC 9715に基づく。現在の世界的なTC率、TCP通過率、製品設定はこれらからは分からない。