Domain Name System(Service または Server)(DNS) RFC 1035 等
TCP/IP ネットワークのIP アドレスやドメイン名,ホスト名などの,ドメイン名に関連する情報を管理・検索する分敢型のデータベースシステム。
または,そのシステムが動いている DNS サーバーのこと。
RFC 1034,1035 など非常に多くの RFC でその拡張や補足説明がおこなわれている。
おもに,IP アドレスと,ドメイン名を相互変換するために使われる。
メールアドレスを正しい IP アドレスに変換する機能もある。
ドメイン名を IP アドレスに変換することを正引き foward reference,その逆を逆引き reverse reference という。
定義レコードには,A レコード,NS レコード,MX レコード,CNAME レコード,PTR レコードなどがある。
1983年6月2日,南カリフォルニア大学(USC)でジョン・ポステル氏とポール・モッカペトリス氏が初めてのテストに成功した。
インターネットが普及した現在では取るに足りないことだが,当時は画期的なコンセプトだった。
大元は世界に分散する13台のルートサーバーで,その下に代理をするコンピューター,さらにその代理と,樹枝状のシステムとなっている。
問い合わせは通常 DNS サーバーの UDP 53番ポートに対して行なわれるが,この際にクライアント側(キャッシュサーバー側)では,通常1024番以上の任意のポートが使用される。
つまり,DNS サーバーからの応答が,Slammer が狙った1434番ポートに返される状況も起こりうる。
2007年2月6日,DNS サーバのうちの重要な何台かに,トラフィックの急増が確認された。
米国太平洋標準時で6日の午前2時30分から,複数のルートサーバがトラフィックの異常な増加を確認。
特に集中して攻撃を受けたのが,米国防総省(DoD)が運用する『G』サーバと,ICANNが運用する『L』サーバだった。
2008年7月8日,Microsoft,Cisco Systems,Juniper Networks,Sun Microsystems などのベンダーがユーザーにパッチを提供した。
DNS の脆弱性が攻撃者によるサーバーの『汚染』を許し,トラフィックが任意の場所へリダイレクトされてしまう可能性がある。
DNS プロトコルには3件の脆弱性が存在した。
脆弱性の詳細を明らかにすることなく,まず数多くのベンダーが修正パッチを迅速にリリースできる体制作りが重視された。
調整の結果,まず7月8日に US-SERT から『DNS プロトコルの脆弱性が存在する』という情報が公開された。
それ以降,ベンダー各社が修正パッチを8月3日までにリリースできるようにするスケジュールとなった。
実際に修正パッチが公開されると,世界全体の約1億2000万台のサーバへ修正パッチが迅速に適用された。
2008年7月22日以降,複数の DNS ソフトウェアにおける DNS キャッシュポイズニングの脆弱性について警告されている。
2008年7月25日,Microsoft は『MS08-037』で Windows DNS の脆弱性に対処したと発表。
Berkeley Internet Name Domain(BIND)
Unbound オープンソース DNS
e.dns.jp
WIDE が運用する JP DNS サーバ。
2007年12月4日,WIDE プロジェクトと日本レジストリサービスは,JP DNS の信頼性向上を狙って,サンフランシスコとフランス・パリにサーバを追加するとともに,『IP Anycast』技術を導入するなどの増強策を実施したと発表。
サーバを海外拠点に追加し,JPRS が全体を管理することで,JP DNS の地理的な分散配置が強化されることになり,東京や大阪など日本国内のサーバ拠点で災害が同時に発生した場合でも,影響を受けない地域で JP DNS の運用継続が可能となるなど,JP DNS 全体の耐災害性が向上した。
DNS データベースのクリーンアップ
一部の ccTLD や RIR で最近行なわれている。
各々のレジストリに DNS サーバホストとして登録されているサーバの設定内容を定期的にチェックし,もし登録されている DNS サーバの設定が正しくない場合,該当するデータの登録者に各種手段(電子メール,電話,郵便など)で連絡をとることにより設定改善を図る。
連絡がつかなかったり,一定期間が経過した後も DNS サーバの設定に改善が見られなかった場合,DNS サーバホストの設定自体を消去するというもの。
DNS プロトコル
DNS サービスに使われるプロトコルで,1983年に Paul Mockapetris 氏と故 Jonathan Postel 氏が開発。
RFC 1034/1035 で整備され,URL を用いた Web へのアクセスやメールの送受信など,今やインターネットの利用には必要不可欠な要素となっている。
2004年11月9日 NISCC はこの脆弱性を報告,DoS 攻撃を受ける可能性が指摘した。
2008年7月22日,US-CERT や SANS Internet Storm Center は,脆弱性が見つかった問題で詳細な情報が手違いで流出したと発表。
それを基に作成したとみられる悪用コードがすでにインターネット上で入手可能になっている。
当初,IOActive のダン・カミンスキー氏によって8月の Blackhat カンファレンスで発表される予定だったが,同氏の情報公開の遅さに業を煮やした人物がこの脆弱性にかんする自らの見解を示しており,その情報を基に攻撃コードが作成されているとみられる。
Julien Desfossez と名乗る人物が Python で動作する攻撃コードを公開しており,『動作は遅いがしっかり機能する』とコメントしている。
システムにこの脆弱性が存在するベンダーは Cisco Systems,Debian GNU/Linux,FreeBSD,富士通,Hewlett-Packard,IBM,Internet Systems Consortium(ISC),Juniper Networks,Microsoft,Novell,Red Hat,Sun Microsystems,SUSE Linux,Ubuntu など。
DNS ポイズニング
悪意ある攻撃者が DNS サーバにリクエストを大量に送りつけ,偽の応答を返すようにするもの。
攻撃対象の DNS サーバの応答に依存するリクエストを発したユーザーを,偽のサイトに誘導できる。
1995年ごろから行われてきたが,深刻な問題にはなりにくいとされている。
2005年3月,シマンテック社のファイアーウォールに存在する既知の脆弱性を悪用して,イーベイ,Google,ウェザー・コムの一部ユーザーを,訪問者のコンピューターにスパイウェアのインストールを試みる3つのサイトへと,リダイレクトしようとした。
用いられた手法は DNS ワイルドカードと呼ばれるもので,この攻撃は単なるテストと見られている。
DNS キャッシュポイズニング,DNS キャッシュ汚染
DNS キャッシュサーバ(リゾルバ)が DNS サーバに名前解決を行う際,DNS サーバの応答より速く偽の DNS 情報をリゾルバに渡すことで,ユーザーをフィッシングサイトなどに誘導すること。
ユーザーが正規サイトのドメインを照会しても,攻撃者によってDNSサーバが汚染されていればユーザーが不正サイトにたどり着き,マルウェア感染や個人情報の盗難といったさまざまな危険に巻き込まれる恐れがある。
この脆弱性を突かれると,ホスト名は正しいのにまったく違うサイトへ誘導させることが可能になるため,ファーミングなどの危険性が高まる。
原因は,DNS プロトコル自身が持つ脆弱性によるが,中でも DNS パケットの中に含まれる識別 ID が16ビットしかないことも攻撃者にとって有利に働いている。
偽装した DNS パケットの中の ID をランダムに変化させながら渡すことで,リゾルバの問い合わせ頻度が高くなるようなケース,つまり,リソースレコードの TTL が30秒など極端に短い場合などでは,非常に短時間でキャッシュポイズニングに成功する。
根本的な解決策としては,リゾルバからの問い合わせに対する応答に,デジタル署名を施してデータの改ざんを検知可能にする DNSSEC(DNS Security Extensions)などが挙げられるが,応答パケットが大きくなったり,その管理の手間などから現実的には DNSSEC の採用はそう簡単ではない。
2009年1月14日,情報処理推進機構はこの脆弱性に関する対策資料を Web で公開。
DNS の役割や仕組み,DNS キャッシュ汚染を実現する手法や脅威を解説しているほか,DNS の問合せ動作や関連ツールの『whois』『nslookup』の使い方を説明。
DNS キャッシュ汚染対策の検査ツール『Cross-Pollination Check』や『DNS-OARC Randomness Test』の使用方法,BIND DNSサーバとWindows DNSサーバの適切な設定に関しても具体的な方法を紹介している。
2009年12月10日,情報処理推進機構(IPA)は DNS サーバにおけるキャッシュポイズニングの脆弱性へ早急に対応するよう,Web サイト管理者などに改めて呼び掛けた。
この脆弱性は,DNS キャッシュサーバが DNS サーバにドメインの名前解決を行う際,DNS サーバの応答より速く偽の DNS 情報を DNS キャッシュサーバに渡すことで,ユーザーを不正サイトなどに誘導できてしまうというもの。
2008年7月に明らかになり,Internet Systems Consortium(ISC)や IPA などが対策方法を公開している。
IPA によると,この脆弱性に対処していないとみられるサイトに関する届け出が多数寄せられているという。
DNS Security Extensions(DNSSEC)
電子署名を応用し,DNS の情報が改ざんされていないかどうかを検証する仕組み。
1994年から IETF で検討,1997年から開発されている DNS のセキュリティを向上させるための拡張仕様。
サーバとクライアントの間で交わされるメッセージが改ざんされていないことを保証するため,メッセージのハッシュ値を公開鍵暗号方式で暗号化し,メッセージと共に送る。
DNS サーバーから送られてくる IP アドレスとホスト名の対応情報の信頼性と正当性を保証するセキュリティ拡張機能で,DNS キャッシュポイズニング,DNS のなりすまし,不正な DNS サーバーによる攻撃を回避する技術。
Internet Systems Consortium (ISC) のオープンソース DNS サーバー『BIND』が実装している。
これに移行するには,DNS 管理者が管理する全ての DNS ゾーンに署名し,署名したデータを確認するようネームサーバーを設定する必要がある。
2009年11月,これを実装済みの DNS サーバーを攻撃する,新たな脆弱性が見つかった。
ISC は,セキュリティ勧告で『DNSSEC を有効にしているネームサーバーでは,再帰的なクライアント クエリを解決中に受け取った応答の追加セクションから,不適切なレコードをキャッシュに追加してしまう可能性がある。この挙動は,チェック無効 (CD) でのクライアント クエリ処理と,DNSSEC レコードの要求 (DO:DNSSEC OK) が同時になされる場合にのみ発生する』と述べている。
2011年現在,世界各国で DNSSEC への対応が進んでおり,DNS の根幹となるルートサーバでは,すでに2010年夏に DNSSEC への対応を完了している。
DNSSEC ジャパン
DNSSEC の導入・運用に関する課題の整理と検討を行い,参加者の技術力の向上,ノウハウの共有を促進するとともに,ツールの提供や普及のための技術解説などの対外活動も行う団体。
2009年11月24日設立を発表。
サイト:http://dnssec.jp
DNS ワイルドカード
一部誤って入力された電子メールアドレスを正しいアドレスに変換するため,DNS レコードで使用するのがいわゆるワイルドカード機能。
最近スパム業者がこれを悪用するようになり,現在ではフィッシング詐欺で使われている。
mail exchanger(MX)
DNS でドメインに対して設定できる項目,情報。
このドメイン宛のメールを配送する際の,送信先メールサーバー。
MTA は DNS を参照して宛先のドメインの MX 情報を取得,その後 MX として登録されているメールサーバーの MTA に対してメールを配送する。
SPFレコード
DNS レコードの一種で,メールの送信サーバの情報を記録したもの。
メールを受け取った SMTP サーバが問い合わせ,メールの情報と照らし合わせることで,本当に正しいの SMTP サーバから送信されたかが確認できるようになる。
Dynamic Domain Name System(Dynamic DNS) ダイナミック DNS,RFC 1995・1996
DNS データベースの内容に変更があったときにその変更を即座に通知したり,変更部分のデータだけを転送するなどの機能を持った DNS。
個人向けの ADSL や FTTH 接続サービスなどで動的に割り振られる非固定の IP アドレスと,特定のドメイン名を自動的に結びつける。
mail exchange resource record(MXRR) RFC974
DNS サーバーに設定された,メールサーバーを示す情報。
メールサーバーのホスト名を記録している。
Start of Authority Record(SOAR),SOA レコード
DNS の設定ファイルに定義する情報レコードの1つ。
これに,DNS のゾーンを定義するための名称,DNS の定義情報のバージョンを管理するためのシリアル番号,
名前解決の際にキャッシングに関する設定などを記述する。
DNS resolver
DNS サーバーにアクセスするクライアント。
2002年6月28日,JPCERT/CC は,このライブラリーの脆弱性が原因でバッファーオーバーフローをかけられる危険性があると警告。
NSD
オランダの NLnet Labs が開発している,オープンソースの DNS サーバ。
2009年5月,脆弱性があるとアップデート版を公開。
脆弱性は NSD で特定種類のパケットを処理する際に起きるワンバイトオーバーフロー問題が原因。
悪用されると,バッファオーバーフローを引き起こして DNS サーバがダウンしたり,サービス妨害(DoS)状態に陥ったりする可能性がある。
脆弱性が存在するのは NSD 2.0.0〜3.2.1。
NSD 3.2.2
2009年5月公開のバグ修正版。
戻る 英語『D』,最初のメニュー