1.タイトル:JPRS update 2.ロガー:川端宏生(社団法人日本ネットワークインフォメーションセンター(JPNIC)) 3.発表者:森下泰宏 (株式会社日本レジストリサービス(JPRS)) 　　　　 yasuhiro@jprs.co.jp 4.発表日:2003年7月25日(金)13:15-13:40 5.発表の焦点、論点、議題 ・日本語JPドメイン名 　　　　- JANOG11での報告の通り、標準規格(RFC)が決まった。 　　　　- このRFCに対応するためのいくつかの取り組みを紹介する。 ・JP DNSに関する最新動向の紹介 　　　　- JP DNSサーバのホスト名の変更について 　　　　- 電力危機に対する緊急対応について 　　　　- JP DNSサーバのIPアドレス・AS番号の変更について 　- 発表の後に質疑応答が行われた。 6.発表の流れ ・日本語JPドメイン名について 　　- 2003年7月10日より、標準規格(RFC)に準拠した形でのサービスを開始した。 　　- 具体的には以下のRFC(3本)が対象となっている 　　　　+ RFC 3490 :IDNA(Internationalizing Domain Names in Applications) 　　　　+ RFC 3491 :NAMEPREP:(A Stringprep Profile for Internationalized Domain Names) 　　　　+ RFC 3492 :Punycode 　　- これら3つのRFCの中でDNS/Webのオペレータに影響があるのはRFC3492(Punycode) である。 　　- なおPunycode(RFC3492)は日本語JPドメイン名に限らず、すべてのIDN(国際化ドメイン名) 　　　のエンコーディング方式を規定している。 　　- 従来、JPRSではRACE方式で日本語JPドメイン名のサービスを提供していた。 そのため、RFCに準拠したサービスを行うためには、日本語JPドメイン名の エンコード方式をRACE方式からPunycode方式に移行する必要がある。 　　- 移行にあたり、両方のエンコーディング方式を併用する期間を設定する。 　　- 併用期間中は、{RACE}.JPと{Punycode}.JPの双方のドメインについて JP DNSサーバからNSレコードを設定するように対応する。 　　- 具体的な設定例を紹介 　+ 移行にあたって懸念された事項 　　- いわゆるLame delegationといわれる状態が増加することが懸念される。 　　　- JANOGのメーリングリストでも指摘をされている。 　　　　- ここでは、Lame delegationを、あるソーンのDNSサーバとして指定 されているサーバが、本来返すべきAAビットがセットされた応答を 返さない状態と定義する。 　- この影響範囲を考察するために下記のような調査を行った。 　　　- Lame delegationという状態はDNSに対してどのような影響を及ぼすのか。 　- まず、今回の併用期間の開始によるLame Delegationの発生を最小限にするた 　　め、RACEとPunycodeの両方式への対応を行っていただくようにお願いした。主 なお願いした先は以下の通り。 　　　　+JANOGのミーティング、メーリングリスト 　　　　+JPRSの指定事業者(いわゆるレジストラ) 　　　　+JP Direct(JPRSに直接申請している)顧客 　- Lame delegation率を逐次的に調査している 　　　- RACEおよびPunycodeの併用期間については逐次的な調査を予定している。 　　　 　　　- 4本のグラフ 　　　　　+ 青色:RACEおよびPunycodeの両方式とも正しく設定済 　　　　　+ 紫色:RACEおよびPunycodeの両方式ともLame delegation 　　　　　+ 黄色:RACE方式→正しく設定済、Punycode方式→Lame delegation 　　　　　+ 水色:RACE方式→Lame delegation、Punycode方式→正しく設定済 　　　- 7/10以降は併用期間が開始されるが、併用期間開始前までに大手の指定 　　　　事業者を中心に両方式への対応のお願いを行った。 　　　　　　→ その結果、7/9までに概ね対応していただけた。 　　　- 7/10以降は、汎用JPドメイン名や属性型JPドメイン名と大差のない比率 　　　　で推移しているのが現状である。 　- DNSサーバの主な実装について、Lame delegationがある場合にどのような 動作するのかを調査を行った。 　　　- DNSキャッシュサーバの動作について調査を行った。 　　　- 各クライアントからの要求を受け付けて、そこから反復的に各DNSサーバ 　　　　を検索して名前を解決する機能を持つサーバが、DNSキャッシュサーバ。 　　　- Lame delegationが発生している場合に、どういうことが起きるかを調査 　　　- 調べる対象はBIND, djbdns, Windows 2000/2003 Serverとした。 　　　　　- 特にBINDは各バージョンについて調査した 　　　　　　　　+ BIND (9.x, 8.x) 　　　　　　　　+ djbdns 　　　　　　　　+ Windows 2000/2003 Server - BINDは多数出回っていると考えられるため、その中でも最も多く出回っている 考えられるためバージョン8.x系について細かく各バージョンごとに調査を おこなった。 　　　　　　　　+ 9.3.0s20021217, 9.2.2 　　　　　　　　+ 8.4.1-P1, 8.3.6〜8.3.0 　　　　　　　　+ 8.2.7〜8.2.3 　　　　　　　　+ 4.9.11〜4.9.3, 4.8 - Windows2000に関してはノーマルなWindows2000 Server,Windows2000 Server(SP3) Windows2003 server に添付されているものについてそれぞれ調査した。 　　　- 通常、DNSキャッシュサーバでは、キャッシュに何もない状態の場合ルート 　　　　サーバ、JP DNSサーバ、該当するドメイン名のDNSサーバに対して反復的に 　　　　問い合わせを行い結果を得る。該当するドメイン名のDNSサーバにおいて Lame Delegationが発生している場合、 　　　　　　- 1回目は通常の反復問い合わせを行い、結果として失敗する 　　　　　　- 2回目以降は、正常な応答を得られた部分についてはキャッシュに 残っているためルートサーバやJP DNSサーバには問い合わせを行わず、 該当するドメイン名のDNSサーバに直接問い合わせる(結果として失敗 する)。 　　　→ 調査した実装において正常に稼動したものは以下の通りであった。 　　　　 　　　　　+ BIND 9 　　　　　+ BIND 8.3.5以降のBIND8 　　　　　+ BIND 4 　　　　　+ djbdns 　　　　　+ Windows 2003 Server 　　　→ 以下の実装では、Lame Delegation であったこともキャッシュされてし まう。 　　　　　- Lame delegationの状態もキャッシュされてしまうような実装の場合、 Lame delegationの状態を修正してもしばらく名前が引けなくなるお それがある。そのため、Lame Delegationの状態はキャッシュしない ことが望ましいと考えられる。 　　　　　+ BIND 8.3.1-BIND8.3.4 　　　　　+ BIND 8.2.x 　　　→ Windows2000 Serverでは、JP DNSにやや適切でない影響を与える動作をする。 　　　　　- 1回目の問い合わせは通常どおりを行う。キャッシュに 　　　　　　Lame delegationの状態が入っているときの振る舞いとして、組織 　　　　　　のサーバに問い合わせに行き、Lame delegationの状態であること 　　　　　　がわかると、JP DNSに問い合わせを行う。 　　　　　　　　→1回目の問い合わせは通常通り処理される。 →2回目以降の問い合わせでは、該当するドメイン名のDNSサーバに問 い合わせを行い、Lame Delegationの状態であることが判明すると、 再度JP DNSサーバのうちのひとつに問い合わせを行う。 →JP DNSサーバに対して1回無駄な問い合わせパケットが発生する。 　　　→ BIND8.3.0は、上位のサーバに対して膨大なクエリパケットを発生さ 　　　　 せる問題があるため(2002年1月発見)、使用禁止。 　+ Lame delegationの状態がどれぐらい影響を与えるのか。 　　　- 現在までの調査結果では、正しく(注意深く)実装されたDNSキャッシュ サーバであれば、 - 再帰検索要求を受け付ける、各地のDNSキャッシュサーバ - 該当するゾーンのサーバとして指定されているDNSサーバ - 無駄な問い合わせの繰り返しにより消費されるネットワークやシ ステム資源 以外には悪影響を及ぼさない。 　- 上記以外のサーバに関しては悪影響を及ぼすものではない。 　　　- ただし、BIND8.3.0のようにLame delegationをきっかけとして、大事 　　　　故が起こる可能性をはらんでいる。 　　　- 現在の状況を例えると、以下のようになるのではないかと考えている。 　　　- 見通しの悪い交差点に止められた違法駐車(Lame delegation)が 原因で、大事故になる可能性がある。 　+ 今後の予定について 　　　- 併用期間は、RACE対応アプリケーションのPunycodeへの対応を 　　　　確認し、アプリケーション更新のための一定期間経過後に終了予定。 　　　 　　　- RACEに対応した主なアプリケーションは以下のようなものがあり、こ 　　　　れらの対応は以下のようになっている。 　　　　　+ i-Nav(Internet Explorer用日本語ドメイン名プラグイン) - 近日中にPunycode対応予定 　　　　　+ Netscape(Mozilla) - ver.7.1(Mozilla 1.4)でPunycode対応済み 　　　　　+ Opera - ver.7.1はRACEのみ対応 - ver.7.2b2(英語版)はPunycodeのみ対応 　　　- Lame delegationをはじめとして、DNSにおけるさまざまな不備が及ぼす 　　　　影響範囲を継続して調査予定 ・JP DNS アップデート 　+ 最近の主な動き 　　　- JP DNSサーバのホスト名の変更 　　　- 電力危機への緊急対応 　　　- JP DNSサーバのIPアドレスおよび所属AS番号の変更 　+ JP DNSサーバのホスト名の変更 　　　- JP DNSサーバのホスト名を[a-f].dns.jpという名称に統一する。 これは、ルートサーバやgTLDのサーバ等で既に行われている方法と同様で ある。 　　　　　- DNSプロトコルでは既出のドメイン名についてはDNSパケット内で圧縮され 　　　　　　るため、有効なペイロードを確保できる。 　　　- このペイロードをIPv6用エリアとして確保することを考えている。 　　　　　- 引いてみればわかるのだが、現時点ではAAAA glueが３つある。 　　　　　- 当方での調査により、既にAAAA glueをこれ以上安全に追加できない事がわかっている。 　　　- dns.jpゾーンをJP DNSサーバそのものに保持させることにより、委任 　　　　の関係をきれいにすることも目的の一つである。 　+ 電力危機への緊急対応 　　　- WIDE Projectと協調して、e.dns.jpを東京電力のエリア外で稼動させた。 　　　- 稼動にあわせてIPアドレスおよびAS番号の変更を実施 　　　　　- この件に対しては後述 　+ JP DNSサーバのIPアドレスおよび所属AS番号の変更 　　　- 専用のIPアドレス(プロバイダに依存しないIPアドレス)への移行を検討 　　　　　- APNICにおいてcritical infrastructure用として定義されているIPアドレ スの割り当てを受ける予定 　　　- IPアドレス/AS番号の変更についてはe.dns.jpをパイロットケースとし、 一部計画を先行実施している。 　　　　　- 電力危機への緊急対応の件も含まれる 　　　- ルートサーバの一部で既に実施されている、Anycastによるサービスの実施 　　　　も視野に入れている。 　　　　　- １つのIPアドレスで複数のDNSに対応させる 　+ 現在の状況 　　　- jp/*.jpゾーン 　　　　　+ ns.wide.ad.jp → e.dns.jpへの切り替え完了 　　　　　+ [a-d,f].dns.jpへの変更作業が進行中 　　　- JPNICに委譲されている逆引きゾーンに関しては、JPNICと協調して 　　　　[a-f].dns.jpへの移行を実施中である。 　　　　　- 今日は作業実施中なので、途中の状況を見られる状態になっているかも 　　　　　　しれません。 　+ JP DNSの安定運用の計画について 　　　- 以前から東京にしかルートDNSサーバがないなどの背景があり、安定 　　　　運用について問題視されていたが、もう少し積極的に安定運用への取 　　　　り組みを行おうとしている。 　　　- 安定運用への取り組みについては、Webを公開しているので、そちら 　　　　を参考にしてください。 　+ 参考URLとして、技術的な情報を公開している場所は以下のとおりである。 　　　- DNS関連技術情報 　　　　　http://jprs.jp/tech/ 　　　- 日本語ドメイン名について 　　　　　http://jprs.jp/info/notice/idn.html 　　　- 日本語JPドメイン名のRFC準拠に伴う移行について 　　　　　http://jprs.jp/info/notice/ace-transition.html ・質疑応答 　■藤崎さん(NTT) 　+ 多国語ドメイン名に関する対応状況について質問 　　　- Netscape7.1はRACE/Punycode方式の両方とも使えるのか？ 　　　　　→Punycode方式のみである(森下) 　■石田さん(メディアエクスチェンジ(MEX)) 　+ JP DNSのオペレーションの安定運用に関して質問 　　　- 現在のJP DNSが設置されたのは10年前である。 　　　- JP DNSが設置された当時の状況と現在では大きく状況が変わっている 　　　　はずであるから、その状況にあわせたようなサイトセレクションの計 　　　　画はあるのか。 　　　　　→現在の状況に対応させるためにIPアドレスの変更やAnycast など のさまざまな技術を検討している(森下) 　　　- そのプロセスは基本的にわれわれにも公開される形になると認識して いる。逆にいえば、我々がオペレーションに関わりたいと思ったとき に、そのオペレーションに参加するチャンスはあるのか。 　　　　 　　　　ここ数年間で状況があまり見えないようになっていると思われるのだ が、もう少しオペレータにも見える形でやっていくと認識しているの だが。(石田) 　　　　　　→実際にどこまで約束できるかはわからないが、一技術者の目か 　　　　　　　ら見ても、従来はそういった情報の公開が十分ではなかったと 　　　　　　　思っている。 　　　　　　　　情報の公開が十分ではなかったので、情報を積極的に公開し 　　　　　　　て、我々もきちんとやっているということを外に見せていこう 　　　　　　　と考えている。 　　　　　　　　私もいちエンジニアであるので、エンジニアの皆さんを裏切ら 　　　　　　　ないような形ですすめていきたい、と考えている。(森下) 7. 感想 　日本語JPドメインへの対応は着実に進んでいる感じがした。技術的な対応が 進んで、もっと積極的に利用されるようになって欲しいと思う。 　DNSを取り囲む状況も刻々と変化しているので、それに柔軟に対応できるよう に頑張って欲しいと思います。