DNSSECの仕組み

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

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

これに対するソリューションはDNSSECと呼ばれるプロトコルで、認証を行うことによりDNS上に信頼性チェックのレイヤーを1層追加します。たとえば、DNSリゾルバーがblog.cloudflare.comを探しているとします。「.com」というネームサーバーが、リゾルバーが「cloudflare」で問い合わせて返ってきたレコードの検証を助け、「blog」の問い合わせに対して返されたレコードの検証を「cloudflare」が助けます。ルート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分未満です。ホスティングプロバイダーを引き続きご利用いただけます。コード変更は必要はありません。


何百万ものインターネットプロパティからの信頼

「ロゴMarsが信頼を寄せる」グレー色
「ロゴ Lorealが信頼を寄せる」グレー色
「ロゴ Doordashが信頼を寄せる」グレー色
「ロゴGarminが信頼を寄せる」グレー色
「ロゴ IBMが信頼を寄せる」グレー色
「ロゴ 23andmeが信頼を寄せる」グレー色
「ロゴShopigyが信頼を寄せる」グレー色
「ロゴ LendingTree が信頼を寄せる」グレー色
「ロゴ Labcorpが信頼を寄せる」グレー色
「ロゴNCR が信頼を寄せる」グレー色
「ロゴトムソン・ロイターが信頼を寄せる」グレー色
「ロゴZendeskが信頼を寄せる」グレー色