DNSSECの仕組み

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ロゴ
委任署名者(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アドレスに誘導される可能性があるためです。
Summary

Similar to HTTPS, DNSSEC adds a layer of security by enabling authenticated answers on top of an otherwise insecure protocol. Whereas HTTPS encrypts traffic so nobody on the wire can snoop on your Internet activities, DNSSEC merely signs responses so that forgeries are detectable. DNSSEC provides a solution to a real problem without the need to incorporate encryption.

Cloudflare’s goal is to make it as easy as possible to enable DNSSEC. All Cloudflare customers can add DNSSEC to their web properties by flipping a switch to enable DNSSEC and uploading a DS record (which we'll generate automatically) to their registrar.: Learn more about how to get DNSSEC.

We’ve also published an Internet Draft outlining an automated way for registries and registrars to upload DS records on behalf of our customers. This will enable Cloudflare to automatically enable DNSSEC for our entire community. Stay tuned for updates.

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

「ロゴ Doordashが信頼を寄せる」グレー色
「ロゴGarminが信頼を寄せる」グレー色
「ロゴ 23andmeが信頼を寄せる」グレー色
「ロゴ LendingTree が信頼を寄せる」グレー色
NCR logo
Thomson Reuters logo
「ロゴZendeskが信頼を寄せる」グレー色