Loading article…
DNS の拡張メカニズム( EDNS ) は、ドメイン ネーム システム(DNS) プロトコルのいくつかのパラメータのサイズを拡張するための仕様です。このプロトコルには、インターネットエンジニアリング コミュニティによって、プロトコルの機能を増やすにはサイズ制限が厳しすぎると判断されていました。最初の拡張セットは、1999 年にインターネット エンジニアリング タスク フォースによってRFC 2671 (EDNS0 とも呼ばれる)として公開されました[1] 。これは、2013 年にRFC 6891によって更新され、 略称がわずかにEDNS(0)に変更されました[2]。
モチベーション
ドメインネーム システムは、1980 年代初頭に初めて開発されました。それ以来、プロトコルの以前のバージョンとの互換性を維持しながら、新しい機能が徐々に追加されてきました。
基本的な DNS プロトコルで使用できるいくつかのフラグ フィールド、リターン コード、ラベル タイプのサイズ制限により、いくつかの望ましい機能のサポートが妨げられました。さらに、UDPで伝送される DNS メッセージは、インターネット プロトコル(IP) とトランスポート層ヘッダーを考慮に入れずに 512 バイトに制限されていました。[3]伝送制御プロトコル(TCP)を使用した仮想回線トランスポートに頼ると、オーバーヘッドが大幅に増加します。これは、DNS に新しい機能を追加する上で大きな障害となりました。1999 年に、Paul Vixie は、新しいフラグと応答コードを許可し、以前の実装と下位互換性のあるフレームワークでより長い応答をサポートするように DNS を拡張することを提案しました。
機構
DNS ヘッダーに新しいフラグを追加できなかったため、EDNS は DNS メッセージの「追加データ」セクションに含まれる疑似リソース レコード(「疑似 RR」)の形式で DNS メッセージに情報を追加します。このセクションは要求と応答の両方に存在することに注意してください。
EDNS は単一の疑似 RR タイプを導入します: OPT。
疑似 RR である OPT タイプの RR は、どのゾーン ファイルにも表示されません。DNS 参加者によって作成されたメッセージ内にのみ存在します。
このメカニズムは下位互換性があります。古い DNS レスポンダは要求内の不明な OPT タイプの RR を無視し、新しい DNS レスポンダは要求に OPT が含まれていない限り応答に OPT を含めないためです。要求に OPT が含まれているということは、新しい要求側が応答内の OPT をどのように処理するかを知っていることを意味します。
OPT 疑似レコードは、最大 16 個のフラグのためのスペースを提供し、応答コードのためのスペースを拡張します。UDPパケットの全体的なサイズとバージョン番号 (現在は 0) は、OPT レコードに含まれています。可変長データ フィールドにより、プロトコルの将来のバージョンでさらに情報を登録できます。元の DNS プロトコルでは、ラベルの長さオクテットの最初の 2 ビットで定義される 2 つのラベル タイプが提供されていました (RFC 1035)。00 (標準ラベル) と 11 (圧縮ラベル) です。EDNS では、ラベル タイプ 01 が拡張ラベルとして導入されています。最初のバイトの下位 6 ビットを使用して、最大 63 個の新しい拡張ラベルを定義できます。
例
dig コマンドで表示される OPT 疑似レコードの例:
;; OPT擬似セクション: ; EDNS: バージョン: 0、フラグ: do; udp: 4096
「EDNS: version: 0」の結果は、EDNS0に完全に準拠していることを示します。[4]「flags: do」の結果は、「DNSSEC OK」が設定されていることを示します。[5]
アプリケーション
ドメイン名
EDNSはDNSセキュリティ拡張（ DNSSEC ）の実装に不可欠です。[6]
EDNS パディング
EDNSを使用してDNSメッセージの周囲にどのくらいのパディングを入れるかを設定するための標準があります。[7] [8] DNSを暗号化する場合、パディングは不可欠です。パディングがないと、暗号化されたクエリのサイズからクエリされたドメイン名を特定できる可能性があるためです。
EDNS キープアライブ
EDNSはTCP接続をどのくらいの時間維持するかを示すために使用されます。[9]
EDNS クライアント サブネット (ECS)
EDNSは、 EDNSクライアントサブネット（ECS）オプションの形式で、リゾルバからネームサーバーにクライアントの地理的位置に関する一般的な情報を送信するためにも使用されます。[10]
問題
実際には、ファイアウォールを通過する EDNS を使用すると、一部のファイアウォールが DNS メッセージの最大長を 512 バイトと想定し、それより長い DNS パケットをブロックするため、問題が発生する可能性があります。
EDNS の導入により、比較的小さな要求パケットに比べて非常に大きな応答パケットが可能になるため、反射型サービス拒否攻撃の一種であるDNS 増幅攻撃が可能になりました。
参考文献
- ^ RFC 2671、DNS の拡張メカニズム (EDNS0)、P. Vixie、インターネット協会 (1999 年 8 月)
- ^ RFC 6891、DNS の拡張メカニズム (EDNS(0))、J. Damas、M. Graff、P. Vixie、(2013 年 4 月)
- ^ RFC 1035、ドメイン名 - 実装と仕様、P. Mockapetris (1987 年 11 月)
- ^ IETF のネットワーク ワーキング グループ、1999 年 8 月、RFC 2671: DNS の拡張メカニズム (EDNS0)、3 ページ、この仕様への完全な準拠はバージョン「0」で示されます。
- ^ IETF のネットワーク ワーキング グループ、2001 年 12 月、RFC 3225: DNSSEC のリゾルバ サポートの指定、3 ページ、クライアントが DNSSEC セキュリティ RR を受け入れる (理解する) 能力を明示的に通知するために選択されたメカニズムは、クエリの EDNS0 OPT ヘッダーの Z フィールドの最上位ビットを使用することです。このビットは、「DNSSEC OK」(DO) ビットと呼ばれます。
- ^ RFC 4035、DNS セキュリティ拡張のプロトコル変更、R. Arends、Telematica Instituut、2005 年。セクション 4.1 EDNS サポート
- ^ Mayrhofer, Alexander (2016年5月). 「RFC 7830: EDNS(0) パディングオプション」. tools.ietf.org . 2018年2月2日閲覧。
- ^ Mayrhofer, Alexander (2018年10月). 「RFC 8467: DNSの拡張メカニズムのパディングポリシー (EDNS(0))」. tools.ietf.org . 2018年10月1日閲覧。
- ^ Wouters, Paul (2016 年 4 月). 「RFC 7828: edns-tcp-keepalive EDNS0 オプション」. tools.ietf.org . 2018 年 2 月 2 日閲覧。
- ^ Contavalli, Carlo (2016 年 5 月). 「RFC 7871: DNS クエリのクライアント サブネット」. tools.ietf.org . 2018 年 2 月 2 日閲覧。
参照
- EDNS クライアント サブネット
- DNS フラッグデー 2019