JPドメイン名のサービス案内、ドメイン名・DNSに関連する情報提供サイト
JPドメイン名のサービス案内、ドメイン名・DNSに関連する情報提供サイト
増刊号
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━2007-12-21━
◆ FROM JPRS 増刊号 vol.82 ◆
━！ＪＰ━━━━━━━━━━━━━━━━━━━━━━━━━ＪＰＲＳ━━
＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┓
DNSの管理運用と電子メールの国際化における技術動向
┗━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
今回のFROM JPRS増刊号では2007年の締めくくりとして、今年のFROM JPRSでご
紹介した主な話題の中から、DNSの管理運用と電子メールの国際化における技術
動向、および国際化TLD（IDN TLD）に関する最新動向について、2本にわたって
ご紹介します。
◇ ◇ ◇
■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）P. 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レコード）となる。
■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の今後の作業ロードマップが提案・合意されました。
◇ ◇ ◇
◎関連URI
Domain Name System Operations (dnsop) Charter
http://www.ietf.org/html.charters/dnsop-charter.html
（IETF DNSOPワーキンググループ）
Email Address Internationalization (eai) Charter
http://www.ietf.org/html.charters/eai-charter.html
（IETF EAIワーキンググループ）
StJohns, M., "Automated Updates of DNS Security (DNSSEC) Trust
Anchors", RFC 5011, September 2007
http://www.ietf.org/rfc/rfc5011.txt
━！ＪＰ━━━━━━━━━━━━━━━━━━━━━━━━━ＪＰＲＳ━━
編集・発行：株式会社日本レジストリサービス(JPRS)
http://jprs.jp/
http://日本レジストリサービス.jp/
会議報告： http://jpinfo.jp/event/
メールニュース配信解除： http://jpinfo.jp/mail/kaijyo.html
ご意見・ご要望： from@jprs.jp
当メールマガジンの全文または一部の文章をホームページ、メーリングリスト、
ニュースグループまたは他のメディア等へ許可なく転載することを禁止します。
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Copyright(C), 2007 Japan Registry Services Co., Ltd. 2007年12月21日
Copyright©2001-2024 Japan Registry Services Co., Ltd.