DNSSECの複雑さと考慮点

DNSはゾーンと呼ばれる単位に分割されます。ゾーンは通常、ドメイン名で始まり、サブドメインに関連するすべてのレコードを含んでいます。各ゾーンは1人の管理者によって管理されます。例えば、cloudflare.comは、cloudflare.comとそのサブドメイン（例：www.cloudflare.com, api.cloudflare.com）のすべてのDNSレコードを含むゾーンです。

DNSにはサブドメイン用のディレクトリサービスがないため、api.cloudflare.comが存在するかどうかを知りたい場合は、DNSサーバーに問い合わせる必要があり、問い合わせを受けたDNSサーバーは最終的にapi.cloudflare.comが存在するかどうかをcloudflare.comに問い合わせることになります。この動作は、DNSSECの場合は当てはまりません。DNSSECを有効にすると、場合によっては、他の方法では隠蔽されるゾーンコンテンツが公開されてしまうことがあります。誰もがサブドメインの秘匿性を気にしているわけではなく、また、ほとんどのサイトには「www」サブドメインが存在するため、ゾーンの内容はすでに簡単に推測できてしまいます。しかし、サブドメインは、ログインポータルや、サイト所有者がプライベートで使用する他のサービスに使用されることがあります。サイト所有者が攻撃者からサイトを保護するために、「secretbackdoor.example.com」の公開を望まない場合があります。

DNSSECがサブドメインを公開してしまう理由は、ゾーンの署名方法に関係しています。歴史的に、DNSSECは静的ゾーンの署名に使用されていました。静的ゾーンは、特定のドメインに対するレコードの完全なセットです。DNSSEC署名レコードは、ドメインの中間地点で鍵署名鍵（KSK）とゾーン署名鍵（ZSK）を使用して作成され、権威サーバーに送信されて公開されます。権威サーバーはこのレコードセットを使用して、存在しないサブドメインに関する問い合わせも含め、あらゆる問い合わせに応答します。

サブドメインが存在しない場合にサーバーが無署名のNXDOMAIN（Non-Existent Domain）応答を返す標準のDNSとは異なり、DNSSECはすべての応答が署名されていることを保証しています。これには、NextSECure（NSEC）レコードと呼ばれる実在しないことを証明する特別なレコードを使用します。NSECレコードを使用して、「サブドメインXとサブドメインYの範囲内にサブドメインは存在しません」といった応答を返すことができます。ゾーン内の全てのドメイン間の隙間を埋めるような回答をすることで、NSECは静的な記述であらゆる問い合わせに応答することができます。また、NSECレコードには、各名称にどのようなリソースレコードタイプが存在するかも記載されています。

静的署名付きゾーンでは、定義上、固定数のレコードが存在します。各NSECレコードは次のNSECレコードを指しているため、その結果、すべてのサブドメインをカバーするNSECレコードの有限の「環」ができます。誰もが、すべてのサブドメインを把握するまで、NSECレコードを次から次へと辿り、ゾーンを「散策」することができるのです。この方法を用いると、そのゾーンの名前をすべて明らかにすることができ、内部情報が危険にさらされる可能性があります。

例えば、「example.com」というDNSSEC対応ゾーンがあり、サブドメイン「public.example.com」と「secret.example.com」があるとします。NSECレコードを追加することで、すべてのサブドメインの存在を明らかにすることができてしまいます。

example.comのNSECレコードを要求すると、次のようになります。

example.com. NSEC public.example.com. A NS SOA TXT AAAA RRSIG NSEC DNSKEY

public.example.comを問い合わせると、次のNSECレコードが得られます：

public.example.com. NSEC secret.example.com. A TXT AAAA RRSIG NSEC

secret.example.comを問い合わせると、次のNSECレコードが得られます。

secret.example.com.NSEC example.com. A TXT AAAA RRSIG NSEC

一つ目はゾーンtop/apexに対するもので、「example.com」という名前が存在し、次の名前が「public.example.com」であることが書いてあります。public.example.comのレコードには、次の名前が「secret.example.com」であることが書かれており、プライベートサブドメインの存在を明らかにしています。「secret.example.com」には、次のレコードが「example.com」であることが書かれており、サブドメインのチェーンが完成します。このように、わずかな問い合わせで、誰でもそのゾーンにあるレコードの完全なセットを知ることが可能です。

技術的には、DNSレコードは秘匿性を持たせるように考えられていませんが、実際にはそう考えられていることもあります。サブドメインは、しばらくの間、（企業のログインページなど）非公開の用途で使用されており、突然ゾーンファイルの内容が明らかになるようなことは予期しておらず、好まれないことがあります。

DNSSEC以前は、ゾーン内の名前の内容を検出する唯一の方法は、それらの問い合わせを行うか、権威サーバーの1つからゾーンの転送を試みることでした。ゾーン転送（AXFR）は頻繁にブロックされます。NSECの代替であるNSEC3は、ゾーン列挙の問題に対処するために導入されたものですが、NSEC3でもサブドメインの存在を明らかにすることは可能です。

.ch以下のほとんどのドメインはNSEC3を使用しています

NSEC3レコードはNSECレコードと似ていますが、問い合わせに対する応答がないドメイン名の署名された間隔ではなく、NSEC3はドメイン名のハッシュの署名された間隔を提供します。これは、ゾーンの列挙を防ぐためのものです。そのため、「example.com」と「www.example.com」 を含むゾーンのNSEC3チェーンは次のようになります（わかりやすくするために各NSEC3レコードを 3 行にしています）：

231SPNAMH63428R68U7BV359PFPJI2FC.example.com.NSEC3 1 0 3 ABCDEF
NKDO8UKT2STOL6EJRD1EKVD1BQ2688DM
A NS SOA TXT AAAA RRSIG DNSKEY NSEC3PARAM

NKDO8UKT2STOL6EJRD1EKVD1BQ2688DM.example.com.NSEC3 1 0 3 ABCDEF
231SPNAMH63428R68U7BV359PFPJI2FC
A TXT AAAA RRSIG

ここで

231SPNAMH63428R68U7BV359PFPJI2FC

example.com

NKDO8UKT2STOL6EJRD1EKVD1BQ2688DM

www.example.com

NSEC3レコードの最初の行にはハッシュ化されたゾーンの「名前」が含まれており、ハッシュラウンド数とハッシュに使用したソルトは、最初の行の最後の2つのパラメータ「3 ABCDEF」です。「1 0」はダイジェストアルゴリズム（1はSHA-1を意味する）と、ゾーンがオプトアウトを使用するかどうか（0は使用しないことを意味する）を表しています。2行目は「ゾーン内の次のハッシュ化された名前」で、3行目はその名前のタイプを列挙しています最初のNSEC3レコードの「次の名前」が、2番目のNSEC3レコードの名前と一致し、その「次の名前」でチェーンが完結することがお分かりいただけると思います。

NSECの列挙では、ドメイン内にありそうな名前を推測することで、ドメインの全リストを作成することができます。ゾーンに約100のドメイン名がある場合、ゾーン全体を列挙するのに約100回のリクエストが必要です。NSEC3では、存在しないレコードが要求された場合、次のゾーンが存在するNSEC3レコードがハッシュのアルファベット順に並んで署名された状態で返されます。次のクエリ名の候補が既にあるリストの隙間に当てはまるかどうかを確認することで、誰でも100回程度のクエリで完全な環を作成することができます。この計算を行えるツールはたくさんあり、nmapへのプラグインなどがあります。

ゾーン内のすべての有効な名前に対応するハッシュを用いて辞書攻撃を仕掛けることで、実際の名前を把握することができます。短い名前は簡単に推測でき、辞書を使えば、権威ネームサーバーに推測を殺到させなくても、存在を明らかにすることができるのです。HashCatのようなツールを使えばソフトウェアでこれを簡単に行うことができるため、ビットコインの人気によってハッシュ化に特化したハードウェアの価格が劇的に下がりました。暗号ハッシュを計算するために作られたデバイスの家内工業が急成長しています。Tesla Password cracker（下図）は、こうした既製品の一例です。

Teslsa Cracker

ハッシュは安価で実現できるため、NSEC3を設計通りに使用していもゾーンプライバシーはわずかに向上するのみです。名前がどれだけ保護されるかは、その名前の推測のしにくさに比例します。

つまり、NSECは平文のパスワードを公開するようなもので、NSEC3はUnix形式のパスワードファイルを公開するようなものなのです。どちらの手法も安全性は高くありません。NSEC3では、サブドメインは推測が困難であればあるほど、プライベートであると言えます。

この脆弱性は、RFC 4470および4471 (https://tools.ietf.org/html/rfc4470 とhttps://tools.ietf.org/html/rfc4471) で紹介されている「DNSSEC white lies」と呼ばれる技術によって緩和することができます。これはDan Kaminsky氏がデモンストレーションのために実装したものです。存在しないドメインに対するリクエストが来た場合、次の実ドメインのNSEC3レコードを提供する代わりに、アルファベット順に次のハッシュのNSEC3レコードが提示されます。これは、NSEC3の応答と問い合わせの間にハッシュが辞書的に一致するドメインが存在しないというNSEC3の保証を破ったことにはなりません。

NSEC3やNSECの「白い嘘」は、問い合わせに対してリアルタイムで署名が計算できる場合のみ実装できます。従来、DNS解決のための静的ゾーンレコードはオフラインで作成され、署名を持つすべてのレコードがゾーンファイルに格納されていました。このファイルは、稼働中のDNSサーバーによって読み取られ、ゾーンに関する問い合わせに応答することができるようになります。

CloudflareのDNSSEC実装では、効率的に生成できるECDSAの署名を活用し、DNSSECレコードに即席で署名しています。

DNSSECは様々なモードで動作するように設計されており、それぞれに異なるセキュリティ、パフォーマンス、利便性のトレードオフがあります。ライブ署名は、鍵管理の安全性が低い代わりに、ゾーンのコンテンツが露出してしまう問題を解決します。

最も一般的なDNSSECモードは、静的ゾーンのオフライン署名です。オフライン署名は、ネットワークに接続されていないマシンに秘密鍵を保持することで、署名システムを外部の脅威から高度に保護します。この運用モデルは、DNSの情報が頻繁に変更されない場合に適しています。

もう一つの一般的な動作モードに、集中型オンライン署名があります。アクセスが制限された専用のDNS署名システムでデータを署名することで、DNSデータの変更と公開を素早く行うことができます。事業者によっては、メインのDNSサーバーでDNS署名を実行しているところもあります。静的ゾーンのオフライン署名と同様に、このモードは中央署名モデルに従っています。つまり、単一の（またはレプリケートされた）中央署名機関がすべての署名を行い、そこから実際の権威DNSサーバーにデータが伝搬されます。

より急進的なモードは、必要に応じて実際の権威DNSサーバーがその場でデータに署名できるようにすることです。これにより、どこで応答が生成され署名されたかなどの地理的に依存する情報など、多くの新しい機能が実現されます。欠点は、鍵材料がインターネットに直接アクセスできる多くの異なるマシンに残ることです。エッジでライブ署名を行うと、鍵の配布などの新しい問題が発生し、ノードに余分なコンピューティング要件が課されます。

最近、Heartbleedとして知られるバグが発見され、サーバーアプリケーションに大きなセキュリティホールが開かれる事態となりました。これはOpenSSLのコーディングミスにより、リモートでメモリが公開される脆弱性が生じたものです。このバグにより、攻撃者はリモートからインターネットに面したサーバーから暗号鍵を抜き取ることができたのです。リモートでメモリが公開されてしまうバグは、鍵がDNSSECライブ署名のようなアクティブなプロセスで使用されている場合、秘密鍵のセキュリティに対する多くの脅威の1つに過ぎません。マシンがインターネットにさらされればさらされるほど、攻撃のベクトルは増えていきます。オフライン署名のマシンであれば、このような脅威にさらされる可能性がかなり低くなります。

鍵の安全性を確保する方法として、ハードウェアセキュリティモジュール（HSM）などのハードウェアベースのソリューションを使用する方法があります。この方法の主な欠点はコストであり、HSMは非常に高価（そして遅い）です。これは、利用者との距離を縮めるために地理的に分散しているDNSサーバーを運用する上で、最も厄介な点の一つです。すべてのサーバーロケーションにHSMを導入すると、コストがかかるだけでなく、法的な問題が発生する可能性があります。

鍵がリモート上に公開されることから保護するためのもう一つの解決策は、暗号化操作をシステムの信頼できるコンポーネントに引き渡すことです。そこで、暗号化を引き渡すことができるカスタムDNSサーバーが役立ちます。

DNSSECの鍵管理は、TLSの鍵管理と類似しており、同様の課題があります。今年初め、私たちはTLSの鍵の安全性を高めるために、キーレスSSLを導入しました。私たちはキーレスSSLを拡張して、DNSSECライブ署名用のリモートキーサーバーの利点を提供することを検討しています。

権威DNSサーバーを運用している事業者は、悪意のある分散サービス妨害（DDoS）攻撃の導線としてサーバーが利用されてしまうことに神経を尖らせることが多いようです。これは、DNSがステートレスプロトコルであるUDPを使用していることに起因しています。

TCPでは、それぞれの接続は3ウェイハンドシェイクから始まります。これにより、接続を開始する前にお互いのIPアドレスを認識し、正しいことを確認します。UDPでは、ハンドシェイクのような行為はありません。メッセージは、検証されないまま「送信元」のIPアドレスを持つIPに直接送信されます。攻撃者が「こんにちは、送信元IP：X」というUDPパケットをサーバーに送信すると、サーバーは通常「X」にUDPパケットを送信して応答することになります。「X」を送信者のIPアドレスではなく被害者のIPアドレスにすりことは、UDP「スプーフィング」（なりすまし）と呼ばれます。攻撃者は被害者になりすますことで、UDPリクエストに応答するサーバーを「リフレクト」されたトラフィックで過負荷状態に陥れることができます。これは、権威サーバーにも、オープンな再帰リゾルバーにも同様に適用されます。

DNSSECはUDPでも動作しますが、DNSクエリに対する応答は、複数のDNSKEYとRRSIGレコードを含む非常に長いものになる可能性があります。これはリフレクション攻撃を「増幅」させることができるため、攻撃者にとって魅力的なターゲットとなります。少量のスプーフィングされたUDP DNSSECリクエストがネームサーバーに送信されると、被害者は大量の反射トラフィックを受け取ることになります。場合によっては、これだけで被害者のサーバーを過負荷状態に陥れ、サービス拒否を引き起こすこともあります。

ルートサーバーに存在しないTLDを問い合わせた場合に返される応答は約100バイトですが、同じ問い合わせに対する署名付きの応答は約650バイト、増幅率にして6.5倍です。ルートは1,024ビットのRSA鍵で署名され、不存在の応答にはNSECが使用されます。TLDに存在しないドメインを1,024ビットの鍵で署名したNSEC3を使って要求した場合、増幅率は約10倍になります。さらに高い増幅率を得られるクエリもあり、最も効果的な「ANY」クエリがあります。

多くのサービスと同様に、DNSもTCP上で動作させることができます。TCPが必要であることを示すために、リゾルバに送り返すことができる「truncation」（切り捨て）フラグがあります。これにより、DNSリクエストの速度が遅くなるという代償を払いながら、DNSリフレクションの問題を解決することができます。しかし、16%のリゾルバがTCP切り捨てフラグを実装しておらず、4%がセカンドサーバを試行しないため、この解決策は現時点では実用的ではありません。

応答のサイズを小さくするもう一つの方法に、従来のRSA鍵の代わりに、 楕円曲線デジタル署名アルゴリズム （ECDSA） 鍵を使用するというものがあります。ECDSA鍵は同等の強度を持つRSA鍵よりもはるかに小さく 、より小さな署名を生成することで DNSSECの応答をはるかに小さくし、増幅率を低下させます。Google Public DNSは2014年末にECDSAのサポートを追加し、それ以来、他のいくつかの企業も 同様の措置をとっています。

TCPやECDSAのサポートは、一般的なDNSSECのサポートに比べるとまだ遅れており、代わりに従来の不正利用防止策で代用することができます。これには、 Resource Rate Limiting（RRL）、およびその他の経験則などがあります。

リフレクション攻撃から保護するために、Cloudflareはさまざまな角度からのアプローチに取り組んでいます。1つ目は、現在DNSサーバーで使用している攻撃識別に関する経験則と不正使用防止技術を利用すること、2つ目は、DNSSEC応答の増幅率を下げることです。最大増幅率を下げる方法としては、TCP上の「ANY」リクエストにのみ返信する、可能な限り小さいECDSA鍵を使用する、鍵のロールオーバーの頻度を減らす、などがあります。

Cloudflareは、ゾーンプライバシー、鍵管理、リフレクション／増幅のリスクに関して、DNSSECによってもたらされる複雑さを認識しています。適切な技術的判断と、運用管理を実施することで、DNSSECの危険性を防ぐことができます。