DNSSECの仕組み

メールサーバーは、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レコードのハッシュ値を含む
• NSECとNSEC3 - DNSレコードの明確な不在証明がある場合
• CDNSKEYとCDS - 親ゾーンのDSレコードの更新をリクエストする子ゾーン用。

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

RRsets

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

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

ゾーン署名鍵

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

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

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

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

鍵署名鍵

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

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公開鍵で照合します。

もちろん、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アドレスに誘導される可能性があるためです。

レジストラのDNSSEC

DNSSECの信頼はトップダウンであるため（ルートゾーンが.comを検証し、.comゾーンがcloudflare.comゾーンを検証するなどのように）、DNSSECを有効にするには、Webサイトの所有者がレジストラであるあなたとともにDSレコードを更新する必要があります。

この部分には問題があり、DSレコードのコピー&ペーストは人為的なミスが発生する可能性があり、経験の浅いユーザーにとっては複雑さが増してしまいます。私たちはDNSSECをできるだけ簡単に導入できるようにしたいと考えています。

もしCloudflareがレジストラやレジストリと直接やりとりできれば、Cloudflare上のすべてのWebサイトに対してDNSSECを自動的に有効化し、人手をかけずにそのキーを管理することができます。

DNSSEC展開の一環として、私たちは.caのレジストリであるCIRAと共にインターネットドラフトを公開し、CloudflareのようなDNS運営企業がレジストラやレジストリと通信し、DNSSEC管理を自動化するためのプロトコルを提案しています。

すべての人にとってDNSSECをより身近なものにするために、是非私たちの取り組みに参加してください

NICチリ（.cl）やeNIC（.ee）など、既にいくつかのレジストリで対応の追加が予定されています。レジストラまたはレジストリにお勤めで、詳細を知りたい方、プロトコルの開発に携わりたい方、Cloudflareとの統合を追加したい方は、dnssec-integration@cloudflare.comまでメールでご連絡ください。

まとめ

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

Cloudflareの目標は、DNSSECの有効化をできるだけ簡単にすることです。Cloudflareのお客様はすべて、スイッチをオンにしてDNSSECを有効にし、DSレコード（当社で自動生成）をレジストラへアップロードすることによって、WebプロパティにDNSSECを追加できます。DNSSEC導入方法の詳細については、こちらをご覧ください。

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