DNSSECの仕組み

ドメインネームシステム(DNS)は、インターネットの電話帳です。DNSはコンピューターに情報の送信先と入手先を教えます。残念ながら、DNSは、与えられたアドレスをすべて受け入れてしまい、疑うことを知りません。

メールサーバーはDNSを使用してメッセージをルーティングします。つまり、メールサーバーはDNSのインフラストラクチャのセキュリティの問題に対して脆弱です。2014年9月に、CMUの研究者によって、Yahoo!、Hotmail、Gmailサーバーを通して送信されたはずのメールが、不正なメールサーバーを介してルーティングされていたことがわかりました。攻撃者は、ドメインネームシステム(DNS)の数十年前の脆弱性を悪用していました。この脆弱性とは、DNSが応答を受け入れる前に資格情報をチェックしないというものです。

DNSSECのアイコン

これに対するソリューションは、DNSSECと呼ばれるプロトコルです。認証を行うことで、DNS上にもう1つの信頼レイヤーをプラスします。DNSリゾルバーがblog.cloudflare.comを探しているとき、「.com」というネームサーバーが「cloudflare」に返されたレコードをリゾルバーが照合するのを助け、「cloudflare」は「blog」に返されたレコードの照合を助けます。ルートDNSネームサーバーは、「.com」の照合を助けます。そして、ルートによって公開された情報は、Root Signing Ceremony(ルート署名セレモニー)を含む徹底的なセキュリティ手順を踏んで審査されます。

やさしいDNSSEC入門

DNSSECは、既存のDNSレコードに暗号署名を追加することで、安全なドメインネームシステムを確立します。これらのデジタル署名は、A、AAAA、MX、CNAMEなどの一般的なレコードタイプと一緒にDNSネームサーバーに格納されています。関連づけられた署名をチェックすることで、リクエストされたDNSレコードが権威ネームサーバーから送られたものであり、途中で改ざんされていない、中間者攻撃で注入された偽のレコードではないことを確認できます。

署名照合を容易にするために、DNSSECではいくつかの新しいDNSレコードタイプを追加しています。

  • RRSIG- 暗号署名を含む
  • DNSKEY- 公開署名鍵を含む
  • DS- DNSKEYレコードのハッシュ値を含む
  • NSECNSEC3- DNSレコードの明確な不在証明がある場合
  • CDNSKEYCDS- 親ゾーンのDSレコードの更新をリクエストする子ゾーン用。

この記事では、RRSIG、DNSKEY、DSレコード間の相互作用、ならびに、これらがDNS上に信頼のレイヤーを加える方法について説明します。

RRsets

DNSSECを使用してゾーンを保護するための最初のステップは、同じタイプのすべてのレコードをリソースレコードセット(RRSet)にグループ化することです。たとえば、同じラベルのゾーン内に3つのAAAAレコードがある場合(例:label.example.com)、これらはすべて、単一のAAAA RRSetにまとめられます。

RRsetの図

実際にデジタル署名がなされるのは、個々のDNSレコードではなく、この完全なRRSetに対してです。もちろん、これは、同じラベルをもつゾーンから、1 つだけ取り出して検証するのではなく、すべてのAAAAレコードをリクエストして検証する必要があるということを意味します。

ゾーン署名鍵

DNSSECの各ゾーンには、ゾーン署名鍵のペア(ZSK)があります。ZSK秘密鍵はゾーン内の各RRSetにデジタル署名し、ZSK公開鍵は署名を検証します。DNSSECを有効にするには、ゾーンの運営者はZSK秘密鍵を使用して各RRSetのデジタル署名を作成し、RRSIGレコードとしてネームサーバーに格納します。これは、「これらは私のDNSレコードであり、私のサーバーから来て、このように見えるはずです」と宣言するのに似ています。

図:ゾーン署名鍵1

ただし、DNSリゾルバーに署名を検証する方法がない限り、これらのRRSIGレコードは役に立ちません。ゾーンの運営者は、ZSK公開鍵をDNSKEYレコードのネームサーバーに追加し、これを利用できるようにする必要があります。

DNSSECリゾルバーが特定のレコードタイプ(例:AAAA)をリクエストすると、ネームサーバーが対応するRRSIGを返します。このとき、リゾルバーは、ネームサーバーから、ZSK公開鍵を含むDNSKEYレコードを引き出すことができます。RRSet、RRSIG、ZSK公開鍵の全部を使って、応答を照合できるのです。

図:ゾーン署名鍵2

DNSKEYレコードのゾーン署名鍵が信頼できるものであれば、ゾーン内のすべてのレコードが信頼できます。しかし、ゾーン署名鍵が侵害されている場合はどうでしょう?ZSK公開鍵を検証する方法が必要になります。

鍵署名鍵

ゾーン署名鍵に加えて、DNSSECネームサーバーにも鍵署名鍵(KSK)があります。KSKは、前述のZSKがRRSetの安全性を確保した場合とまったく同じ方法でDNSKEYレコードを照合します。KSKは(DNSKEYレコードに保存されている)ZSK公開鍵に署名し、DNSKEYのRRSIGを作成します。

図:鍵署名鍵1

ZSK公開鍵と同様に、ネームサーバーはKSK公開鍵を別のDNSKEYレコードで公開します。これにより、上に示されているDNSKEY RRSetが得られます。KSK公開鍵とZSK公開鍵はいずれもKSK秘密鍵によって署名されます。その後リゾルバーが、KSK公開鍵を使ってZSK公開鍵を照合できるようになります。

リゾルバーの検証は以下のようなものです。

  • 必要なRRSetをリクエストします。これにより、対応するRRSIGレコードが返されます。
  • ZSK公開鍵およびKSK公開鍵を含むDNSKEYレコードをリクエストします。これにより、DNSKEY RRSetのRRSIGが返されます。
  • リクエストのあったRRSetのRRSIGをZSK公開鍵で照合します。
  • DNSKEY RRsetのRRSIGをKSK公開鍵で照合します。
図:鍵署名鍵2

もちろん、DNSKEY RRSetと、対応するRRSIGレコードはキャッシュできるため、DNSネームサーバーに不必要なリクエストが絶えず殺到することはありません。

ゾーン署名鍵と鍵署名鍵を分けて使用する理由は?次のセクションで説明するように、古いKSKまたは侵害されたKSKを交換することは困難です。それよりも、ZSKを交換する方がはるかに簡単です。ZSKを交換すれば、サーバーのセキュリティを損なうことなくより小さなZSKを使用でき、サーバーが応答ごとに送信するデータ量を最小限に抑えることができます。

これで、ゾーン内での信頼が確立されましたが、DNSは階層化されたシステムであり、ゾーンが独立して動作することはほとんどありません。さらにやっかいなことに、鍵署名鍵は自身で署名を行うため、追加の信頼を提供することもありません。このため、ゾーン内の信頼を親ゾーンに接続する方法が必要になります。

委任署名者(Delegation Signer)レコード

DNSSECは、親ゾーンから子ゾーンへの信頼の移管を可能にする委任署名者 (DS) レコードを導入しています。ゾーンの運営者は、KSK公開鍵を含むDNSKEYレコードをハッシュ化し、それを親ゾーンに送り、DSレコードとして公開します。

図:委任署名者レコード

リゾルバーが子ゾーンを参照するたびに、親ゾーンもDSレコードを提供します。このDSレコードによって、子ゾーンのDNSSECが有効化されていることを、リゾルバーが認識します。子ゾーンのKSK公開鍵の妥当性を確認するため、リゾルバーはKSK公開鍵をハッシュ化し、それを親から送られてきたDSレコードと比較します。これらが一致する場合、リゾルバーは、KSK公開鍵が改ざんされたものではないとみなすことができます。つまり、子ゾーン内のすべてのレコードが信頼できるということです。これが、DNSSECで信頼の連鎖を確立する方法です。

KSKを変更する場合は、親ゾーンのDSレコードも変更する必要があることに注意してください。DSレコードの変更は複数の手順が必要で、誤って実行された場合は、ゾーンが壊れてしまうことがあります。まず、親が新しいDSレコードを追加する必要があり、その後、元のDSレコードのTTLが期限切れになるまで待ってから削除する必要があります。このため、鍵署名鍵よりもゾーン署名鍵を交換する方がはるかに簡単です。

明確な不在証明

存在しないドメインのIPアドレスをDNSにリクエストすると、空の応答が返されます。これは「申し訳ありませんが、要求されたゾーンは存在しません」と明確に伝える方法がないためです。これは、応答を認証したい場合に問題になります。署名するメッセージが存在しないためです。DNSSECは、NSECおよびNSEC3のレコードタイプを追加することでこれを修正します。どちらも認証済みの不在証明を許可します。

NSECは、「次の安全な」レコードを返すことで機能します。たとえば、api、blog、およびwwwのAAAAレコードを定義するネームサーバーがあるとします。ストア用のレコードをリクエストすると、wwwを含むNSECレコードが返されます。つまり、レコードがアルファベット順にソートされている場合、ストアとwwwの間にAAAAレコードは存在しないということを示しています。これは、ストアが存在しないことを効果的に伝える方法です。また、NSECレコードは署名されているため、RRSetと同様に、これに対応するRRSIGを検証できます。

残念ながら、このソリューションを使用すると、誰もがどのレコードを探しているかを知らなくても、ゾーン内を歩き、すべてのレコードを収集することができます。これは、ゾーン管理者がゾーンの内容の秘密が保たれていると期待していた場合に、潜在的なセキュリティ上の脅威となる可能性があります。この問題の詳細については、DNSSEC: 複雑さと検討事項DNSSECの適切な運用 のCloudflareの独自のソリューションを参照してください。

信頼の連鎖

ゾーン内で信頼を確立し、それを親ゾーンに接続する方法が明らかになりましたが、DSレコードは信頼できるのでしょうか?DSレコードは、他のRRSetと同様に署名されています。つまり、対応するRRSIGが親にあることを意味します。照合プロセス全体は、親のKSK公開鍵に到達するまで繰り返されます。これを検証するには、その親のDSレコードに移動し、信頼の連鎖を順に上までたどっていく必要があります。

図:信頼の連鎖

しかし、最終的にルートDNSゾーンに到達すると、問題が発生します。照合対象である親のDSレコードが存在しないのです。ここで、グローバルインターネットの非常に人間味溢れる場面が登場します。

ルート署名セレモニー では、世界中から選ばれた個人が集まり、透明性の非常に高い公共の場で、厳密に監査された方法でルートDNSKEY RRSetに署名します。セレモニーでは、ルートネームサーバーのKSKおよびZSKの公開鍵を照合するために使用できるRRSIGレコードを生成します。親のDSレコードを根拠に、 KSK公開鍵を信頼するのではなく、KSK秘密鍵へのアクセスに至るセキュリティ手順が信頼できるものなので、KSK公開鍵も正当であると推測するのです。

親ゾーンと子ゾーン間の信頼を確立する能力は、DNSSECにとって必要不可欠なものです。連鎖のどこかが壊れていた場合、リクエストしているレコードを信頼することはできません。中間者がレコードを改ざんし、彼らの望むIPアドレスに誘導される可能性があるためです。

まとめ

HTTPSと同様に、DNSSECでは、応答の認証を有効化することで、プロトコルにセキュリティ層を追加して、その安全性を確保します。HTTPSがトラフィックを暗号化して、インターネット上の活動を誰からものぞき見されないようにするのに対し、DNSSECでは応答に署名するだけで、偽造を検出できるようにします。DNSSECでは、暗号化を組み込むことなく、実際の問題に対するソリューションを提供します。

Cloudflareの目標は、できるだけ簡単にDNSSECを有効にすることです。現在、Cloudflareの有料プランをご利用中のお客様は、DNSSECをWebプロパティに追加できます。スイッチひとつで、DNSSECを有効にでき、DSレコード(Cloudflareが自動的に生成します)をレジストラーにアップロードできます。DNSSECの入手方法についての詳細はこちらをご覧ください。

Cloudflareは、インターネットドラフトを公開しました。レジストリーとレジストラーがお客様に代わってDSレコードをアップロードする自動化された方法について概説しています。これにより、Cloudflareはコミュニティ全体でDNSSECを自動的に有効化することができます。更新情報は随時お知らせします。

Cloudflareの設定は簡単です

ドメインの設定にかかる時間は5分未満です。ホスティングプロバイダーを引き続きご利使っただけます。コード変更は必要はありません。

Cloudflareの料金設定

Cloudflareを利用することで、どなたのインターネットアプリケーションでもメリットを受けることができます。
ニーズに合ったプランをお選びください。

無料 $ 0 /月 /Webサイト
展開してさらに表示 非表示
個人のWebサイトやブログを運営している方、またはCloudflareを試してみたい方向け。

詳細

Freeプランには次の機能がすべて含まれます。
  • 定額制のDDoS対策
  • グローバルなCDN
  • 共有SSL証明書
  • アカウント監査ログへのアクセス
  • 3つのPage Rule
すべての機能を比較
Pro $ 20 /月 /Webサイト
展開してさらに表示 非表示
基本的なセキュリティやパフォーマンスを必要とするプロフェッショナルなWebサイト、ブログ、ポートフォリオ向け。

詳細

ProプランにはFreeプランの全機能のほか、次の機能が含まれます。
  • Cloudflareルールセットに基づくWebアプリケーションファイアウォール(WAF)
  • Polish™による画像最適化
  • Mirage™によるモバイル最適化
  • I'm Under Attack™モード
  • アカウント監査ログへのアクセス
  • 20のPage Rule
すべての機能を比較
ビジネス $ 200 /月 Webサイト
展開してさらに表示 非表示
高度なセキュリティやパフォーマンス、PCI準拠、優先メールサポートを必要とする小規模な電子商取引Webサイトや企業向け。

詳細

Businessプランには、Proプランの全機能のほか、次の機能が含まれます。
  • 25のカスタムルールセットに基づくWebアプリケーションファイアウォールf(WAF)
  • カスタムSSL証明書のアップロード
  • Modern TLS OnlyモードとWAFによるPCI準拠
  • Bypass Cache on Cookie
  • Railgun™による動的コンテンツの配信の高速化
  • 優先メールサポート
  • アカウント監査ログへのアクセス
  • 50のPage Rule
すべての機能を比較
エンタープライズプラン 問い合わせ
展開してさらに表示 非表示
エンタープライズクラスのセキュリティとパフォーマンス、1日24時間365日の優先電話、メール、チャットサポート、稼働率の保証を必要とする企業向け。

詳細

Enterpriseプランには、Businessプランの全機能のほか、次の機能が含まれます。
  • 電話、メール、チャットによる1日24時間365日のエンタープライズクラスのサポート
  • 稼働率100%保証と25倍の払い戻しを定めたSLA
  • ネットワークの優先順位付けによるエンタープライズクラスのDDoS対策
  • 無制限のカスタムルールセットに基づく高度なWebアプリケーションファイアウォール(WAF)
  • マルチユーザーによるロールベースのアカウントアクセス
  • 複数のカスタムSSL証明書のアップロード
  • 未加工ログへのアクセス
  • アカウント監査ログへのアクセス
  • 専任のソリューションおよびカスタマーサクセスエンジニア
  • 中国のCDNデータセンターへのアクセス(有料)
  • 100のPage Rule
すべての機能を比較

無料

$ 0 /
 
個人のWebサイトやブログを運営している方、またはCloudflareを試してみたい方向け。

Pro

$ 20 /
ドメインあたり
基本的なセキュリティやパフォーマンスを必要とするプロフェッショナルなWebサイト、ブログ、ポートフォリオ向け。

Business

$ 200 /
ドメインあたり
高度なセキュリティやパフォーマンス、PCI準拠、優先メールサポートを必要とする小規模な電子商取引Webサイトや企業向け。

Enterprise

お問い合わせ
 
エンタープライズクラスのセキュリティとパフォーマンス、24時間365日の優先電話、メール、チャットサポート、稼働率の保証を必要とする企業向け。

Cloudflareのお客様

25,000,000以上のインターネットプロパティからの信頼

trustedby crunchbase black
trustedby ao com black
trustedby zendesk black
logo sofi gray 32px wrapper
trustedby log me in black
trustedby digital ocean black
trustedby okcupid black
trustedby montecito black
trustedby discord black
trustedby library of congress black
trustedby udacity black
trustedby marketo black