ドメイン名関連会議報告
2003年
第58回IETF Meeting報告
2003/12/01
2003年11月9日から14日にかけて、第58回IETF Meetingが、米国のミネアポリスで開催されました。多くのテーマが議論されるIETFの中から、DNSやドメイン名に関連する話題をお届けします。
インターネット全体の状況が報告されたIEPG Meeting、ドメイン名の国際化に続いてメールアドレスの国際化を議論しているIEA BoF、Whoisに代わる次世代の技術を検討しているCRISP WG、DNSSECを中心にDNSの拡張機能について議論しているDNSEXT WG、DNSの運用技術を検討しているDNSOP WG、電話番号をDNSで扱う技術を検討しているENUM WG、そして複雑なネットワークの運用のための新たなプロトコルを議論するNETCONF WGの7つの会議の模様をお伝えします。
IETF Administration Plenaryの様子(Minneapolis Hilton and Towers, Minneapolis)
インターネット全体の状況が報告されたIEPG Meeting、ドメイン名の国際化に続いてメールアドレスの国際化を議論しているIEA BoF、Whoisに代わる次世代の技術を検討しているCRISP WG、DNSSECを中心にDNSの拡張機能について議論しているDNSEXT WG、DNSの運用技術を検討しているDNSOP WG、電話番号をDNSで扱う技術を検討しているENUM WG、そして複雑なネットワークの運用のための新たなプロトコルを議論するNETCONF WGの7つの会議の模様をお伝えします。
IETF Administration Plenaryの様子(Minneapolis Hilton and Towers, Minneapolis)
IEPG(Internet Engineering and Planning Group) Meeting
IEPGは、インターネットサービスオペレータで構成される、インターネットの技術や方針を議論するグループです。IETF Meetingが始まる日曜日に会議を開催し、主に地域インターネットレジストリ（RIR）オペレータやccTLDオペレータ等が報告・議論を行いました。
1. 地域インターネットレジストリからの報告
まず最初に、AfriNIC、APNIC、ARIN、LACNIC、RIPE NCCの最新動向と、IPアドレスやAS番号の割り当て状況が報告されました。
この中で、APNICはISCと協調してFルートサーバのアジア展開を行っており、現在は香港・ソウル・北京で運用していること、Iルートサーバの管理組織とも協定を結び、6ヶ月でFとIあわせて5サイトの展開を計画していることが報告されました。
RIPE NCCからは、ヨーロッパでKルートサーバの展開を行なっており、アムステルダムとロンドンで運用していることが報告されました。
2. LACNICでの不適切なDNS設定対策
LACNICから、DNS設定状況の調査と、改善への対策について報告がありました。LACNICでは、正しく設定されているDNSサーバだけをレジストリに登録できるようにしています。その結果、2002年12月に45%だった不適切なDNS設定が、2003年6月には34.9%に、2003年11月には26.7%に減りました。また、毎週すべてのDNS設定をチェックし、Whoisで表示し、登録者に連絡していることが報告されました。
これに関連して会場から、対策方法を検討するためにも、不適切なDNS設定の分類に関する標準を定義しようという提案がありました。
3. APNICでのDNSクエリ測定結果
APNICから、オーストラリア、香港、日本にあるAPNICのDNSサーバへのクエリを解析した結果が報告されました。IPv4での検索数はほぼ一定になってきていますが、IPv6での問い合わせは少ないながらも順調に増えているそうです。また、昨年の8月や今年の1月のワーム（コンピュータ・ウイルスの一種）により、DNSへの問い合わせが激増したことが示されました。また、IPv6での問い合わせは少ないため、研究者がIPv6利用度などを調べるためにDNSへの問い合わせを行なうとそれがピークとして表れることも示されました。
4. IPv4アドレスの寿命についての考察
現在使われていないIPv4アドレスを使い切るまでの時間の予測に関するGeoffHuston氏の考察が報告されました。2020年にIANAの保有IPアドレスがなくなり、2025年に地域レジストリの持つIPアドレスが枯渇するという推測結果でした。
1. 地域インターネットレジストリからの報告
まず最初に、AfriNIC、APNIC、ARIN、LACNIC、RIPE NCCの最新動向と、IPアドレスやAS番号の割り当て状況が報告されました。
この中で、APNICはISCと協調してFルートサーバのアジア展開を行っており、現在は香港・ソウル・北京で運用していること、Iルートサーバの管理組織とも協定を結び、6ヶ月でFとIあわせて5サイトの展開を計画していることが報告されました。
RIPE NCCからは、ヨーロッパでKルートサーバの展開を行なっており、アムステルダムとロンドンで運用していることが報告されました。
2. LACNICでの不適切なDNS設定対策
LACNICから、DNS設定状況の調査と、改善への対策について報告がありました。LACNICでは、正しく設定されているDNSサーバだけをレジストリに登録できるようにしています。その結果、2002年12月に45%だった不適切なDNS設定が、2003年6月には34.9%に、2003年11月には26.7%に減りました。また、毎週すべてのDNS設定をチェックし、Whoisで表示し、登録者に連絡していることが報告されました。
これに関連して会場から、対策方法を検討するためにも、不適切なDNS設定の分類に関する標準を定義しようという提案がありました。
3. APNICでのDNSクエリ測定結果
APNICから、オーストラリア、香港、日本にあるAPNICのDNSサーバへのクエリを解析した結果が報告されました。IPv4での検索数はほぼ一定になってきていますが、IPv6での問い合わせは少ないながらも順調に増えているそうです。また、昨年の8月や今年の1月のワーム（コンピュータ・ウイルスの一種）により、DNSへの問い合わせが激増したことが示されました。また、IPv6での問い合わせは少ないため、研究者がIPv6利用度などを調べるためにDNSへの問い合わせを行なうとそれがピークとして表れることも示されました。
4. IPv4アドレスの寿命についての考察
現在使われていないIPv4アドレスを使い切るまでの時間の予測に関するGeoffHuston氏の考察が報告されました。2020年にIANAの保有IPアドレスがなくなり、2025年に地域レジストリの持つIPアドレスが枯渇するという推測結果でした。
IEA(Internationalizing Email Addresses) BoF
IEA BoFは、電子メールアドレスを国際化するためにIETFでは何を、どのようなアプローチで進めていけばよいか、そしてそれを進めていく意思を持った人がいるか、ということを確認するための場として開催されました。
国際化ドメイン名の標準化過程を経て、IETFでは識別子の国際化（プロトコルの拡張）に対する需要が認識され、関心が高まっています。一方で、これまでのインターネットは英数字を識別子の基本として発展してきており、プロトコルの拡張には、既存システムとの下位互換性と相互運用性の維持が求められています。
電子メールアドレスは、インターネットで最も利用されている識別子であり、アットマーク「@」をはさんで、ユーザ部（アットマークの左側）とドメイン部（アットマークの右側）から構成されています。ドメイン部は既に国際化されており、ユーザ部の国際化も自然な要求ですが、この部分は他のさまざまなプロトコルでも識別子として使用されており、メール配送システムだけで議論を行うことはできません。
現在、IETFでは電子メールアドレスの国際化方式として、以下の2つが提案されています。
IEA BoFでは上記2つの提案に加え、電子メールアドレスを含むインターネット上のリソース識別子（URI）を国際化する提案（IRI: Internationalized URI）の標準化作業の中で電子メールアドレスの国際化を進めていこうという提案も議論されました。
BoFという性格上、どの方式を選ぶといった結論には至っていませんが、議論の中では以下のような意見が寄せられました。
最終的に、1、2のそれぞれの方式について推進していく意思のある人が挙手によって確認され、メーリングリストで議論を継続していくことになりました。
国際化ドメイン名の標準化過程を経て、IETFでは識別子の国際化（プロトコルの拡張）に対する需要が認識され、関心が高まっています。一方で、これまでのインターネットは英数字を識別子の基本として発展してきており、プロトコルの拡張には、既存システムとの下位互換性と相互運用性の維持が求められています。
電子メールアドレスは、インターネットで最も利用されている識別子であり、アットマーク「@」をはさんで、ユーザ部（アットマークの左側）とドメイン部（アットマークの右側）から構成されています。ドメイン部は既に国際化されており、ユーザ部の国際化も自然な要求ですが、この部分は他のさまざまなプロトコルでも識別子として使用されており、メール配送システムだけで議論を行うことはできません。
現在、IETFでは電子メールアドレスの国際化方式として、以下の2つが提案されています。
- 国際化されたメールアドレスを、既存のシステムと互換性のあるASCII文字列（ACE: ASCII Compatible Encoding）に変換して扱う方式
- 国際化されたメールアドレスを国際化拡張として定義し、通信相手が国際化拡張を扱えるかどうかを最初に確認する方式
IEA BoFでは上記2つの提案に加え、電子メールアドレスを含むインターネット上のリソース識別子（URI）を国際化する提案（IRI: Internationalized URI）の標準化作業の中で電子メールアドレスの国際化を進めていこうという提案も議論されました。
BoFという性格上、どの方式を選ぶといった結論には至っていませんが、議論の中では以下のような意見が寄せられました。
- 1の方式は短期的解決である
- できることから始めるべきである
- 既存のプロトコルを変更しようとしているのか、新しいプロトコルを作ろうとしているのか、その決定がまず重要である
最終的に、1、2のそれぞれの方式について推進していく意思のある人が挙手によって確認され、メーリングリストで議論を継続していくことになりました。
CRISP(Cross Registry Information Service Protocol) WG
CRISP WGは、これまでのWhoisを機能的に置き換え、ドメイン名情報などのインターネット資源情報を検索するための新しいプロトコルを検討するWGです。
前回のIETFからの大きな進捗としては、これまでIRISとFIRSという2つの実装案が比較検討されてきた結果として、IRISをWGの実装案として正式に採択したことがあげられます。
また、ドキュメント全体の構造が整理され、特にIPアドレスに関する要求仕様の部分がより明確に分離されました。この動きに関連して、これまでドメイン名関連ドキュメントを中心に、早期のRFC化を目指していた目標を部分的に見直し、2004年の前半を目処にIESGへのドキュメント提出を計ることになりました。
今後のCRISP WGでは、再設定されたマイルストーンに基づき、来年2月のソウルでのIETF、更には6月のIETFに向けてドキュメンテーション作業やメーリングリストにおける議論を続けていくことになっています。
前回のIETFからの大きな進捗としては、これまでIRISとFIRSという2つの実装案が比較検討されてきた結果として、IRISをWGの実装案として正式に採択したことがあげられます。
また、ドキュメント全体の構造が整理され、特にIPアドレスに関する要求仕様の部分がより明確に分離されました。この動きに関連して、これまでドメイン名関連ドキュメントを中心に、早期のRFC化を目指していた目標を部分的に見直し、2004年の前半を目処にIESGへのドキュメント提出を計ることになりました。
今後のCRISP WGでは、再設定されたマイルストーンに基づき、来年2月のソウルでのIETF、更には6月のIETFに向けてドキュメンテーション作業やメーリングリストにおける議論を続けていくことになっています。
DNSEXT(DNS Extensions) WG
DNSEXT WGは、DNSの各機能の拡張に関する議論を行うためのWGです。DNSEXT WGでは現在、DNSの運用においてセキュリティを確保するための技術であるDNSSECのドキュメント改定とproposed standard RFC化を最優先の課題としており、また既存の各種DNSプロトコルのdraft standard化や、DNSの各仕様に関する明確化などに取り組んでいます。
今回のWG Meetingでは新たなプロトコルの提案は行われず、draft standard化のための各活動状況に関する報告と、ゾーン情報中のワイルドカードの取り扱いの明確化に関する議論が行われました。
ワイルドカードに関しては、各資源レコードにおけるワイルドカードの取り扱いがRFC1034で明確に定義されていないため、その明確化に向けた議論が行われました。特にNSレコードとSOAレコードに限っては、その場で挙手による確認が行われた結果、これらの資源レコードにおけるワイルドカードはDNSプロトコルにおいて禁止（outlaw）とすべきであるという合意が形成されました。
その後は、会議の大半の時間がDNSSECドキュメントの改定に関する報告・議論と合意の形成に費やされました。
今回のWG Meetingではこれまでの作業結果により以下の3本のInternet Draftが作成されたことが報告されました。
最後に、DNSSECに関する今後のスケジュールと現在の実装状況についての確認が行われました。DNSSECのドキュメント改定については年内にWGにおけるLast Call（合意に向けた最終確認）を行いたいとのことでした。
また、現在の実装状況については、コンテンツサーバではBIND 9とNSDが近日中に改訂版のDNSSECを実装予定とのことでした。またキャッシュサーバとしてはBIND 9とIDsA(*)での実装作業が進行中であるとの報告があり、最後に「もっとDNSSECの実装を作ろう」という呼びかけがWGチェアからありました。
*: IDsA(Infrastructure DNS securise et Applications)
http://www.idsa.prd.fr/
今回のWG Meetingでは新たなプロトコルの提案は行われず、draft standard化のための各活動状況に関する報告と、ゾーン情報中のワイルドカードの取り扱いの明確化に関する議論が行われました。
ワイルドカードに関しては、各資源レコードにおけるワイルドカードの取り扱いがRFC1034で明確に定義されていないため、その明確化に向けた議論が行われました。特にNSレコードとSOAレコードに限っては、その場で挙手による確認が行われた結果、これらの資源レコードにおけるワイルドカードはDNSプロトコルにおいて禁止（outlaw）とすべきであるという合意が形成されました。
その後は、会議の大半の時間がDNSSECドキュメントの改定に関する報告・議論と合意の形成に費やされました。
今回のWG Meetingではこれまでの作業結果により以下の3本のInternet Draftが作成されたことが報告されました。
- "DNS Security Introduction and Requirements" draft-ietf-dnsext-dnssec-intro-07.txt
- "Resource Records for DNS Security Extensions" draft-ietf-dnsext-dnssec-records-05.txt
- "Protocol Modifications for the DNS Security Extensions" draft-ietf-dnsext-dnssec-protocol-03.txt
最後に、DNSSECに関する今後のスケジュールと現在の実装状況についての確認が行われました。DNSSECのドキュメント改定については年内にWGにおけるLast Call（合意に向けた最終確認）を行いたいとのことでした。
また、現在の実装状況については、コンテンツサーバではBIND 9とNSDが近日中に改訂版のDNSSECを実装予定とのことでした。またキャッシュサーバとしてはBIND 9とIDsA(*)での実装作業が進行中であるとの報告があり、最後に「もっとDNSSECの実装を作ろう」という呼びかけがWGチェアからありました。
*: IDsA(Infrastructure DNS securise et Applications)
http://www.idsa.prd.fr/
DNSOP(Domain Name System Operations) WG
DNSOP WGは、実際にDNSを運用するにあたっての問題点を洗い出し、これからの運用方法についての標準的なアプローチを選ぶために行われています。
DNSEXTでDNSSECのプロトコル仕様を議論しているのに対応して、DNSOPでは運用技術を議論のテーマとしています。
DNSSECでは公開鍵暗号技術を用いており、ゾーン情報への電子署名やゾーンの委任関係の認証を行います。しかし、何らかの理由で鍵が更新された場合、新たな鍵情報をそれを必要とするDNSサーバすべてに配布する負荷が非常に高いため、一度に全ての鍵更新を行うのではなく、逐次的に、しかも自動で行う機構が必要となります。このための必要事項として、いつでも鍵の連鎖を参照できること、DNSキャッシュサーバでの動作を考慮することなどがあげられました。
また、DNSSECに関する問題は、実験やワークショップなどで実際に動かしてみないとわからないものも多くあります。そのため、DNSSECを使った場合と使わない場合のDNSの運用の違いを見つけ出し、DNSSECの運用にあたっての基本的なドキュメントを作成する必要がある、という認識を共有し、進めていくこととなりました。
DNSEXTでDNSSECのプロトコル仕様を議論しているのに対応して、DNSOPでは運用技術を議論のテーマとしています。
DNSSECでは公開鍵暗号技術を用いており、ゾーン情報への電子署名やゾーンの委任関係の認証を行います。しかし、何らかの理由で鍵が更新された場合、新たな鍵情報をそれを必要とするDNSサーバすべてに配布する負荷が非常に高いため、一度に全ての鍵更新を行うのではなく、逐次的に、しかも自動で行う機構が必要となります。このための必要事項として、いつでも鍵の連鎖を参照できること、DNSキャッシュサーバでの動作を考慮することなどがあげられました。
また、DNSSECに関する問題は、実験やワークショップなどで実際に動かしてみないとわからないものも多くあります。そのため、DNSSECを使った場合と使わない場合のDNSの運用の違いを見つけ出し、DNSSECの運用にあたっての基本的なドキュメントを作成する必要がある、という認識を共有し、進めていくこととなりました。
ENUM(Telephone Number Mapping) WG
ENUMは、電話番号をドメイン名に対応させ、電話番号に対応するURIをDNSに登録する技術です。ENUM WGはENUM技術の標準を決め、運用のための技術資料を作成し、ENUM運用に関する情報交換を行なうことを目的としています。
最新のENUMプロトコルであるRFC2916bisは、2003年5月にWGで確定し、現在はIESGでのレビュー中となっています。標準化のための技術的検討を終えて、RFCとしての発行を待つ段階でもあり、議論は実装と運用に関する部分に比重が移っています。
ミーティングにおいては、ENUMプロトコルドキュメントでは詳細に定めていない部分で、実際にENUMクライアントを実装する場合に問題となる点について、どう実装すればよいか細かい提案がありました。
また、ポーランドと韓国からENUMトライアルの状況が報告されました。ポーランドではccTLDオペレータがレジストリを行ない、電話会社がそれぞれの管理する電話番号についてのレジストラとなり、番号利用者を認証してENUMの登録を行っているとのことでした。韓国でも同様に、電話会社が番号利用者を認証していると報告されました。
最新のENUMプロトコルであるRFC2916bisは、2003年5月にWGで確定し、現在はIESGでのレビュー中となっています。標準化のための技術的検討を終えて、RFCとしての発行を待つ段階でもあり、議論は実装と運用に関する部分に比重が移っています。
ミーティングにおいては、ENUMプロトコルドキュメントでは詳細に定めていない部分で、実際にENUMクライアントを実装する場合に問題となる点について、どう実装すればよいか細かい提案がありました。
また、ポーランドと韓国からENUMトライアルの状況が報告されました。ポーランドではccTLDオペレータがレジストリを行ない、電話会社がそれぞれの管理する電話番号についてのレジストラとなり、番号利用者を認証してENUMの登録を行っているとのことでした。韓国でも同様に、電話会社が番号利用者を認証していると報告されました。
NETCONF(Network Configuration) WG
ネットワークの高度な運用が可能になった現在、ネットワークオペレータは各機器ベンダ毎に、その特性や設定、それに影響する状態の把握、機器間の連携、ユーザ認証や機器のエラー情報の取得など、さまざまな事象を個別に理解し連携を図らなければならないという複雑な状況に追い込まれています。
NETCONF WGは、このようなネットワークの設定や制御を行うのに最良のプロトコルを実現する事を目的に、第54回IETF（横浜）でのXMLCONF BoF、第56回IETF（サンフランシスコ）でのNETCONF BoFを経て、WGとして前回の第57回IETF（ウィーン）で設立されました。
前回のIETFでの議論内容を元に、その後もNETCONFプロトコルの詳細内容について議論され、今回の会議までに下記4つのドキュメントが提出されました。
今回の会議は、これらのドキュメントについて、それぞれ合意を得る事を目的として開催されました。
各ドキュメントの内容があまりにも膨大なため、会議も2日に分けて行われ、未決定項目についての決定や、ドキュメント中の問題点についての質疑応答など、さまざまな議論が行われ、概ね順調に合意が得られました。
結果、これらNETCONFプロトコルのLastCallを次のステップとして進めていくことになりました。
本会議報告は、JPRSのメールマガジン「FROM JPRS」の増刊号として発行した情報に写真などを交えてWebページ化したものです。
「FROM JPRS」にご登録いただいた皆さまには、いち早く情報をお届けしております。ぜひご登録ください。
NETCONF WGは、このようなネットワークの設定や制御を行うのに最良のプロトコルを実現する事を目的に、第54回IETF（横浜）でのXMLCONF BoF、第56回IETF（サンフランシスコ）でのNETCONF BoFを経て、WGとして前回の第57回IETF（ウィーン）で設立されました。
前回のIETFでの議論内容を元に、その後もNETCONFプロトコルの詳細内容について議論され、今回の会議までに下記4つのドキュメントが提出されました。
- NETCONF Configuration Protocol
- BEEP Application Protocol Mapping for NETCONF
- NETCONF Over SOAP
- Using the NETCONF Configuration Protocol over Secure Shell(SSH)
今回の会議は、これらのドキュメントについて、それぞれ合意を得る事を目的として開催されました。
各ドキュメントの内容があまりにも膨大なため、会議も2日に分けて行われ、未決定項目についての決定や、ドキュメント中の問題点についての質疑応答など、さまざまな議論が行われ、概ね順調に合意が得られました。
結果、これらNETCONFプロトコルのLastCallを次のステップとして進めていくことになりました。
関連URI
- 58th IETF - Minneapolis, MN, USA
http://www.ietf.org/PASTMEETINGS/IETF-58b.html - IEPG
http://www.isc.org/iepg/ - CRISP WG
http://www.ietf.org/html.charters/crisp-charter.html - DNSEXT WG
http://www.ietf.org/html.charters/dnsext-charter.html - DNSOP WG
http://www.ietf.org/html.charters/dnsop-charter.html - ENUM WG
http://www.ietf.org/html.charters/enum-charter.html - NETCONF WG
http://www.ietf.org/html.charters/netconf-charter.html
本会議報告は、JPRSのメールマガジン「FROM JPRS」の増刊号として発行した情報に写真などを交えてWebページ化したものです。
「FROM JPRS」にご登録いただいた皆さまには、いち早く情報をお届けしております。ぜひご登録ください。
