DNSSECとは何か、その仕組みは？

DNSはセキュリティではなくスケーラビリティを重視して構築されたため、DNSSECはセキュリティ対策のポートフォリオに不可欠な要素となります。

ところで、DNSSECとは何でしょうか？ まず、これは「Domain Name System Security Extensions（ドメインネームシステムセキュリティ拡張）」の略称です。これは、暗号技術に基づくデジタル署名を使用して、ドメインネームシステム（DNS）のクエリと応答を認証するための一連の仕様です。

一見すると、DNSSECの導入は難しそうに思えるかもしれません。しかし、一般に公開されているドメインであれば、その価値を十分に享受できます。

本記事では、まずDNSSECが具体的に何であるかについて触れます。次に、従来のDNS解決の仕組みと、それがなぜサイバー攻撃に対して非常に脆弱なのかについて詳しく解説します。さらに、DNSSECの仕組みと、そこで行われる認証手順について詳しく掘り下げます。最後に、BlueCatがDNSSECの導入をいかに容易にするかについて探ります。

DNSSECとは？

DNSSECとDNSセキュリティは同じものではないことに注意してください。名称は似ていますが、DNSSECはDNSセキュリティの略語ではありません。（後者は、数多くの戦略や製品を包括する総称です。）

では、DNSSECは具体的にどのような役割を果たすのでしょうか？有効化されると、DNSSECはDNSサーバーが以下の質問に答えるのを支援します：

• ルートネームサーバーまたは権威ネームサーバーは、クエリへの応答を提供する権限を持っていますか？
• クエリ応答の内容は信頼できますか？
• さらに、転送中に応答が改ざんされていないと信頼してもよいのでしょうか？

DNSSECをサポートするドメインが増えれば増えるほど、インターネットはすべての人にとってより安全なものになります。インターネットソサエティのDNSSEC統計によると、トップレベルドメインの大部分はすでにDNSSECを導入しています。

DNSSEC なしの DNS

通常のDNS解決は極めて単純です。デバイスからDNSクエリが送信されると、ドメインネームサーバーとリゾルバーが介入してDNSルックアップを実行します。これにより、DNSクエリに対して、関連するレコードからIPアドレスを含む応答が確実に返されます。

残念ながら、このケースにおいて「シンプル」は「無防備」を意味することもあります。DNSプロトコルに固有の特性により、あらゆるエンティティがサイバー攻撃のリスクにさらされる可能性があります。

リゾルバーは、リクエストの目的に沿ったデータを受信している限り、クライアントにIPアドレスを返すことができるようになるまでクエリを継続します。通常のDNS解決では、受信した応答を精査して、上記の3つの質問に答えることはできません。

これにより、標準的なDNSクエリは、DNSキャッシュポイズニング（および密接に関連するDNSポイズニング、別名DNSスプーフィング）のような中間者攻撃に対して脆弱になります。 攻撃者は、DNSリクエストに対する正当な応答を置き換えるために、偽造された応答を注入します。この偽造された応答は、多くの場合、正当なサイトと全く同じに見えるように設定された、攻撃者が制御するサーバーを指し示します。これにより、エンドユーザーは自分が本来いるべきではない場所にアクセスしていることに全く気づかないままになってしまう可能性があります。

DNSSECが有効になっていない場合、悪意のあるサイトもリゾルバーにキャッシュされます。その結果、同じDNSリゾルバーを使用している他のデバイスも、その悪意のあるサイトにアクセスすることになります。このサイトは、あらかじめ設定された有効期限（TTL）が切れるまでキャッシュに残り、無数のデバイスに影響を及ぼす可能性があります。

DNSSEC：その仕組み

基本的に、DNSSECはDNSクエリに対する応答を、クライアントデバイスに返す前に検証します。DNSSECは、一般的なDNSレコードタイプとともに、ネームサーバーに保存されたデジタル署名を使用します。

DNSSECの中核をなすのは、公開鍵と秘密鍵のペアです。各DNSゾーンには、公開鍵と秘密鍵があります。

公開鍵暗号は、DNSSECの検証における出発点です。誰でも利用可能な公開鍵は、対応する秘密鍵で署名されたメッセージを復号するための手段を提供します。

明確にしておきますが、DNSSECのセキュリティには、DNSデータの暗号化、SSL証明書、共有秘密鍵といった一般的な対策は含まれていません。

重要な用語について（言葉遊びの意図はありません）

RRSIGレコード：DNSSECによるDNSゾーンの保護は、同じ名前とタイプ（例：Aレコード）を持つDNSレコードをリソースレコードセット（RRset）にグループ化することから始まります。実際に署名されるのは、個々のDNSレコードではなく、このRRsetです。RRSIGレコードには、RRsetに対する暗号署名が格納されています。

ゾーン署名鍵（ZSK）ペア：DNSSEC対応の各ゾーンには、ZSKの公開鍵と秘密鍵のペアがあります。ネットワーク管理者は、秘密鍵を使用してゾーン内の各RRセットに対して暗号署名を作成し、それらをRRSIGレコードとして保存します。ZSKの公開鍵は署名を検証するために使用され、DNSKEYレコードに保存されます。

DNSKEYレコード：DNSKEYレコードには公開鍵が格納されます。通常、ゾーンごとに2つあり、ゾーン署名鍵（ZSK）と鍵署名鍵（KSK）に対応しています。リゾルバーは、DNSKEYレコードを使用して、RRSIGレコード内の署名が正当であることを検証します。

鍵署名鍵（KSK）： ZSKが侵害されていないことを保証するため 、DNSネームサーバーには、ZSKの公開鍵を検証するためのKSKも用意されています。KSKはZSK内の公開鍵に署名し、DNSKEYレコード用のRRSIGを作成します。KSKの秘密鍵は、ZSKとKSKの両方の公開鍵に署名を行います。

DSレコード：DSレコードは、親ゾーンと子ゾーン間の関連性を証明します。DSレコードは親ゾーンに存在し、KSKを含む子ゾーンのDNSKEYのハッシュ値を含んでいます。DSレコードは、信頼の連鎖における次の鍵を指し示します。

信頼の連鎖

各暗号鍵は後続の暗号鍵に署名を行うため、各DNSゾーンはその直下のレベルを検証できるようになり、いわゆる「信頼の連鎖」が形成されます。この連鎖の最上位には、トラストアンカーが存在します。

ドメインネームシステムの各レベルで検証が行われます。応答の正当性が確認された後、クライアントデバイスはその応答を受け取ります。信頼の連鎖がいずれかの時点で途切れ、レコードの検証が行えない場合、DNSサーバーは代わりにSERVFAILというDNS応答コードを返します。

DNSSECのステップバイステップ解説

DNSSECの解決および検証の基本的な手順は以下の通りです：

1. まず、クライアントはローカルの検証型再帰サーバーに対して、example.com の A レコードを要求します。
2. 検証を行う再帰サーバーは、ルートから.example.comゾーンの権威サーバーに至る通常の再帰パスに従います。
3. 次に、再帰サーバーは権威サーバーにAレコードを要求します。
4. 権威サーバーは、example.com に対する A レコードおよび対応する RRSIG A レコードを応答として返します。
5. その後、再帰サーバーは example.com の権威サーバーに対し、そのゾーンの DNSKEY レコードを問い合わせます。
6. example.comの権威サーバーは、example.comのDNSKEYレコードおよび対応するRRSIG DNSKEYレコードを返します。

7. 次に、再帰サーバーは .com に example.com の DS レコードを問い合わせます。
8. .comサーバーは、example.comに対するDSレコードおよび対応するRRSIG DSレコードを応答として返します。
9. その後、再帰サーバーは .com サーバーに DNSKEY レコードを要求します。
10. .comサーバーは、DNSKEYレコードおよび対応するRRSIG DNSKEYレコードを応答として返します。

11. 次に、再帰サーバーはルートサーバーに対して「.com」のDSレコードを要求します。
12. ルートサーバーは、.com に対する DS レコードおよび対応する RRSIG DS レコードを返します。
13. その後、再帰サーバーはルートのDNSKEYレコードを要求します。
14. ルートサーバーは、ルートに対するDNSKEYレコードおよび対応するRRSIG DNSKEYレコードを返します。
15. 最後に、再帰サーバーは、設定されたトラストアンカーを使用して、DNSKEYレコードおよびルートに対応するRRSIG DNSKEYレコードの検証を行います。DNSSEC対応のリゾルバーには、ルートサーバーからの応答を検証するために必要な鍵がすでに組み込まれています。

キャッシュされた応答

これらの手順は、応答がまだキャッシュされていない場合のゾーンに対する最初のクエリを対象としています。一度キャッシュされると、ルートに至るまでのチェーン上のすべての検証はすでに完了しています。その場合、クライアントが example.com とは異なる A レコードを要求しても、その A レコードの署名を検証する作業のみを行えば済みます。

インターネット・システムズ・コンソーシアム（ISC）が提供するDNSSECに関する全10回のウェビナーシリーズでは、そのプロセスを詳細に解説しています。DNSSECの解決と検証に関する第4回のウェビナーは、さらに理解を深めるのに役立ちます。

中間者攻撃の阻止

DNSSECが有効になっている状態で中間者攻撃が試みられた場合、検証を行うリゾルバーは、その起源を検証するための暗号データを持たないため、不正なサーバーからの応答を拒否します。リゾルバーは偽の応答をクライアントに返さないため、クライアントは不正なサイトへ誘導されることはありません。

さらに、DNSSECは「非存在の証明（PNE）」を提供します。PNEにより、DNSSECで署名されたゾーンは、NXDOMAIN応答（「そのサイトは存在しません」という応答）が正当であることを証明できます。 これにより、攻撃者が攻撃の際に偽のNXDOMAIN応答を挿入することを防ぎます。クライアントを悪意のあるサーバーにリダイレクトすることはありませんが、影響を受けたキャッシュサーバーの背後にあるユーザーに対しては、あたかもオフラインであるかのように見せかけてしまいます。

BlueCatはDNSSECの導入を容易にします

DNSSEC の導入方法を検討する際、その複雑さや必要な知識の多さを過小評価しがちです。一元化され、自動化された DNS インフラストラクチャがなければ、その課題はさらに大きくなります。

手動での実装には、少なくともレコードのメンテナンスと鍵のロールオーバー（侵害のリスクを低減するために鍵を定期的に更新すること）が必要です。

しかしそれ以外にも、ゾーンに変更があるたびに実行しなければならない、RRセットやゾーンの再署名といった重要な手順があります。これらの手順のいずれかを誤って実行すると、ゾーンが利用不能になってしまいます。 PNEチェーンの維持管理も、DNSSECで署名されたゾーンを手動で管理する上で、最も手間がかかり、かつミスを起こしやすい作業の一つです。

BlueCat を使用して DNS インフラストラクチャを一元化すると、以下の DNSSEC 関連のタスクがバックグラウンドで自動的に実行されます：

• 暗号鍵ペアの生成
• ゾーン内のすべてのレコードに対して、PNEチェーン（NSECまたはNSEC3レコードを含む）を生成・維持する
• ゾーンおよび関連するすべてのDNSレコードへの署名
• 親ゾーン用のDSレコードの生成
• 定義されたスケジュールに従って、KSKおよびZSKをシームレスに更新
• 緊急ロールオーバー時の新しいKSKまたはZSKの生成
• 鍵生成の成功・失敗の監視
• 自動生成に失敗した場合の新しい鍵ペアの手動生成

BlueCatは、お客様が1つの中央プラットフォームから簡単に設定できるようにすることで、DNSSECを簡素化します。BlueCatプラットフォームがどのように役立つかをご覧ください。 [email protected]