1. Introduction (はじめに)

1. Introduction (はじめに)

DNS [RFC1035] はメッセージ形式を規定しており, このようなメッセージ内には, オプション, エラー, および名前圧縮をエンコードするための標準形式があります。この文書で説明されている拡張機能を使用しない場合, UDP 上の DNS メッセージの最大許容サイズは 512 バイトです。UDP 上の最大メッセージサイズなどの DNS のプロトコル制限の多くは, DNS で伝達できる追加情報 (複数の IPv6 アドレスや DNS セキュリティ (DNSSEC) 署名など) を効率的にサポートするには小さすぎます。最後に, RFC 1035 は, 実装が相互作用する他のアクターに対して自身の能力をアドバタイズする方法を定義していません。

[RFC2671] は DNS に拡張メカニズムを追加しました。これらのメカニズムは広くサポートされており, 多くの新しい DNS 用途とプロトコル拡張がこれらの拡張の存在に依存しています。このメモは [RFC2671] を改良し, 廃止します。

非拡張エージェントは, [RFC2671] で定義され, ここで再記述されるプロトコル拡張を解釈する方法を知りません。拡張エージェントは, 新しいプロトコル要素に直面して非拡張クライアントとの相互作用を処理する準備が必要であり, 非拡張 DNS に優雅にフォールバックします。

EDNS は DNS のホップバイホップ拡張です。これは, EDNS の使用が DNS 解決プロセスの各ホストペア間で交渉されることを意味します。たとえば, スタブリゾルバが再帰リゾルバと通信する場合, または再帰リゾルバが権威サーバと通信する場合です。

[RFC2671] は拡張ラベルタイプを規定しました。提案された唯一のそのようなラベルは, [RFC2673] における "ビット文字列ラベル" または "バイナリラベル" と呼ばれるラベルタイプであり, 後者が一般的に使用される用語です。さまざまな理由により, 新しいラベルタイプの導入は非常に困難であることがわかり, [RFC2673] は実験的に移行されました。この文書は [RFC2673] を廃止し, バイナリラベルを非推奨にします。拡張ラベルは依然として定義されていますが, 展開の実際的な困難のため, その使用は推奨されません。将来の使用は, 展開の障害を慎重に評価した後にのみ検討すべきです。