DNSの応答が大きくなるとき、EDNSのUDPペイロードサイズは重要な手掛かりです。ただし、その数値は通信経路の通りやすさを測った結果ではありません。「受け取れると相手に伝えた長さ」と「経路を越えて届く長さ」を分けると、大きい応答だけ失敗する現象を整理しやすくなります。
簡単にまとめると？
- EDNS(0)のOPTには、問い合わせ側が受け取れるUDPペイロードの大きさを広告する欄があります。経路MTUの測定値ではありません。
- 端末と再帰リゾルバー、再帰リゾルバーと権威サーバーは別のやり取りです。一方の広告値だけで、もう一方の経路まで判断できません。
- 広告値、実際の応答サイズ、経路の制約、切り詰めを示すTC、TCPでの再試行を分けて確認します。サイズ内でも配送成功は保証されません。
OPTは、応答の住所データを増やすレコードではない
EDNS(0)はDNSの拡張機構です。問い合わせの追加情報部へ置けるOPT擬似リソースレコードを使い、通常の名前とアドレスの対応とは別に、その問い合わせと応答に関する制御情報を伝えます。RFC 6891では、OPTのCLASS欄をUDPペイロードサイズに使います。[1、6.1.1–6.1.2]
ペイロードは、UDPが運ぶ中身の長さです。DNSメッセージを運ぶ場合は、そのDNSメッセージのバイト数を考えます。これをIPパケット全体の長さと混ぜると、ヘッダー分を含めるかどうかで比較がずれます。本稿の数値例はすべてDNSを運ぶUDPペイロードへ単位をそろえます。
ここで広告されるのは、問い合わせ側のネットワークスタックが再構成して届けられる最大UDPペイロードです。RFCは、経路MTUがそれより小さい場合があると明記しています。[1、6.2.3] MTUは一度に運べるパケットの大きさに関わる制約であり、受信側のバッファの大きさとは別に考える必要があります。
受信側に余裕があっても、途中の制約は残る
たとえば受信側が大きな荷物を置ける部屋を持っていても、途中の通路が狭ければ、そのまま運べるとは限りません。この比喩で部屋に相当する情報を伝えても、経路上のすべての通路を検査したことにはなりません。ネットワークではさらに、分割されたIPパケットの扱いや中間装置の方針も関係します。
RFC 6891は、大きい値によってIP層の断片化が起き、断片の欠落やファイアウォールの設定のため応答を受け取れなくなる問題を説明しています。[1、6.2.3] したがって広告値を大きくした後で失敗したとしても、DNSのデータ自体が間違っていると即断できません。反対に、小さい問い合わせが成功しただけで、大きな応答まで通ると結論づけることもできません。
広告サイズの調整は、この区別を踏まえて行うものです。本稿は特定の数値をすべての環境へ推奨するものではありません。2013年のRFCに記された開始値の例を、そのまま現在の全ネットワークの最適値として転記することも避けます。
同じ1300バイトを、三つの条件で比べる
独自の説明用モデルを作ります。完全な応答のペイロード長をD、問い合わせ側の広告値をA、経路で断片化なしに扱えると仮定したペイロード上限をPとします。Pは経路条件を説明するためにこちらで与える値で、OPTから読み出せる情報ではありません。サーバー独自の上限、断片化、損失、フィルタリングはこの単純な比較には入れません。
例1はD=1300、A=1400、P=1200バイトです。1300は1400以下なので、広告値との比較は通ります。しかし1200を超えるため、このモデルでは経路側の比較を通りません。広告値を満たすという一つの条件だけで、応答をそのまま運べると判断できない例です。
例2は同じD=1300、P=1200のまま、Aを1200へ小さくします。今度は完全な応答が広告値にも収まりません。ここで分かるのは、「完全な1300バイトの応答を、広告値内の一つのUDP応答として扱う」という方針が使えないことです。実際にどのレコードを省き、TCを立てるかは応答の組み立てに依存し、この長さ比較だけでは再現しません。
例3はD=1000、A=1200、P=1200です。二つの長さ比較をともに通ります。それでも、このモデルにはパケット損失や中間装置の規則を入れていないので、「届いた」とは記録できません。条件を満たすことと、受信を観測したことを分けるための例です。
広告値は、名前解決全体を通る一枚の許可証ではない
名前解決では、端末のスタブリゾルバーが再帰リゾルバーへ問い合わせ、再帰リゾルバーが権威サーバーへ問い合わせる場合があります。EDNSはその各組の通信ごとに扱われます。[1、1] 端末側で見た広告値と、再帰リゾルバーが外へ出す問い合わせの広告値は、同じであるとは限りません。
この違いを先ほどのモデルへ加えるなら、端末側の組と権威サーバー側の組に、それぞれ別のAとPを用意します。一方でA=1400、他方でA=1200という入力を与えても矛盾はありません。片側の値を変更しても、もう片側の値まで変わったと記録しないことが大切です。
OPTそのものを通常の回答データとしてキャッシュすることもできません。問い合わせ側が広告する最大ペイロードサイズは、その取引を越えて使うためにキャッシュしてはならないと定められています。[1、6.2.1、6.2.3] 過去の一回で大きい値が見えたことを、相手の恒久的な能力表として使うことは避けます。
「返らない」と「切り詰めが返った」を分ける
診断の記録を作るなら、最初にどの二者間を見たのかを明示します。そのうえで問い合わせの広告値、観測できた応答長、TCビット、再試行した通信方式を並べます。応答を受け取れなかった場合は、受信した応答長やTCを0と埋めず、未観測とします。見えていない値と、観測した0は異なります。
TCは応答が切り詰められたことを示します。RFC 7766は、UDP応答が切り詰められた場合のTCPによる再試行を扱い、DNS実装にTCP対応を求めています。[2、4–5、6.1.2] 一方、応答がまったく見えないタイムアウトだけでは、TCを受け取ったとはいえません。DNSデータの不存在を示す回答を受け取ったことにもなりません。
大きい応答の失敗を調べるときは、サイズを変えた試行だけでなく、TCP経路が利用できるかも別に確かめる必要があります。広告値を下げれば、完全な応答がUDPへ収まらず、別の取り方が必要になる場合があるからです。「小さくすれば必ず成功する」という結論ではなく、どの条件を改善し、どの条件がまだ未確認なのかを残すと、次の調査を選びやすくなります。
出典
- RFC 6891 — Extension Mechanisms for DNS (EDNS(0))、2013年4月。1、6.1.1–6.1.2、6.2.1、6.2.3、7。RFC Editorの状態ページでInternet Standard、STD 75を確認。数値例と図は独自作成。
- RFC 7766 — DNS Transport over TCP – Implementation Requirements、2016年3月、4–5、6.1.2。2026年10月23日確認。本稿はEDNSのサイズ広告と配送条件の区別を扱い、全DNS拡張や個別実装の性能を評価しない。