次の方法で共有

DNSSEC の概要 (プレビュー)

  • [アーティクル]

この記事では、ドメイン ネーム システム セキュリティ拡張機能 (DNSSEC) の概要を示し、DNSSEC の用語についても紹介します。 DNSSEC ゾーン署名の利点について説明し、DNSSEC 関連のリソース レコードを表示するための例を示します。 Azure パブリック DNS ゾーンに署名する準備ができたら、次のハウツー ガイドを参照してください。

Note

DNSSEC ゾーン署名は現在プレビュー段階です。
ベータ版、プレビュー版、または一般提供としてまだリリースされていない Azure の機能に適用される法律条項については、「Microsoft Azure プレビューの追加使用条件」を参照してください。

DNSSEC とは

DNSSEC は、ドメイン ネーム システム (DNS) の応答が正規のものであることを検証可能にすることで、DNS プロトコルのセキュリティを向上させるための一連の拡張機能です。 DNSSEC は、発信元の認証、データ整合性、および不在認証の機能を備えています。 DNSSEC を使用すると、DNS プロトコルが特定の種類の攻撃 (特に DNS スプーフィング攻撃) を受ける可能性が大幅に減少します。

コア DNSSEC 拡張機能は、次の RFC (Request for Comments) で規定されています。

  • RFC 4033: 「DNS セキュリティの概要と要件」
  • RFC 4034: 「DNS セキュリティ拡張機能のリソース レコード」
  • RFC 4035: 「DNS セキュリティ拡張機能のプロトコルの変更」

DNSSEC RFC の概要については、「RFC9364: DNS セキュリティ拡張機能 (DNSSEC)」を参照してください。

DNSSEC の動作のしくみ

DNSSEC を使用した DNS ゾーンは、ゾーン署名と呼ばれるプロセスによってセキュリティ保護されます。 DNSSEC を使用してゾーンに署名すると、DNS クエリと応答の基本的なメカニズムを変更することなく検証のサポートが追加されます。 DNSSEC を使用してゾーンに署名するには、ゾーンのプライマリ権限を持つ DNS サーバーが DNSSEC をサポートしている必要があります。

ゾーンに署名すると、リソース レコードの署名 (RRSIG) とその他の暗号化レコードがゾーンに追加されます。 次の図では、ゾーン contoso.com における、ゾーン署名前とゾーン署名後の DNS リソース レコードを示します。

DNSSEC を使用して署名したときに RRSIG レコードがどのようにゾーンに追加されるかを示す図。

DNS 応答の DNSSEC 検証は、連続した信頼チェーンを持つこれらのデジタル署名を使用して行われます。

Note

DNSSEC 関連のリソース レコードは、Azure portal には表示されません。 詳細については、「DNSSEC 関連のリソース レコードを表示する」を参照してください。

DNSSEC を使用してゾーンに署名する理由

SC-20: セキュリティで保護された名前/アドレス解決サービスなどの一部のセキュリティ ガイドラインに準拠するには、DNSSEC を使用してゾーンに署名する必要があります。

DNS 応答の DNSSEC 検証により、DNS リダイレクトとも呼ばれる一般的な種類の DNS ハイジャック攻撃を防ぐことができます。 DNS ハイジャックは、クライアント デバイスが不正な (スプーフィングされた) DNS 応答を使用して悪意のあるサーバーにリダイレクトされた場合に発生します。 DNS キャッシュ ポイズニングは、DNS 応答のスプーフィングに使用される一般的な方法です。

DNS ハイジャックのしくみの一例を次の図に示します。

DNS ハイジャックのしくみを示す図。

通常の DNS 解決

  1. クライアント デバイスが contoso.com の DNS クエリを DNS サーバーに送信します。
  2. DNS サーバーが contoso.com の DNS リソース レコードで応答します。
  3. クライアント デバイスが contoso.com に応答を要求します。
  4. contoso.com アプリまたは Web サーバーがクライアントに応答を返します。

DNS ハイジャック

  1. クライアント デバイスが contoso.com の DNS クエリをハイジャックされた DNS サーバーに送信します。
  2. DNS サーバーが contoso.com の無効な (スプーフィングされた) DNS リソース レコードで応答します。
  3. クライアント デバイスが contoso.com の応答を悪意のあるサーバーに要求します。
  4. 悪意のあるサーバーがスプーフィングされた応答をクライアントに返します。

スプーフィングされる DNS リソース レコードの種類は、DNS ハイジャック攻撃の種類によって異なります。 MX レコードがスプーフィングされてクライアントの電子メールがリダイレクトされたり、A レコードがスプーフィングされてクライアントが悪意のある Web サーバーに送られたりする可能性があります。

DNSSEC は、DNS 応答に対して検証を実行することで、DNS ハイジャックを防止します。 ここで示されている DNS ハイジャック シナリオでは、contoso.com ドメインが DNSSEC を使用して署名されている場合、クライアント デバイスは検証されていない DNS 応答を拒否できます。 検証されていない DNS 応答を拒否するには、クライアント デバイスで contoso.com に対する DNSSEC 検証を適用する必要があります。

DNSSEC には、ゾーン列挙を防ぐための Next Secure 3 (NSEC3) も含まれています。 ゾーン列挙 (ゾーン ウォーキングとも呼ばれます) は、攻撃者が子ゾーンを含むゾーン内のすべての名前のリストを作成する攻撃です。

DNSSEC を使用してゾーンに署名する前に、DNSSEC のしくみを理解しておく必要があります。 ゾーンに署名する準備ができたら、「DNSSEC を使用して Azure パブリック DNS ゾーンに署名する方法」を参照してください。

DNSSEC 検証

DNS サーバーが DNSSEC に対応している場合、DNS クエリの DNSSEC OK (DO) フラグを値 1 に設定できます。 この値は、応答側の DNS サーバーに、応答に DNSSEC 関連のリソース レコードを含むように指示します。 これらの DNSSEC レコードは、DNS 応答が正規のものであることを検証するために使用される Resource Record Signature (RRSIG) レコードです。

再帰 (非権威) DNS サーバーは、トラスト アンカー (DNSKEY) を使用して RRSIG レコードに対して DNSSEC 検証を実行します。 サーバーは DNSKEY を使用して RRSIG レコード (およびその他の DNSSEC 関連レコード) のデジタル署名の暗号化を解除し、ハッシュ値を計算して比較します。 ハッシュ値が同じ場合は、ホスト アドレスの (A) レコードなど、DNS クライアントが要求した DNS データを含めて DNS クライアントに応答します。 次の図を参照してください。

DNSSEC 検証のしくみを示す図。

ハッシュ値が同じでない場合、再帰 DNS サーバーは SERVFAIL メッセージで応答します。 このように、有効なトラスト アンカーがインストールされた DNSSEC 対応の解決 (または転送) DNS サーバーは、再帰サーバーと権威サーバーの間のパスにおける DNS ハイジャックから保護できます。 ローカル (最終ホップ) 再帰 DNS サーバー自体がハイジャックからセキュリティ保護されている場合、この保護では、DNS クライアント デバイスが DNSSEC に対応している必要も、DNS 応答検証を実施する必要もありません。

Windows 10 および Windows 11 クライアント デバイスは、非検証型セキュリティ対応スタブ リゾルバーです。 これらのクライアント デバイスは検証を実行しませんが、グループ ポリシーを使用して DNSSEC 検証を適用できます。 NRPT は、名前空間ベースの DNSSEC 検証ポリシーを作成および適用するために使用できます。

トラスト アンカーと DNSSEC 検証

Note

DNSSEC 応答の検証は、既定の Azure 提供のリゾルバーでは実行されません。 このセクションの情報は、DNSSEC 検証のために独自の再帰 DNS サーバーを設定する場合や、検証の問題をトラブルシューティングする場合に役立ちます。

トラスト アンカーは、DNS 名前空間階層に基づいて動作します。 再帰 DNS サーバーは、任意の数のトラスト アンカーを持つことも、トラスト アンカーを持たないことも可能です。 トラスト アンカーは、単一の子 DNS ゾーンまたは任意の親ゾーンに追加できます。 再帰 DNS サーバーにルート (.) トラスト アンカーがある場合は、任意の DNS ゾーンで DNSSEC 検証を実行できます。 詳細については、「ルート ゾーン オペレーター情報」を参照してください。

DNSSEC 検証プロセスは、トラスト アンカーに対して以下のように機能します。

  • 再帰 DNS サーバーにゾーンまたはゾーンの親階層名前空間に対する DNSSEC トラスト アンカーがない場合、そのゾーンでは DNSSEC 検証は実行されません。
  • 再帰 DNS サーバーにゾーンの親名前空間の DNSSEC トラスト アンカーがあり、子ゾーンのクエリを受け取った場合、子ゾーンの DS レコードが親ゾーンに存在するかどうかを確認します。
    • DS レコードが見つかった場合、再帰 DNS サーバーは DNSSEC 検証を実行します。
    • 再帰 DNS サーバーは、親ゾーンに子ゾーンの DS レコードがないと判断した場合、子ゾーンは安全でないとみなし、DNSSEC 検証を実行しません。
  • 複数の再帰 DNS サーバーが DNS 応答に関係している場合 (フォワーダーを含む)、信頼チェーンが途切れないように、各サーバーは応答に対して DNSSEC 検証を実行できる必要があります。
  • DNSSEC 検証が無効になっている、または DNSSEC に対応していない再帰サーバーは、検証を実行しません。

信頼チェーン

信頼チェーンは、DNS クエリに対する応答の送信に関与するすべての DNS サーバーが、応答が転送中に変更されていないことを検証できる場合に発生します。 DNSSEC 検証をエンド ツー エンドで機能させるには、信頼チェーンが途切れないようにする必要があります。 この信頼チェーンは、権威サーバーと非権威 (再帰) サーバーの両方に適用されます。

権威サーバー

権威 DNS サーバーは、Delegation Signer (DS) レコードを使用して信頼チェーンを維持します。 DS レコードは、DNS 階層内の子ゾーンの信頼性を検証するために使用されます。

  • 署名済みゾーンで DNSSEC 検証を行うには、署名済みゾーンの親も署名する必要があります。 親ゾーンは子ゾーンの DS レコードも持っている必要があります。
  • 検証プロセス中に、ゾーンの親に対して DS レコードの照会が行われます。 DS レコードが存在しない場合、または親の DS レコード データが子ゾーン内の DNSKEY データと一致しない場合、信頼チェーンが途切れ、検証が失敗します。

再帰サーバー

再帰 DNS サーバー (解決またはキャッシュ DNS サーバーとも呼ばれます) は、DNSSEC トラスト アンカーを使用して信頼チェーンを維持します。

  • トラスト アンカーは、DNSKEY レコード、または DNSKEY レコードのハッシュを含む DS レコードです。 DNSKEY レコードは、ゾーンが署名済みの場合は権威サーバー上に作成され、ゾーンが未署名の場合はゾーンから削除されます。
  • トラスト アンカーは、再帰 DNS サーバーに手動でインストールする必要があります。
  • 親ゾーンのトラスト アンカーが存在する場合、再帰サーバーは階層型名前空間内のすべての子ゾーンを検証できます。 これには転送されたクエリも含まれます。 すべての DNSSEC 署名済み DNS ゾーンの DNSSEC 検証をサポートするには、ルート (.) ゾーンのトラスト アンカーをインストールします。

キーのロールオーバー

DNSSEC 署名済みゾーンのゾーンを署名するキー (ZSK) は、Azure によって定期的にロールオーバーされます (置き換えられます)。 キーを署名するキー (KSK) を置き換える必要はありませんが、Microsoft サポートに連絡することでこのオプションを使用できます。 KSK を置き換える場合は、親ゾーンの DS レコードも更新する必要があります。

ゾーン署名アルゴリズム

ゾーンは、楕円曲線デジタル署名アルゴリズム (ECDSAP256SHA256) を使用して DNSSEC 署名されます。

次の表に DNSSEC 関連レコードの簡単な説明を示します。 詳細については、「RFC 4034: DNS セキュリティ拡張機能のリソース レコード」および「RFC 7344: DNSSEC 委任信頼のメンテナンスの自動化」を参照してください。

Record 説明
リソース レコードの署名 (RRSIG) 署名を保持するために使用される DNSSEC リソース レコードの種類。これは、特定の名前と種類の DNS レコードのセットをカバーします。
DNSKEY 公開キーを保存するために使用される DNSSEC リソース レコードの種類。
Delegation Signer (DS) 委任をセキュリティ保護するために使用される DNSSEC リソース レコードの種類。
Next Secure (NSEC) DNS 名が存在しないことを証明するために使用される DNSSEC リソース レコードの種類。
Next Secure 3 (NSEC3) DNS リソース レコード セットに対してハッシュ化された不在認証を提供する NSEC3 リソース レコード。
Next Secure 3 Parameter (NSEC3PARAM) NSEC3 レコードのパラメーターを指定します。
Child Delegation Signer (CDS) このレコードは省略可能です。 存在する場合、CDS レコードを子ゾーンで使用して、親ゾーンの DS レコードの必要な内容を指定できます。
Child DNSKEY (CDNSKEY) このレコードは省略可能です。 CDNSKEY レコードが子ゾーンに存在する場合、DNSKEY レコードから DS レコードを生成するために使用できます。

DNSSEC 関連のレコードは Azure portal には表示されません。 DNSSEC 関連のレコードを表示するには、Resolve-DnsName や dig.exe などのコマンド ライン ツールを使用します。 これらのツールは、Cloud Shell を使用するか、デバイスにインストールされている場合はローカルで利用できます。 Resolve-DnsName の -dnssecok オプションまたは dig.exe の +dnssec オプションを使用して、クエリに DO フラグを設定してください。

重要

nslookup.exe コマンド ライン ツールを使用して DNSSEC 関連のレコードを照会しないでください。 nslookup.exe ツールは、DNSSEC 非対応の内部 DNS クライアントを使用します。

次の例を参照してください。

PS C:\> resolve-dnsname server1.contoso.com -dnssecok

Name                                      Type   TTL   Section    IPAddress
----                                      ----   ---   -------    ---------
server1.contoso.com                        A     3600  Answer     203.0.113.1

Name        : server1.contoso.com
QueryType   : RRSIG
TTL         : 3600
Section     : Answer
TypeCovered : A
Algorithm   : 13
LabelCount  : 3
OriginalTtl : 3600
Expiration  : 9/20/2024 11:25:54 PM
Signed      : 9/18/2024 9:25:54 PM
Signer      : contoso.com
Signature   : {193, 20, 122, 196…}

C:\>dig server1.contoso.com +dnssec

; <<>> DiG 9.9.2-P1 <<>> server1.contoso.com +dnssec
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 61065
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 512
;; QUESTION SECTION:
;server1.contoso.com.       IN      A

;; ANSWER SECTION:
server1.contoso.com. 3600   IN      A       203.0.113.1
server1.contoso.com. 3600   IN      RRSIG   A 13 3 3600 20240920232359 20240918212359 11530 contoso.com. GmxeQhNk1nJZiep7nuCS2qmOQ+Ffs78Z2eoOgIYP3j417yqwS1DasfA5 e1UZ4HuujDk2G6GIbs0ji3RiM9ZpGQ==

;; Query time: 153 msec
;; SERVER: 192.168.1.1#53(192.168.1.1)
;; WHEN: Thu Sep 19 15:23:45 2024
;; MSG SIZE  rcvd: 179

PS C:\> resolve-dnsname contoso.com -Type dnskey -dnssecok

Name                                 Type   TTL   Section    Flags  Protocol Algorithm      Key
----                                 ----   ---   -------    -----  -------- ---------      ---
contoso.com                          DNSKEY 3600  Answer     256    DNSSEC   13             {115, 117, 214,
                                                                                                165…}
contoso.com                          DNSKEY 3600  Answer     256    DNSSEC   13             {149, 166, 55, 78…}
contoso.com                          DNSKEY 3600  Answer     257    DNSSEC   13             {45, 176, 217, 2…}

Name        : contoso.com
QueryType   : RRSIG
TTL         : 3600
Section     : Answer
TypeCovered : DNSKEY
Algorithm   : 13
LabelCount  : 2
OriginalTtl : 3600
Expiration  : 11/17/2024 9:00:15 PM
Signed      : 9/18/2024 9:00:15 PM
Signer      : contoso.com
Signature   : {241, 147, 134, 121…}

C:\>dig contoso.com dnskey

; <<>> DiG 9.9.2-P1 <<>> contoso.com dnskey
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 46254
;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;contoso.com.               IN      DNSKEY

;; ANSWER SECTION:
contoso.com.        3600    IN      DNSKEY  256 3 13 laY3Toc/VTyjupgp/+WgD05N+euB6Qe1iaM/253k7bkaA0Dx+gSDhbH2 5wXTt+uLQgPljL9OusKTneLdhU+1iA==
contoso.com.        3600    IN      DNSKEY  257 3 13 LbDZAtjG8E9Ftih+LC8CqQrSZIJFFJMtP6hmN3qBRqLbtAj4JWtr2cVE ufXM5Pd/yW+Ca36augQDucd5n4SgTg==
contoso.com.        3600    IN      DNSKEY  256 3 13 c3XWpTqZ0q9IO+YqMEtOBHZSzGGeyFKq0+3xzs6tifvD1rey1Obhrkz4 DJlEIxy2m84VsG1Ij9VYdtGxxeVHIQ==

;; Query time: 182 msec
;; SERVER: 192.168.1.1#53(192.168.1.1)
;; WHEN: Thu Sep 19 16:35:10 2024
;; MSG SIZE  rcvd: 284

DNSSEC の用語

この一覧は、DNSSEC について説明するときに使用されるいくつかの一般的な用語を理解するのに役立ちます。 「DNSSEC 関連のリソース レコード」も参照してください。

用語 説明
認証済みデータ (AD) ビット 応答の回答セクションと権限セクションに含まれるすべてのデータが、DNS サーバーのポリシーに従ってそのサーバーによって認証されたことを応答内に示すデータ ビット。
認証チェーン 事前構成済みのトラスト アンカーから DNS ツリー内の一部の子ゾーンまで拡張される、署名および検証済みの DNS レコードのチェーン。
DNS 拡張機能 (EDNS0) DO ビットや最大 UDP パケット サイズなどの拡張 DNS ヘッダー情報を保持する DNS レコード。
DNS セキュリティ拡張機能 (DNSSEC) DNS データの署名と安全な解決のメカニズムを提供する DNS サービスの拡張機能。
DNSSEC OK (DO) ビット クライアントが DNSSEC 対応であることを通知する DNS 要求の EDNS0 部分にあるビット。
DNSSEC 検証 DNSSEC 検証は、公開暗号化キーを使用して DNS データの配信元と整合性を検証するプロセスです。
セキュリティの島 委任元の親ゾーンからの認証チェーンを持たない署名済みゾーン。
キーを署名するキー (KSK) 特定のゾーンの 1 つ以上の他の署名キーに署名するために使用される秘密キーに対応する認証キー。 通常、KSK に対応する秘密キーはゾーンを署名するキー (ZSK) に署名します。これには、他のゾーン データに署名する、対応する秘密キーがあります。 ローカル ポリシーでは、ZSK を頻繁に変更する必要がある一方で、ゾーンへのより安定した安全なエントリ ポイントを提供するために、KSK の有効期間を長くすることができます。 認証キーを KSK として指定することは、純粋に運用上の問題です。DNSSEC 検証では、KSK と他の DNSSEC 認証キーは区別されません。 1 つのキーを KSK と ZSK の両方として使用することも可能です。
非検証型セキュリティ対応スタブ リゾルバー 1 つ以上のセキュリティ対応 DNS サーバーを信頼して、代わりに DNSSEC 検証を実行するセキュリティ対応スタブ リゾルバー。
セキュリティで保護されたエントリ ポイント (SEP) キー DNSKEY RRSet 内の公開キーのサブセット。 SEP キーは、DS RR を生成するために使用されるか、キーをトラスト アンカーとして使用するリゾルバーに配布されます。
セキュリティ対応 DNS サーバー RFC 4033 [5]、4034 [6]、および 4035 [7] で定義されている DNS セキュリティ拡張機能を実装する DNS サーバー。 特に、セキュリティ対応 DNS サーバーは、DNS クエリを受信し、DNS 応答を送信し、EDNS0 [3] メッセージ サイズ拡張と DO ビットをサポートし、DNSSEC レコードの種類とメッセージ ヘッダー ビットをサポートするエンティティです。
署名済みゾーン RFC 4035 [7] セクション 2 で定義されているとおり、レコードが署名されているゾーン。 署名済みゾーンには、DNSKEY、NSEC、NSEC3、NSEC3PARAM、RRSIG、および DS リソース レコードを含めることができます。 これらのリソース レコードを使用すると、DNS データをリゾルバーで検証できます。
トラスト アンカー 特定のゾーンに関連付けられている事前構成済みの公開キー。 トラスト アンカーを使用すると、DNS リゾルバーはそのゾーンの署名済み DNSSEC リソース レコードを検証し、子ゾーンへの認証チェーンを構築できます。
未署名ゾーン RFC 4035 [7] セクション 2 で定義されているとおり、署名されていない DNS ゾーン。
ゾーンの署名 ゾーン署名は、DNSSEC 関連のリソース レコードを作成してゾーンに追加して、DNSSEC 検証と互換性を持たせるプロセスです。
ゾーン署名の削除 ゾーン署名の削除は、ゾーンから DNSSSEC 関連のリソース レコードを削除して、未署名の状態に復元するプロセスです。
ゾーンを署名するキー (ZSK) ゾーンに署名するために使用される秘密キーに対応する認証キー。 通常、ゾーンを署名するキーはキーを署名するキーと同じ DNSKEY RRSet の一部であり、対応する秘密キーがこの DNSKEY RRSet に署名しますが、ゾーンを署名するキーは少し異なる目的で使用され、有効期間などを他の方法でキーを署名するキーとは別に制御できます。 認証キーをゾーンを署名するキーとして指定することは、純粋に運用上の問題です。DNSSEC 検証では、ゾーンを署名するキーと他の DNSSEC 認証キーは区別されません。 1 つのキーをキーを署名するキーとゾーンを署名するキーの両方として使用することも可能です。

次のステップ