DNSのセキュリティ拡張"DNSSEC"入門

DNS (Domain Name System)は、ドメイン名(www.nttpc.co.jp等)から対象のサーバーのIPアドレスを教えてくれるシステムです。Webページを見たり、メールをするために、無くてはならないものだということは皆さんご存知かと思います。
そのような重要なシステムであるのにも関わらず、DNSは通信のほとんどにUDP (User Datagram Protocol)を使っていたり、受け取った答えが正しいものかチェックしていなかったりと、大雑把な作りとなっています。それにはさまざまな背景があるのですが、そこを突いた攻撃や脆弱性が最近でも発見されています。

下に攻撃の一例を挙げます。

上記で述べたように、キャッシュDNSサーバー側で受け取った情報が正しいかどうかをチェックしていないため、攻撃者が不正な応答を紛れ込ませると、キャッシュDNSサーバーはその応答を正しい情報として扱い、ユーザーに本来とは異なった嘘のIPアドレス情報を返してしまう可能性があります。嘘のIPアドレスを返されたユーザーは、本来閲覧するはずであったWebページとは異なった別のWebページを閲覧してしまうことになります。 いつもの通販サイトを利用しているつもりが、偽者のサイトに誘導され、クレジットカードの情報が盗まれてしまう、などのフィッシング被害が考えられます。

そのようなDNSの脆い点を改善するための仕組みがDNSのセキュリティ拡張"DNSSEC (DNS Security Extensions)"です。

DNSSECの仕組みを一言で言うと『DNS応答が正しいサーバーから応答されたものであるか検証する仕組み』です。
ドメインを管理している権威DNSサーバーが問合せを受けた際、返す答えに「鍵(DNSKEY)」と「署名(RRSIG)」をつけて、正しい応答であることを主張します。それを受けたキャッシュDNSサーバーが、その「鍵」と「署名」のセットが正しい組み合わせであるかを検証し、応答が正しいものであるかを判断します。もし、攻撃者が嘘の情報を紛れ込ませたとしても「鍵」と「署名」の検証に失敗するため、キャッシュDNSサーバーで不正な応答であると判断し、名前解決に失敗したとユーザーに返答します。

この仕組みだと「鍵」と「署名」の組み合わせのみが合っているだけで、正しい応答であると判断してしまうため、「鍵」と「署名」のセットで偽装すれば、その応答を正しいものとして扱ってしまう可能性があります。それを防ぐために用意されているものが「信頼の連鎖」です。
DNSは、ドメイン名の巨大な分散データベースです。いくつもの権威DNSサーバーがそれぞれのデータを管理し、キャッシュDNSサーバーが順々に辿って目的のドメインの名前解決を行います。通常、www.nttpc.co.jpの名前解決をする場合は、以下の順番で上位のDNSから問い合わせていきます。

• STEP1

  「.」(ルート)の権威DNSに「.jp」の権威DNSを教えてもらう

• STEP2

  「.jp」の権威DNSに「.co.jp」の権威DNSを教えてもらう

• STEP3

  「.co.jp」の権威DNSに「nttpc.co.jp」の権威DNSを教えてもらう

• STEP4

  「nttpc.co.jp」の権威DNSに「www.nttpc.co.jp」のIPアドレスを教えてもらう

まとめると『上位のDNSが、次のDNSが正しいことを証明している』ということになります。その証明が連鎖していくことで最終的に「www.nttpc.co.jp」の応答が正しいことが分かるのです。 先ほどの、「www.nttpc.co.jp」の名前解決の例に、この「信頼の連鎖」の動きを加えると以下のようになります。

ここまでがインターネットユーザーの視点から見た簡単な説明です。

一方で、DNSサーバーの管理者、特に権威DNSサーバーでドメインを管理している人には大変な重圧がかかります。 DNSSECはセキュリティを向上させる仕組みなので、「鍵」が外部に漏えいしたり、悪意ある人物に推測されてしまう点に注意が必要です。すなわち「鍵」を適切な形で保管を行い、定期的に交換しなくてはなりません。身近なところで言うとSSLの証明書等と同じですね。
これだけだと大した負荷ではないように感じられますが、DNSとなると簡単にいきません。DNSにはキャッシュ機能とTTL (Time To Live)という値が存在します。一般的にキャッシュDNSサーバーは、あるドメイン名を解決したあと、そのドメインのTTLの時間だけ自身のメモリ内に名前解決した情報を保存 (キャッシュ)します。保存期間中に同じドメイン名で名前解決の要求があれば、キャッシュされた情報をもとに応答を返します。DNSSECの「鍵」や「署名」も一般のレコードと同様に扱われるため、TTL時間分だけキャッシュされます。例えば、「署名」だけがキャッシュされた状態で、新しい「鍵」を受け取ってしまった場合、「鍵」と「署名」が不整合を起こし、キャッシュDNSサーバー側で不正な応答と間違われてしまう、すなわち、そのドメインの名前解決に失敗してしまいます。

ドメインの名前解決が出来ないということは、インターネットの世界から孤立してしまうことと同じです。会社のサービスサイトがある日突然見えなくなったら、大きな損害ですよね。
以上から、キャッシュのTTLが切れる時間を考えながら「鍵」の交換をしなければいけないのです。そのTTLが「1日」など、大きな値であったりすると、鍵の交換作業は、数日がかりの作業になってしまいます。

その他、ネットワーク的なハードルもあります。
DNSSECを有効にするとDNSの応答に「鍵」や「署名」を追加して返すことになるので、応答のパケットが大きくなります。通常DNSはUDPで通信するため、UDPパケットの最大値512Byteを超えると、TCP (Transmission Control Protocol)にフォールバックするか、EDNS0という機能でUDPパケットを分割して送信します。
そんな時に、途中のルーターでTCPの53番ポートをルーターやファイアウォールでフィルターしていたら...、分割されたUDPパケットを認識できない古いルーターやDNSサーバーだったら...、どうなるかわかりますよね。応答が返ってきません。上記と同じく孤立状態です。

上記で挙げた例はDNSSECを導入するうえでハードルとなるものの、代表的なものです。ドメインを管理する権威DNSサーバーも、応答を受け取るキャッシュDNSサーバーもさまざまな問題に悩まされながら運用していく必要があるのです。

とはいえ、我々のようなISP事業者はこのような問題を避けて通ることはできません。DNSSECに限らず、お客さまが安心して利用していただける環境を提供するため、日々、品質向上に努めていきたいと思います。