メインコンテンツへジャンプする

JPNICはインターネットの円滑な運営を支えるための組織です

ロゴ:JPNIC

WHOIS 検索 サイト内検索 WHOISとは? JPNIC WHOIS Gateway
WHOIS検索 サイト内検索

EDNS0とは

EDNS0とは、RFC2671で規定されるDNSの拡張プロトコルです。

DNSでやりとりされる、問い合わせや応答メッセージのプロトコルは、 RFC1035で規定されていますが、そのフォーマットは、 RFC1035が策定された1980年代当時におけるインターネットの状況が反映されており、 厳しく制約されたものとなっています。 例えば、OPCODEやRCODEと呼ばれるフィールドの大きさは4ビット(10進数で0~15)とされているなど、 いくつかのフィールドは長さが固定長として定義され、 指定できる数値の範囲が限定されています。また、数値を格納するフィールドだけでなく、 AAビットやTCビットのようなヘッダフラグの数も、 あらかじめ固定的に決められています。

RFC1035の策定時から年月がたつにつれ、 DNSメッセージにさまざまな情報を含めたいという要望が増え、 当初は空いていた予約・未割り当てコードも徐々に割り当てられていき、 その残り数は少なくなっていきました。

そうした状況から、将来にわたってプロトコルを拡張できるように、 また、従来のDNSクライアントに影響を与えないように、 1999年、RFC2671としてEDNS0が策定されました。 EDNS0で拡張される点として、主に以下のものがあげられます。

  1. DNSメッセージヘッダ: RCODEやフラグの拡張
  2. DNSラベルタイプ: ラベル型の拡張
  3. DNSメッセージのUDPペイロードサイズ: 最大512オクテットの制限を通信可能であれば65535オクテットまでに拡張

近年、負荷分散や障害に対する耐性の向上を目的として、 一つのドメイン名に多数のレコードを割り当てることがあります。 また、IPv6、ENUM、DNSSECをはじめとした新しい技術への対応などによって、 DNSメッセージに含まれる情報は増加する傾向にあります。 例えば、IPv6ではそのアドレスの長さからIPv4と比較して大きなレコードが使用され、 また、DNSSECでも新しいヘッダフラグの追加および電子署名による長大なレコードが使用されることになります。 事実上これらのプロトコルでは、EDNS0の使用が前提となるため、 IPv6やDNSSECのメッセージを取り扱うDNSサーバは、 EDNS0をサポートすることがRFC3226で必須とされました。

Extension Mechanisms for DNS (EDNS0):
  http://www.ietf.org/rfc/rfc2671.txt
  http://www.nic.ad.jp/ja/translation/rfc/2671.html

DOMAIN NAMES - IMPLEMENTATION AND SPECIFICATION:
  http://www.ietf.org/rfc/rfc1035.txt

DNSSEC and IPv6 A6 aware server/resolver message size requirements:
  http://www.ietf.org/rfc/rfc3226.txt

Domain Name System (DNS) Parameters:
  http://www.iana.org/assignments/dns-parameters

JPNIC News & Views vol.770(2010年8月16日発行)より

このページを評価してください

このWebページは役に立ちましたか?
よろしければ回答の理由をご記入ください

それ以外にも、ページの改良点等がございましたら自由にご記入ください。

回答が必要な場合は、お問い合わせ先をご利用ください。

ロゴ:JPNIC

Copyright© 1996-2024 Japan Network Information Center. All Rights Reserved.