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


ドメイン名関連会議報告

2011年

第82回IETF Meeting報告

~ドメイン名/DNS関連の話題を中心に~

IETF全般の状況

3年ぶりに参加者が1,000人を下回る

今回のIETF82の参加者は948人と前回(IETF81)の1,127人から大きく減少し、リーマンショックによる世界的な経済危機の中開催されたIETF73以来、3年ぶりに1,000人を下回りました(図1)。1996年以降に開催されたIETF Meetingで参加者が1,000人を下回ったのはこの2回のみであり、原因の一つとして2010年の欧州債務危機に端を発する、世界的な景気低迷が挙げられています。

図1:IETF Meeting参加者数の推移

図1:IETF Meeting参加者数の推移

また、今回のIETF82では最近アジア太平洋地域で開催されたIETF76(広島:参加者1,152人)、IETF79(北京:参加者1,207人)と比べ開催地からの参加人数が少なく(*1)、そのことも参加者減少の原因の一つとして挙げられています。

(*1)IETF76とIETF79では開催地から全体の30%程度の参加がありましたが、今回のIETF82では台湾からの参加は全体の6%程度に留まっています。

3度目の日本開催?

年~2013年のIETF Meetingは欧米地域での開催が既に予定されており、アジア太平洋地域における次の開催予定は2014年以降となっています。今回、時期未定ながら次回のアジア太平洋地域の候補地として、日本での開催を計画している旨が発表されました。日本ではこれまでに2002年のIETF54(横浜)、2009年のIETF76(広島)の2度にわたり、IETF Meetingが開催されています。もし計画通り開催されれば、アジア太平洋地域におけるIETFの最多開催国となります。

dane WGの状況

daneは「DNS-based Authentication of Named Entities」に由来する、DNSを用いたデジタル証明書(以下、証明書)の安全な配送や、証明書とサーバーの関連付けの正しさを検証できるようにするための標準化作業を進めているWGです。

インターネットでは通信相手が正当なサーバーであることを検証する際、第三者となる証明機関(認証局)が発行したサーバー証明書を使用します。daneではこれをDNSの委任関係を用いて検証することにより、認証局の介在なしにサーバーの正当性を検証することが可能になります。

IETF82では、これまでのIETF Meetingで議論された各項目についての議論が継続され、実運用可能なプロトコルを目指した作業が進められました。また、今後の計画として、daneの運用ドキュメントの充実などが提案されました。

daneとDNSSECの関係

daneに相当するアイディア、つまり、DNSを証明書のインフラとして活用しようという考え方そのものは以前からありました。しかし、その実現のためには通信路への攻撃に対する耐性が必要不可欠であり、そのための技術であるDNSSECが実環境に導入されていなかったことから、実現のための障壁となっていました。

その後、2010年7月のルートゾーンへのDNSSECの導入を皮切りに、2011年に「.jp」や「.com」、「.net」などの主要なTLDにおいてDNSSECの正式運用が相次いで開始され、インターネットにおいてdaneを実際に導入・運用するための前提条件が整いました。

このような背景から、daneはDNSSEC普及のためのキラーアプリケーションの一つとなる可能性があります。今後のdane WGの動向に要注目です。

appsawgの状況

appsawgは「Applications Area Working Group」に由来しており、アプリケーションエリア全般の話題について総合的に取り扱うためのWGです。最近のIETFにおける状況の変化により、従来個別に存在していたWebや電子メール関連のWGにおいて議論されていた話題は、最近ではappsawgでまとめて議論されるようになってきています。

今回のappsawgではドメイン名/DNSに関係する話題として、ICANNで進められている国際化トップレベルドメイン(IDN TLD)における異体字の問題点を明らかにし、その解決を図るためのプロジェクト(Variant Issues Project)の概要が紹介されました。プロジェクトではアラビア文字、漢字、キリル文字、デーバナーガリー(*2)、ギリシャ文字、ラテン文字の6種類をターゲットとしており、各文字ごとにエキスパートが参加し、問題点の洗い出しを行っています。

(*2)デーバナーガリー(Devanagari):北インド諸語であるヒンディー語、マラーティー語、ネパール語などで筆記・印刷に用いられている文字です。特徴として、各文字がシローレーカー(頭線)と呼ばれる横線でつながっている点が挙げられます。

会議では、プロジェクトからの報告を受けてIETFが検討すべき内容として、IDN TLDを利用する各アプリケーションがどのように動作・機能すべきかを検討する必要がある、という指摘がありました。

また、今回のappsawgでは電子メールにおける送信元認証(Sender Authentication)の技術として広く普及しているSPF(Sender Policy Framework)を、現在の実験(Experimental)規格から標準規格に更新するためのWGを作成しようという提案がありました。その場ではWG作成に関する合意には至りませんでしたが、今後WGのメーリングリストで議論を継続することとなりました。

weirds BOFの状況

weirdsは「WHOIS-based Extensible Internet Registration Data Service」に由来しており、Webサービスを用いた次世代のWHOISについて議論することを目的としています。weirdsは前回のIETF81ではbar BOF(*3)として開催されましたが、今回は正式なBOFとして開催されました。

(*3)IETFで開催されるBOF(Birds of a Feather)には、担当エリアディレクターの事前承認を必須とし、将来のWG設立を目指し本会議の一部として公式に開催される「BOF」と、早朝・昼食時・終了後など、本会議の時間外に非公式の形で開催される「bar BOF」の2種類があります。

今回のweirdsでは目的を、国際化の完了、計算機で処理しやすい(Machine-friendly)データモデルと表現形式の標準化、それぞれのサービスレベルの区分けの三つとすることが説明されました。

その後、ARIN、RIPE NCC、ICANN、LACNICにおけるweirdsの実装状況と得られた知見が発表されました。そのうちRIPE NCCの発表において「UTF-8をフルサポートしているのでシステムは国際化されている」という内容があり、会場からはUTF-8サポートだけをもって国際化されたというのは不十分であるという指摘がありました。

その後、WGのチャーター案としてweirdsをRIRなどのアドレスレジストリに限定するか、TLDなどのドメイン名レジストリも対象とするかについて議論されました。その場では明確な合意に至りませんでしたが、会場の雰囲気として、まずはアドレスレジストリに限定した形で当面の問題解決を図ろう、という空気が支配的でした。

eai WGの状況

eaiは「Email Address Internationalization」に由来しており、電子メールアドレスを国際化するための各プロトコルの標準化を行っています。

eaiでは現在の実験規格から標準規格への更新のための作業を継続しており、SMTP、電子メールヘッダフォーマット、DSN(*4)の拡張については、現在の提案がIESGによって会議終了後の11月22日に承認されました。また、POP(*5)拡張については作業をほぼ完了、IMAP(*6)拡張については細かい部分の議論をメーリングリストで継続し、近日中に仕様をまとめる予定となっています。

また、POP/IMAPにおけるEAIをサポートしていない場合のダウングレードについては若干の改良点が合意され、いくつかの懸念点については関係者とエリアディレクター、WG議長(チェア)による集中的な議論の後、改善点を提示することとなりました。

(*4)DSN:Delivery Status Notification電子メールの配送状況を発信者に通知するためのプロトコルとして、RFC 3464で定義されています。
(*5)POP:Post Office Protocolユーザーが自分の電子メールをメールサーバーから取り出す時に使用する受信用プロトコルとして、RFC 1939で定義されています。
(*6)IMAP:Internet Message Access Protocolユーザーがメールサーバー上の電子メールを操作するためのプロトコルとして、RFC 3501で定義されています。IMAPではPOPと異なり、電子メールをメールサーバー上に保存したまま管理することを想定しています。

eaiが標準化されることにより、電子メールアドレスに日本語を含むさまざまな言語が使用できるようになります。従来のeaiは実験規格でしたが、現在進められている標準規格への更新が完了することにより、今後必要となるMTA(*7)、MUA(*8)、MSA(*9)、MDA(*10)のeaiへの対応を進めるための準備が整うことになります。

(*7)MTA:Mail Transfer Agent(メール転送エージェント)メールサーバーにおいて宛先別の振り分け、メール配送エージェント(MDA)への振り分けなど、メール転送に関する機能を担当します。代表的なMTAの実装にはsendmail、Postfix、qmail、Eximなどがあります。
(*8)MUA:Mail User Agent(メールユーザーエージェント)電子メールの読み書きや管理をするためのアプリケーションソフトウェアで、メールソフトとも呼ばれます。従来からさまざまなMUAが開発・利用されており、最近ではWebブラウザーで利用するWebメールが広く普及しています。
(*9)MSA:Mail Submission Agent(メール投稿エージェント)メールサーバーにおいてMUAから発信されるメールの受け取りを担当します。spamメールなどの不正利用を防止するため、MUAからの受け取りに特化した新たなエージェントとして提案されました。MSAはSMTP認証などの機能を備え、不完全なメッセージの修正や不正利用の防止などを担当します。
(*10)MDA:Mail Delivery Agent(メール配送エージェント)メールサーバーにおいて、MTAにより振り分けられた電子メールを受信者に配送する機能を担当します。

次回のIETFはパリで開催、会議参加者数の推移に注目を

次回の第83回IETF Meeting(IETF83)は2012年3月25日から30日にかけてフランスのパリで開催されます。 冒頭でも述べたように、IETF82の参加者数は前回のIETF81から大きく減少しました。もし参加者が1,000人を切る状況が今後も長期にわたって続いた場合、会議参加費の更なる値上げ(*11)や会期の短縮、これまで続けてきた開発途上国の参加者の支援(旅費・宿泊費の負担)の削減などの緊急対策を取る必要があるともいわれています。
(*11)2009年に会議参加者の減少に伴う会議参加費の値上げ(約6%値上げし675米ドルとする)が実施されています。

しかし、このような性急な経費削減は、IETFの活動そのものにも影響を与えかねません。またIETFはインターネット技術の標準化という重要な役割を担っており、特定のスポンサー企業や政府などからの安易な活動資金の調達は、活動の中立性や自律性などを考慮した場合、好ましいことではありません。そのため、IETFが今後も健全な運営を継続していけるかどうかは、次回を含む今後の会議参加者数の推移にかかっているともいえるでしょう。

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