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


ドメイン名関連会議報告

2013年

第88回IETF Meeting報告(後編)

~weirds WG/インターネットガバナンス関連、IEPG Meetingにおける話題~

今回のFROM JPRS増刊号では前回に引き続き、第88回IETF Meeting(以下、IETF 88)における議論の中から、weirds WGとInternet Governance Update BOFの状況、IETFに併設される形で開催されたIEPG Meetingにおける話題についてお伝えします。

会場となったハイアット・リージェンシー・バンクーバー

会場となったハイアット・リージェンシー・バンクーバー

weirds WGにおける話題

weirdsはWeb Extensible Internet Registration Data Serviceに由来しており、現在のWHOISを置き換えるプロトコルであるRDAP(*1)の開発、各RDAP実装の相互接続性の確認などを目的としています。

(*1)
RDAPの詳細についてはFROM JPRSバックナンバー「第86回IETF Meeting報告(後編)~レジストリ関連/全体会議/Networking History BOFにおける話題から~」をご参照ください。

URI文字列の仕様

weirds WGで検討を進めていたURI文字列の仕様(draft-ietf-weirds-rdap-query)が、現在appsawg(*2)で標準化を進めているURI Pathの仕様(draft-ietf-appsawg-uri-get-off-my-lawn)に準拠していないという指摘があり、問題を解決するための議論が進められました。

(*2)
appsawgは「Applications Area Working Group」に由来しており、アプリケーションエリア全般の話題を総合的に取り扱うWGです。

議論の結果、この問題については今後W3C(*3)にも相談の上、URI文字列の仕様をURI Pathの仕様に準拠した形に更新する方向で検討を進めることとなりました。この方針に従い、会議終了後にdraft-ietf-weirds-rdap-queryが07から08に更新されています。

(*3)
World Wide Web Consortiumの略称。World Wide Webで利用される一連の技術の標準化を進めることを目的として、1994年に設立された非営利団体です。

検索処理と国際化

RDAPの検索処理と国際化ドメイン名に関する、部分一致(Partial Matching)と正規化(Normalization)の仕様について議論されました(draft-hollenbeck-weirds-rdap-search)。
会場からは、検索の仕様についてはもっと詳細に文書化した方が良い、レジストリごとに異体字(variant)の仕様やポリシーが存在する、といったコメントがあり、今後も継続して検討を進めることになりました。

問い合わせ名からRDAPサーバーへの到達方法

前回のIETF 87から継続して議論されている問い合わせ名からRDAPサーバーへの到達方法について、これまでに提案された二つの方式(*4)、

1)DNSによる検索(draft-blanchet-weirds-bootstrap)
2)IANAレジストリ方式(draft-blanchet-weirds-bootstrap-ianaregistries)

に加え、SRVまたはNAPTRレコードを用いることでIANAへの登録を不要とする新たな方式(draft-blanchet-weirds-bootstrap-autonomous)が提案されました。

(*4)
これらの方式の詳細についてはFROM JPRSバックナンバー「第87回IETF Meeting報告(後編)~DNSの運用とセキュリティにつながる話題、レジストリ関連WGにおける話題~」をご参照ください。

会議では、三つの方式についての比較検討の後、WGとして方法を統一するか、また統一する場合、どの方法を採用するのかについて議論されましたが結論には至らず、それぞれの方式の技術的課題についてメーリングリストで議論を進めることになりました。

相互接続試験

最後に、WGで進めている相互接続試験の状況が報告されました。いくつかの実装上の問題が発見されたことと、仕様の細部についてのいくつかの要確認事項が共有された後、次回のIETF 89でも試験を再度実施し、相互接続性の改良を進めていくことが確認されました。

Internet Governance Update BOF

今回のIETF 88ではIAB(*5)が主宰する「Internet Governance Update BOF」というセッションが開催されました。このセッションは前々回のIETF 86で開催された「IAB WCIT Information session」と同様、インターネットガバナンスに関する状況をIETF参加者と共有・議論することを目的としています。

(*5)
Internet Architecture Boardの略称。
IETF及びIESGによる標準化プロセスを監督し、RFCの発行・IANAの資源割り当てについて責任を負います。また、IETF議長及びIESGエリアディレクターの承認、ISOCへの技術的アドバイスなど、インターネット全体にかかわる重要な役割を担っています。

今回のセッションでは、次世代WHOISに関する話題が取り上げられました。
ICANNにおける「A Next Generation Registration Directory Service(RDS)」の検討状況が共有され、IETFにおけるweirds WGの活動状況が紹介されました。

その後、IGF(*6)における検討状況が共有され、マルチステークホルダーモデルの中でIETFがどのような役割を果たしていくべきかについて、参加者の間で議論されました。関連する議論は今後、Internetgovtechメーリングリスト(関連URIを参照)において継続される予定となっています。

(*6)
Internet Governance Forumの略称。
インターネットガバナンスについて話し合う、国際連合が管轄するフォーラムです。2005年11月に開催された「World Summit on the Information Society(世界情報社会サミット:WSIS)」で採択された「チュニスアジェンダ」により開催が決定され、2006年から年に1回の割合で開催されています。

IEPG Meetingにおける話題

IEPGは、IETF Meetingに先立って日曜日午前に開催される略式の会合で、インターネットの運用に関連するさまざまなテーマを取り扱っています。

ここでは、今回のIEPG Meetingで報告・議論された話題のうち、FROM JPRSが特に注目したものについてお伝えします。

Google Public DNSの利用状況調査

特定のURI(ドメイン名)を持つ広告へのアクセスを分析することで各クライアントとキャッシュDNSサーバーの問い合わせを関連付け、それによりGoogle Public DNSの利用状況を調査した結果が、APNICのジェフ・ヒューストン (Geoff Huston)氏から発表されました。

発表では、2013年5月時点でその広告をアクセスしたIPアドレス数のうち、

・Google Public DNSのみを使っているものが全体の5.3%
・Google Public DNSと他のキャッシュDNSサーバーを併用しているものが全体の1.9%

であったことが報告されました。

また、2013年6月に元CIA職員のエドワード・スノーデン氏がアメリカ国家安全保障局(NSA)による極秘の監視計画「PRISM」を暴露した事件(以下、スノーデン事件)以後、

・Google Public DNSのみを使っているものが全体の4%台に減少
・Google Public DNSと他のキャッシュDNSサーバーを併用しているものは、逆に全体の2%台に増加

という変化があったことが報告されました。

また、調査により判明したGoogle Public DNSの国別の利用率と、スノーデン事件以降のその変化の状況も併せて報告されました。

Unboundを用いたデータプリフェッチ(HAMMER(*7))の実装試験

前回(IETF 87)のdnsop WGで発表された、キャッシュDNSサーバーの実装方式を工夫することで応答時間やキャッシュヒット率を向上させる提案(HAMMER)を、小変更を加えた上でUnboundに試験実装した結果が、NLnet LabsでUnboundの開発を担当するワウター・ワインハーツ(Wouter C.A. Wijngaards)氏から発表されました。

(*7)
draft-wkumari-dnsop-hammer。HAMMERの詳細についてはFROM JPRSバックナンバー「第87回IETF Meeting 報告(前編)~DNS 関連WGにおける話題~」をご参照ください。

HAMMERからの変更点は、

1)プリフェッチ実行の条件
HAMMER:クライアントからDNS問い合わせを受けた時点で、そのレコードのキャッシュTTLが2秒以下に減少していた場合
Unbound:クライアントからDNS問い合わせを受けた時点で、そのレコードのキャッシュTTLがオリジナルTTLの10%以下に減少していた場合

2)プリフェッチ実行の除外条件
HAMMER:オリジナルTTLが6秒以下であった場合
Unbound:オリジナルTTLが9秒以下であった場合

の2点とのことで、同氏はその理由として、権威DNSサーバーやUnbound自身の負荷上昇の防止を挙げています。

同氏からは、実環境を用いた試験結果として、

・プリフェッチによる問い合わせは、権威DNSサーバーへの問い合わせ総数の1.5%であった
・プリフェッチの有無による権威DNSサーバーへの問い合わせ状況の変化は、ごくわずかであった
・プリフェッチを有効にすることで、問い合わせから応答までの時間(発表資料中の「Query Resolving Time」)が短いものが増加した

ことが発表されました。

また、分析においてTTLで指定された時間内に到達した問い合わせ数(N)とTTLの比率(N/TTL)が0.1よりも大きいものを「人気のある名前(Popular name)」と定義したこと、プリフェッチは本来のターゲットである「人気のある名前」に加え、「人気はないが大きなTTLが設定されている名前」に対しても有効であると考えられることが示されました。

DNSにおける各種セキュリティ機能の検討

DNSに実装されている各種セキュリティ機能についてコストの面から検討した結果が、Farsight Securityのポール・ビクシー(Paul Vixie)氏から発表されました。

発表では、DNSに対する脅威とそれに対する対策例が提示され、特に最近提案されているTCPの常用、DNS RRLにおけるslip(*8)の設定変更(*9)、ANYレコードに対する対策の三つについて、コストの面から検討した結果が示されました。

(*8)
DNS RRLでは応答制限時にも名前解決ができるように、制限発動時の応答の一部について、slipと呼ばれる動作をします。slipでは応答を廃棄する代わりに切り詰め(TC)ビットをセットされた応答を返すことで、送信元にTCPによる再送を促します。
(*9)
2013年9月に、DNS RRLの悪用によりキャッシュポイズニング攻撃のリスクが高まることが指摘され、その対策としてslipの設定変更(応答制限時にすべての応答をslipとする)が提案されました(関連URIを参照)。

また、同氏からは、

・DNSの(高い)パフォーマンスは、プロトコルがステートレスであることに依存している
・DoS攻撃やキャッシュポイズニング攻撃の対策はステートを持つことであり、パフォーマンスを低下させる
・ステートの持ち方には重いもの(例:TCPの常用)、中程度のもの(例:DNS Cookie(*10))、軽いもの(例:DNS RRL)がある

点が示され、セキュリティは経済(economics)であり、過去から現在、未来になるに従い、徐々に高コストとなっていくと結論づけられました。

(*10)
サーバーからのDNS応答にHTTPと同様の「クッキー」を加え、以降のDNS問い合わせ(セッション)においてそれを利用することにより、DNS応答の偽造を防止する提案です(draft-eastlake-dnsext-cookies)。

次回のIETF Meeting

次回の第89回IETF Meeting(IETF 89)は2014年3月2日から7日にかけ、英国のロンドンで開催される予定です。

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