ドメイン名関連会議報告
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開催のホテル外観
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
- 2008年1月までにコアドキュメントの最終案をIESGに提出し、RFC化の承認を得る
- 2008年3月までにPOPおよびIMAPといった、ユーザが電子メールを取り扱うために必要なプロトコルの拡張仕様に関し、WGでの合意を形成する
- 2008年3月および7月の二度にわたり、実験仕様に基づいた試験実装を持ち寄り、実装の評価及び相互接続性の検証を行う
- 2008年11月より標準(Standards Track)仕様への移行を図る作業を開始する
という、WGの今後の作業ロードマップが提案・合意されました。
本会議報告は、JPRSのメールマガジン「FROM JPRS」の増刊号として発行した情報に写真などを交えてWebページ化したものです。
「FROM JPRS」にご登録いただいた皆さまには、いち早く情報をお届けしております。ぜひご登録ください。