JPドメイン名のサービス案内、ドメイン名・DNSに関連する情報提供サイト


ドメイン名関連会議報告

2007年

DNSの管理運用と電子メールの国際化における技術動向

2007/12/25

今回のFROM JPRS増刊号では2007年の締めくくりとして、今年のFROM JPRSでご 紹介した主な話題の中から、DNSの管理運用と電子メールの国際化における技術 動向、および国際化TLD(IDN TLD)に関する最新動向について、2本にわたって ご紹介します。

IETF 70ミーティングの様子
IETF 70ミーティングの様子

DNS応答パケットサイズに関する技術的考察

伝統的なDNSで取り扱い可能なUDPパケットの大きさは512バイトまでに制限され ています。そのため、限られたパケットサイズの中で効率的かつ安定的なDNS運 用を実現する必要性から、DNSサーバの運用・実装において、さまざまな配慮が 必要になります。

この制限の存在自体は従来から知られており、これまでは各DNSオペレータによ り、それぞれの運用経験に基づいた対応が行われてきました。そこで、この制 限について改めて体系的に考察し、DNSゾーンの管理者およびDNSサーバの実装 者が配慮すべき点をアドバイスとしてまとめることにより、DNSサーバの安定運 用を行う指針とするための作業が、IETF DNSOP(Domain Name System Operations)WGにおいて進められています。

これまでの作業により以下の内容が、文書の草案(*1)に盛り込まれました。

  • DNS応答パケットサイズを小さくするため、あるゾーンのDNSサーバ名を1つのドメイン名の下にまとめることは有用である
    (例: ?.root-servers.net、?.dns.jp)
  • 上位ゾーンへのグルー(*2)の登録のしかたに関する注意点
  • 全てのDNSサーバ名を1つのドメイン名の下にまとめた場合、あるゾーンのDNSサーバ名として使用可能な最大数は13である
  • RRset(リソースレコードの集合)が大きくなることによる切り詰めの危険性を避けるため、一つのDNSサーバ名に対し二つ以上のIPv4またはIPv6アドレスを登録することは推奨しない
  • ただし上記条件はプロトコルファミリ毎に有効である。すなわち、一つのDNSサーバ名に対し、IPv4アドレスとIPv6アドレスをそれぞれ一つずつ登録することは問題ない
  • DNSサーバがグルーを返す場合に配慮すべき注意点

なお、これらの条件により、

  • 13個のDNSサーバ名が同一ドメイン名の中にある
  • かつ、それぞれのDNSサーバに対し、一つのAレコードが登録されている

場合、すなわち現在のルートゾーンについては、13個のDNSサーバ名のうちの一 部または全部にAAAAレコードが一つ追加登録されたとしても今回の指針を満た すことになります。これは、近い将来予定されているルートサーバのIPv6 対応 (IPv6による到達性の実現)の、技術的な裏付けの一つとなるものです。

(*1)
. Vixie, A. Kato, "DNS Referral Response Size Issues", December 2007
http://www.ietf.org/internet-drafts/draft-ietf-dnsop-respsize-09.txt
(*2)
権威DNSサーバが委譲しているサブドメインのDNSサーバ名を応答する際に付加する情報のこと。具体的には、DNSサーバ名に対応するIPアドレス情報(AまたはAAAAレコード)となる。
IETF 70開催のホテル外観
IETF 70開催のホテル外観

DNSSECの普及に向けた取り組み

DNSSECを運用する場合、インターネット上のすべてのDNSキャッシュサーバにお いて「Trust Anchor」を設定する必要があります。

Trust AnchorとはDNSSECによる検証を行う場合に最初の手がかりとなる情報で あり、DNSSECによる名前検証を行うにあたり、必須となるものです。DNSSECの 仕様では、Trusted AnchorがすべてのDNSキャッシュサーバに設定され、かつ適 切な間隔で更新され続ける必要があります。

Trusted Anchorの更新を自動的に行うためのプロトコル仕様は、RFC 5011によ り規定されています。しかし、RFC 5011で規定されているのは自動更新のプロ トコル仕様のみであり、実際のインターネットにおいて自動更新を具体的にど のように運用するかについては規定されていません。

そこで、運用者が実際に設定するTrust Anchorの形式、DNSキャッシュサーバ起 動時の公開鍵情報を更新するための「Trust Anchor Priming」の方式、DNSキャッ シュサーバにおけるTrust Anchorの定期的な更新方法例とそれぞれの手法に対 する評価結果がまとめられ、IETF DNSOP WGにおいて提案されています(*3)。

今回の提案には、DNSキャッシュサーバの運用コストを軽減させることで DNSSECの普及を支援しようというねらいがあります。
(*3)
M. Larson, O. Gudmundsson, "DNSSEC Trust Anchor Configuration and Maintenance", November 2007
http://www.ietf.org/internet-drafts/draft-larson-dnsop-trust-anchor-02.txt

電子メールアドレスの国際化における技術動向

IETF EAI WGで作業が進められている電子メールアドレスの国際化については、 12月に開催されたIETF 70ミーティングにおいてプロトコル拡張の柱となる4本 のコアドキュメントの未解決事項がほぼ解決し、順次IESGに提出される見込み となりました。なお、現在作成が進められているコアドキュメントの内容につ いては、FROM JPRS 2007年8月13日号「電子メールアドレスの国際化の概要と現 状」(*4)をご参照ください。

(*4)
FROM JPRS 2007年8月13日号「電子メールアドレスの国際化の概要と現状
http://jpinfo.jp/event/2007/0813IETF.html
また、IETF 70ミーティングにおいて、

  1. 2008年1月までにコアドキュメントの最終案をIESGに提出し、RFC化の承認を得る
  2. 2008年3月までにPOPおよびIMAPといった、ユーザが電子メールを取り扱うために必要なプロトコルの拡張仕様に関し、WGでの合意を形成する
  3. 2008年3月および7月の二度にわたり、実験仕様に基づいた試験実装を持ち寄り、実装の評価及び相互接続性の検証を行う
  4. 2008年11月より標準(Standards Track)仕様への移行を図る作業を開始する

という、WGの今後の作業ロードマップが提案・合意されました。

本会議報告は、JPRSのメールマガジン「FROM JPRS」の増刊号として発行した情報に写真などを交えてWebページ化したものです。
「FROM JPRS」にご登録いただいた皆さまには、いち早く情報をお届けしております。ぜひご登録ください。