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

ドメイン名関連会議報告

2012年

ICANNトロント会合における技術トピックス

～DNSSECの導入状況とICANNにおける技術啓発活動を中心に～

2012/12/06

ccTLDやgTLDの関係者が数多く集まるICANN Meetingは以前から、ドメイン名管理のポリシー／ガバナンスに関する重要な情報交換や議論の場となってきました。それに加え、ここ数年はDNSやDNSSECに関する技術的内容の情報交換や議論においても、ICANN Meetingが重要な役割を果たすようになってきています。

また、ICANN Meetingには世界各国からさまざまな立場の関係者が参加しますが、それらの参加者は必ずしもDNSやDNSSECの技術者や専門家ではありません。そのような状況を受け、最近のICANN Meetingでは会議の参加者全体を対象とした技術啓発活動、特に、初心者・非技術者向けにDNSSECの概要を解説することを目的としたセッションが毎回開催されています。

今回のFROM JPRSでは2012年10月にカナダのトロントで開催された第45回ICANN Meeting（以下、ICANN45）において、技術情報の交換・議論の場として開催されたDNSSECワークショップ、ICANN40以来のDNS-OARCとの共同開催となったccNSO Tech Day、初心者・非技術者向けの技術啓発を目的に開催された「DNSSEC for Everybody - A Beginner's Guide」セッションの内容についてお伝えします。

DNSSECワークショップにおける話題

今回のDNSSECワークショップでは、主要なTLDやISPなどにおけるDNSSECの導入状況が発表されました。その中から北米地域のISPにおける状況と、ヨーロッパ地域のccTLDにおける状況について報告します。

北米地域のISPにおけるDNSSEC導入状況

北米地域におけるDNSSECの導入事例として、米国最大のISPであるComcastとカナダの大手ISPであるVideotronの状況が、それぞれの担当者から発表されました。なお、Comcastでは2012年1月にDNSSECの導入を完了しており、ユーザーに標準提供しているキャッシュDNSサーバーでDNSSEC検証が有効になっています。

▽外部のDNSSEC運用ミスでもISPに問い合わせ、迅速な情報提供で対応

Comcastの担当者からは、同社において問題になった点としてDNSSECでは外部の権威DNSサーバーでDNSSECの運用ミスがあった場合、そのサーバーが管理するドメイン名の名前解決ができなくなるが、ユーザーはその場合も（運用ミスをしていない）同社のカスタマーサポート窓口に問い合わせること、それに対応するため同社では「Comcast DNS（関連URIを参照）」というDNS技術情報を速報するページを開設し、DNSSECエラーがどのドメイン名で発生しているかの情報を同社の顧客にほぼリアルタイムで提供していることが発表されました。

また、Videotronの担当者からは、現時点ではDNSSEC対応のキャッシュDNSサーバーをユーザーに標準提供していないが、2014年を目標にDNSSECの正式導入に向けた準備を進めているという発表がありました。

ヨーロッパ地域のccTLDにおけるDNSSEC導入状況

ヨーロッパ地域のccTLDでは、以前からDNSSECの導入が積極的に進められてきました。最近では.nl（オランダ）、.cz（チェコ）、.se（スウェーデン）の三つのccTLDにおける普及が顕著で、特に.nlではDNSSECに対応したドメイン名が130万件を超え、世界最多となっています

前回のFROM JPRS増刊号「ICANNトロント会合報告」でも報告したように、これらのccTLDではレジストラに対するインセンティブの設定やウェビナー （Webinar: インターネット上で行われるセミナー）の開催など、DNSSECの普及促進を目的としたさまざまな施策が実施されています。

▽DNS／DNSSEC運用自動化ツール「AtomiaDNS」

最近、これらのccTLDの現場におけるDNS／DNSSECの運用自動化ツールとしてAtomiaDNSというソフトウェアが急速に普及し始めています。 AtomiaDNSはオープンソースで開発されており、MySQLによるゾーンデータの保持を標準サポートしているPowerDNSを権威DNSサーバーに採用することで、LAMP(*1)を用いたDNSSEC対応／自動化を可能にしています。また、Web画面による管理やSOAP（*2）によるAPIを標準装備しているなど、既存のWebアプリケーションとの親和性が高くなっています。

(*1)
OSのLinux、WebサーバーのApache、データベースのMySQL、スクリプト言語のPerl、PHP、Pythonを総称した名称で、さまざまなWebサービスがこの構成により構築されています。
(*2)
他のコンピューター上のデータやサービスをネットワーク経由で呼び出すためのプロトコルです。通信にはHTTP、メッセージの表現形式にはXMLが採用され、複数のWebサービスを連携させる場合などに使われます。

「DNSSECクイズ」

前回のプラハで開催されたICANN44に引き続き、Nominet UKのロイ・アレンズ（Roy Arends）氏から「The Great DNSSEC Quiz」と題した発表がありました。アレンズ氏はIETFやDNS-OARCの場で長年にわたって活動しているDNS技術者／研究者で、現在のDNSSECの標準仕様であるRFC 4033～4035や、DNSSECの不在証明に使用するNSEC3の標準仕様であるRFC 5155など、DNS／DNSSEC関連の重要なRFCの共著者でもあります

今回のDNSSECワークショップではこの発表が全体スケジュールのほぼ真ん中に割り当てられ、技術セッションに特有の難しい話が続いた後、疲れた頭をほぐしてリラックスするための時間となっているようでした。問題の難易度も「1024ビットのRSA鍵のRDATAの長さはいくつ」といったマニアックなものも出題された前回に比べ、やや易しくなっていたようです。

なお、前回のICANN44で出題されたクイズの問題のスライドが公開されています（関連URIを参照：今回のクイズのスライドは残念ながら公開されていないようです）。あなたは最後の問題の写真の二人が誰かわかりますか？

「DNSSECクイズ」

この二人は誰？
（答え：ビント・サーフ氏（左）とスティーブ・クロッカー氏（右））

ccNSO Tech Dayにおける話題

今回のccNSO Tech Dayは、ICANN40以来2度目となるDNS-OARCワークショップとの共同開催となりました（本稿では以降「共同ワークショップ」と記述します）。共同ワークショップの開催に至った背景の一つとして、ccNSO／DNS-OARCの双方にとってメリットがあることが挙げられます。その詳細についてはFROM JPRSバックナンバー「ccTLD向けDNS運用技術／ソリューション展開の動向と今後の展望～ICANN ccNSO／DNS-OARC共同ワークショップにおける話題から～」を併せてご参照ください。

共同ワークショップでは、DNS／DNSSECの運用技術に関する最新トピックスやさまざまな取り組みが発表されました。ここではその中から、ISCのポール・ビクシー氏により発表されたDNS RRL（Response Rate Limiting）の背景と概要について報告します。

DNS RRLの背景と概要

▽データの増幅はDNSの本質的特性～DNSSECなどの普及により増幅率が拡大

DNSではその仕様上、応答パケットの大きさが対応する問い合わせパケットのそれよりも必ず大きくなります。かつ、主な通信プロトコルとして送信元IPアドレスの偽装が比較的容易なUDPが使われていることから、DNSサーバーがDoS攻撃における攻撃用データの増幅器、すなわちDNS Amp攻撃の踏み台として悪用されやすいという本質的な特性を備えています。

かつ、最近ではDNSSECやSPF／DKIMなどの普及によりDNS応答のサイズが増加する方向にあります。これはすなわち、データの増幅率が拡大していることを意味しています。

DNS Amp攻撃の踏み台となるリスクを軽減するための有力な手段として、キャッシュDNSサーバーにおけるアクセスコントロールの適用が以前から推奨されてきました。しかし、権威DNSサーバーではその特性上任意のIPアドレスからの問い合わせに応答しなければならず、一般的なアクセスコントロールの実施は困難です。

DNS RRLはこの問題を解決するための手段の一つとして開発されました。

通常、権威DNSサーバーに問い合わせを送信するのはキャッシュDNSサーバーのみです。キャッシュDNSサーバーはキャッシュ機能を備えているため、通信エラーやDNSパケットの切り詰めによるTCPフォールバックが発生した場合を除き、同一IPアドレスから同内容の問い合わせが短時間のうちに連続して到達することはありません。

DNS RRLではこの特性を利用し、DNS Amp攻撃が疑われる連続的な問い合わせに対する単位時間あたりの応答レートを制限することにより、権威DNSサーバーがDNS Amp攻撃の踏み台として使われることを防ぎます。

現在、DNS RRLはBIND 9に対するパッチの形で提供・公開されています（関連URIを参照）。ビクシー氏はBIND 9以外でのDNS RRLの実装を歓迎するとのことで、メーリングリストを利用したオープンな議論の場も提供しています。

なお、同氏によるとDNS RRLはDNSプロトコルそのものを拡張するものではないことから、IETFにおける標準化は現時点では計画していないとのことでした。

初心者向けガイド「みんなのためのDNSSEC」

ICANN45会期中の10月15日に「DNSSEC for Everybody - A Beginner's Guide」と題した、DNSSECを初心者向けに解説したセッションが開催されました。本セッションは技術啓発活動の一環として、ここ数回のICANN Meetingにおいて毎回開催されています。

セッションでは最初に、原始人をモチーフにしたDNSSECの概要と目的を説明した漫画が紹介されます。狼煙（のろし）による通信を妨害するいたずら好きの男の名前がカミンスキー（Kaminsky）（*3）、通信を妨害された原始人に知恵を授ける村の賢者の名前がディフィー（Diffie）（*4）というユーモアに富んだ作りになっており、その後のDNSとDNSSECの動作の解説では発表者が寸劇を交えて説明するなど、DNSSECの導入目的と動作イメージを初心者・非技術者にわかりやすく伝えることに重点が置かれた構成となっています。

発表資料が公開されていますので（関連URIを参照）、興味を持たれた方はぜひご覧になってみてはいかがでしょうか。

通信を妨害する男：カミンスキー

通信を妨害する男：カミンスキー

(*3)
2008年にキャッシュポイズニングの有力な手法である「カミンスキー型攻撃手法」を発表したダン・カミンスキー氏に由来しています。
(*4)
DNSSECで用いられている公開鍵暗号の研究者・先駆者であるホイットフィールド・ディフィー（Whitfield Diffie）氏に由来しています。

初技術情報交換・議論の場ともなりつつあるICANN Meeting

このように、ICANN Meetingはインターネット全体を対象としたポリシー／ガバナンスに関する調整の場という従来からの役割に加え、ドメイン名やDNS／DNSSECの運用に関する技術情報の交換や議論の場ともなりつつあります。

新gTLDの導入やDNSSECの普及促進などを円滑に進めるには、それらを支えるDNSの安定運用が必要不可欠です。国や地域単位のNOGやRIPE、APNIC、LACNICなどの地域コミュニティに加え、世界各国から関係者が集まるICANNの場においてもこうした技術情報の交換や議論が試みられ始めていることは、注目すべき状況であると言えるでしょう。

関連URI

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