要約

  • TCPはDNSの通常のサービス経路であり、ゾーン転送だけに使う例外ではない。
  • EDNSは利用可能なUDPの範囲を広げるが、あらゆる経路での配送を保証しない。
  • 準備状況は、切り詰めからTCP確立、完全な応答、安全な接続再利用まで同じ問い合わせを追って証明する必要がある。

障害を最もよく示すのは、緑色のダッシュボードである。UDP/53は速く応答し、権威データも新しい。ところが大きな応答にTCビットが立つ。リゾルバーはTCPを開くが、提供拠点のaccept queueが浅い、ファイアウォールのタイムアウトが用途に合わない、あるいは遅い相手の後ろで処理が直列化される。DNSデータは正しい。それでも配送経路は準備できていない。

RFC 1035は、53番ポート上のUDPとTCPを定義し、TCP DNSメッセージに2オクテットの長さを付ける。さらに、TCPデータを待つ間に他の処理を止めてはならず、複数接続を扱うべきだとする。EDNSが当初のUDP上限を拡張しても、切り詰めが同じ問い合わせを完了するための仕事を別のトランスポートへ移す点は変わらない。

RFC 6891では、要求側がDNSとして再構成し上位へ渡せる最大UDPペイロードを通知する。その値は端点能力の証拠であって、途中の全経路に対する約束ではない。試験環境でTCが現れないことを理由に、本番契約からTCPを外すことはできない。

RFC 7766は、汎用DNS実装にTCP対応を求め、問い合わせごとの接続確立コストを避けるため接続再利用を扱う。したがって容量の問いは、ポートが一度開いたかではない。同時処理が完了するか、遅い接続が他を妨げないか、有限の状態を守りながら有用な接続を維持できるかである。RFC 9210はこの運用境界を更新する。一度の接続成功は、実際の問い合わせ構成と負荷における接続寿命の管理を証明しない。