DNSSEC を使用して DNS 応答を検証してセキュリティで保護する

2025-02-24
適用対象: ✅ Windows Server 2025, ✅ Windows Server 2022, ✅ Windows Server 2019, ✅ Windows Server 2016

DNSSEC リソースレコードは、DNS 応答の検証とセキュリティ保護に使用されます。 DNS ゾーンは、ゾーン署名によって DNSSEC で保護されます。ゾーンに署名すると、DNS クエリと応答の基本的なメカニズムを変更することなく、検証のサポートが追加されます。 Windows Server での DNS Server の DNSSEC の概要については、「DNSSECの概要」を参照してください。

デジタル署名は、検証を提供するために DNS 応答に含まれています。これらのデジタル署名は、ゾーン署名中に生成され、ゾーンに追加される DNSSEC 関連のリソースレコードに含まれています。

再帰型DNS

DNSSEC 対応の再帰または転送 DNS サーバーが DNSSEC 署名済みゾーンの DNS クライアントからクエリを受信すると、DNSSEC レコードを送信して DNS 応答を検証するように権限のある DNS サーバーに要求します。再帰 DNS サーバーまたは転送 DNS サーバーは、ゾーンがそのゾーンの DNSKEY (トラストアンカーとも呼ばれます) を持っている場合に DNSSEC をサポートすることを認識します。

大事な

権限のない DNS サーバーでは、再帰または転送を使用して DNS クエリを解決する場合があります。このトピックでは、権限のないサーバーを再帰 DNS サーバーと呼びます。サーバーが転送を使用する場合、DNS 応答の DNSSEC 検証に使用されるプロセスは同じです。

DNSKEYの

再帰 DNS サーバーは、DNSKEY リソースレコードを使用して、権限のある DNS サーバーからの応答を検証します。応答を検証するために、DNS サーバーは DNSSEC 関連のリソースレコードに含まれるデジタル署名を復号化し、ハッシュ値を比較します。ハッシュ値が同一の場合は、要求した DNS データ (ホスト (A) リソースレコードなど) を使用して DNS クライアントに応答します。ハッシュ値が一致しない場合は、SERVFAIL メッセージで応答します。このように、DNSSEC 対応の有効なトラストアンカーがインストールされた DNS サーバーを解決すると、DNS クライアントが DNSSEC に対応しているかどうかに関係なく、DNS スプーフィング攻撃から保護されます。

DNS クライアントが DNSSEC に対応している場合は、DNS サーバーが DNSSEC 検証を実行するように構成できます。

次の図は、検証プロセスを示しています。

DNSSEC 検証プロセスの概要を示す図。

DNSKEY は、ハッシュ値の計算と RRSIG レコードの暗号化解除に使用されます。この図には、実行されたすべての検証プロセスが表示されるわけではありません。 DNSKEY が有効であり、DS レコードが存在する場合は有効であることを確認するために、さらに検証が実行されます (スクリーンショットには示されていません)。

DNS クエリと応答プロセス

簡単な例は、DNSSEC を DNS クエリと応答プロセスに組み込んで検証を提供する方法を示しています。

次の例では、DNS クライアントコンピューターが再帰 (キャッシュ) DNS サーバーに対してクエリを実行し、応答を返す前に権限のある DNS サーバーにクエリを実行します。この例では、DNS データがまだクライアントまたはサーバーにキャッシュされていないことを前提としています。 DNSSEC データは、ゾーンが署名されていて、DNSSEC 対応のサーバーとクライアントを使用している場合にのみ、DNS 応答を本物として検証します。

次の図は、再帰 DNS クエリプロセスを示しています。

次の表に示すように、再帰 DNS クエリプロセスを示す図。

次の表は、オプションの DNSSEC データを使用した DNS クエリと応答の手順を示しています。

ステップ	クエリ応答	オプションの DNSSEC データ
1	DNS クライアントは、再帰 DNS サーバーに DNS クエリを送信します。	DNS クライアントは、DNSSEC 対応 (`DO=1`) であることを示すことができます。
2	再帰 DNS サーバーは、ルートおよび最上位ドメイン (TLD) DNS サーバーに DNS クエリを送信します。	再帰 DNS サーバーは、DNSSEC 対応 (`DO=1`) であることを示すことができます。
3	ルートサーバーと TLD サーバーは、ゾーンの権限のある DNS サーバーの IP アドレスを提供する再帰 DNS サーバーに DNS 応答を返します。	親ゾーンの権限のあるサーバーは、子ゾーンが DNSSEC を使用して署名され、セキュリティで保護された委任 (DS レコード) が含まれていることを示すことができます。
4	再帰 DNS サーバーは、ゾーンの権限のある DNS サーバーに DNS クエリを送信します。	再帰 DNS サーバーは、DNSSEC 対応 (`DO=1`) であり、応答で送信される署名付きリソースレコード (`CD=1`) を検証できることを示すことができます。
5	権限のある DNS サーバーは、リソースレコードデータを提供して、再帰 DNS サーバーに DNS 応答を返します。	権限のある DNS サーバーは、検証で使用するために、DNS 応答に RRSIG レコードの形式で DNSSEC 署名を含めることができます。
6	再帰 DNS サーバーは DNS クライアントに DNS 応答を返し、リソースレコードデータを提供します。	再帰 DNS サーバーは、DNSSEC を使用して DNS 応答が検証された (`AD=1`) かどうかを示すことができます。

DNSSEC データを含む

DNSSEC 関連のフラグ (ビット) は、DNSSEC データが含まれているかどうかを判断するために DNS クエリと応答で使用され、検証が実行されました。これらのフラグは、DNS パケットヘッダーで拡張データビットをオンまたはオフにすることで設定されます。フラグをオンにすると、「ビットを設定する」と呼ばれます（値は1に設定されます）。フラグをオフにすることは、ビットを "クリア" と呼びます (値は 0 に設定されます)。

DO: DO ビットは DNS クエリに含まれており、"DNSSEC OK" の省略形です。 DO ビットが (DO=1) 設定されている場合、クライアントは DNSSEC 対応であり、DNS サーバーが応答で DNSSEC データを返しても安全です。 DO ビットが設定されていない (DO=0) 場合、クライアントは DNSSEC 対応ではなく、DNS サーバーは DNS 応答に DNSSEC データを含めることはできません。 DNS クライアントは、DNSSEC に対応していない場合でも、DNSSEC を使用して保護できます。このコンテキストでは、DNS クライアントは DNS クエリを送信する任意のコンピューターです。再帰 DNS サーバーが権限のある DNS サーバーにクエリを送信する場合、再帰 DNS サーバーは、権限のある DNS サーバーが応答で DNSSEC データを送信するように DNSSEC 対応であることを示す必要があります。
AD: AD ビットは DNS 応答に含まれており、"認証済みデータ" の省略形です。 AD ビットが (AD=1) 設定されている場合は、DNSSEC を使用して検証されたため、DNS 応答が本物であることを意味します。 Windows 8 を実行しているコンピューターなど、有効でない DNSSEC 対応コンピューターは DNSSEC 検証を実行しませんが、DNS 応答が本物であることを要求するように構成できます。 AD ビットが設定されていない場合 (AD=0)、DNS 応答は検証されませんでした。 AD ビットは、検証が試行されなかったか、検証が失敗したために設定されない可能性があります。
CD: CD ビットは DNS クエリに含まれており、"無効のチェック" の省略形です。 CD ビットがクエリで (CD=1) 設定されている場合は、検証が正常に実行されたかどうかにかかわらず、DNS 応答を送信する必要があることを意味します。 CD ビットが設定されていない場合 (CD=0)、検証が必要で失敗した場合、DNS 応答は送信されません。 CD ビットがクリア (CD=0) の場合、これは "有効なチェック" を意味し、DNSSEC 検証が行われる可能性があります。ホストは DNSSEC 検証を実行でき、Windows Server 2012 以降を実行する再帰 DNS サーバーなどのアップストリーム検証を必要としないため、CD ビットがクエリに設定 (CD=1) される可能性があります。 Windows DNS クライアントを実行しているコンピューターなどの非検証スタブリゾルバーは、CD ビットがクリアされた CD=0でクエリを発行します。詳細については、RFC4035、セクション 3.2.2を参照してください。

DNS パケットヘッダーに存在できる 4 番目の重要なフラグ (ビット) は AA ビットです。このフラグは DNSSEC では新しいものではなく、DNSSEC のデプロイ時に使用できます。

AA: AA ビットは DNS 応答に含まれており、"権限のある回答" の省略形です。 AA ビットが設定されている場合は、権限のある DNS サーバーから直接送信された DNS 応答が本物であることを意味します。 DNSSEC 検証を必要とするクライアント (AD=1) は、代わりに AA ビット (AA=1、AD=0) を受け入れます。権限のある応答を検証する必要がないため、クライアントが権限のあるサーバーに直接クエリを実行する場合。権限のあるサーバーが独自の応答を検証するのは冗長です。

DNS クエリの例

次の例では、Resolve-DnsName コマンドレットを使用して、Windows 8.1 を実行している DNS クライアントコンピューターから実行される DNS クエリの結果を表示します。 Resolve-DnsName コマンドレットは、Windows Server 2012 および Windows 8 で導入され、DNSSEC データを含む DNS クエリを表示するために使用できます。

大事な

ゾーンの DNSSEC サポートをテストするには、nslookup.exe コマンドラインツールを使用しないでください。 nslookup.exe ツールは、DNSSEC に対応していない内部 DNS クライアントを使用します。

例 1: 次の例では、を使用して署名済みゾーン DO=0 のアドレス (A) レコードのクエリが再帰 DNS サーバーに送信されます。

Resolve-DnsName finance.secure.contoso.com –type A -server dns1.contoso.com


Name Type TTL Section IPAddress

---- ---- --- ------- ---------

finance.secure.contoso.com A 2848 Answer 192.168.0.200

dnssecok パラメーターが含まれていないため、DO ビットが設定されていません。

例 2: 次の例では、DO=1 パラメーターを追加して、フラグを設定します。

Resolve-DnsName -name finance.secure.contoso.com -type A -server dns1.contoso.com -dnssecok

Name Type TTL Section IPAddress

---- ---- --- ------- ---------

finance.secure.contoso.com A 2848 Answer 192.168.0.200

Name : finance.secure.contoso.com

QueryType : RRSIG

TTL : 2848

Section : Answer

TypeCovered : A

Algorithm : 8

LabelCount : 4

OriginalTtl : 3600

Expiration : 10/18/2013 8:23:41 PM

Signed : 10/8/2013 7:23:41 PM

Signer : secure.contoso.com

Signature : {86, 229, 217, 39...}

Name : .

QueryType : OPT

TTL : 32768

Section : Additional

Data : {}

DO=0すると、DNS サーバーは DNS 応答で DNSSEC データを送信しません。 DO=1すると、クライアントは DNSSEC データ (使用可能な場合) を受信できることを示します。 secure.contoso.com ゾーンは署名されているため、DO=1するときに RRSIG リソースレコードが DNS 応答に含まれていました。

例 1 と例 2 の両方で、名前解決ポリシーテーブル (NRPT) が検証を必要とするように構成されていないため、secure.contoso.com ゾーンの検証は必要ありません。

Get-DnsClientNrptPolicy コマンドレットを使用して、現在の NRPT 規則を表示できます。詳細については、の Get-DnsClientNrptPolicyを参照してください。

例 3: 次の例では、secure.contoso.comの NRPT ルールが表示されます。

Get-DnsClientNrptPolicy

Namespace : .secure.contoso.com

QueryPolicy :

SecureNameQueryFallback :

DirectAccessIPsecCARestriction :

DirectAccessProxyName :

DirectAccessDnsServers :

DirectAccessEnabled :

DirectAccessProxyType : NoProxy

DirectAccessQueryIPsecEncryption :

DirectAccessQueryIPsecRequired : False

NameServers :

DnsSecIPsecCARestriction :

DnsSecQueryIPsecEncryption :

DnsSecQueryIPsecRequired : False

DnsSecValidationRequired : False

NameEncoding : Utf8WithoutMapping

この例では、DnsSecValidationRequired の値は Falseです。値が false の場合、DNSSEC 検証は必要ありません。

例 4: secure.contoso.comに対して DNSSEC 検証が有効になっている場合、NRPT では、DnsSecValidationRequiredの True が表示されます。この例では、secure.contoso.com 名前空間と、DnsSecValidationRequired パラメーターのみを表示します。

(Get-DnsClientNrptPolicy -NameSpace secure.contoso.com).DnsSecValidationRequired

True

DnsSecValidationRequired の値が True 場合、DNSSEC 対応のクライアントコンピューターは、DO=1 パラメーターが含まれていない場合でも、常にを使用してクエリを送信します。

例 5: 名前解決ポリシーテーブル (NRPT) で DNSSEC 検証が必要な場合、DNSSEC 対応クライアントに対して DNSSEC OK ビットが自動的に設定 (DO=1) されます。

Resolve-DnsName -name finance.secure.contoso.com -type A -server dns1.contoso.com

Name Type TTL Section IPAddress

---- ---- --- ------- ---------

finance.secure.contoso.com A 2848 Answer 192.168.0.200

Name : finance.secure.contoso.com

QueryType : RRSIG

TTL : 2848

Section : Answer

TypeCovered : A

Algorithm : 8

LabelCount : 4

OriginalTtl : 3600

Expiration : 10/18/2013 8:23:41 PM

Signed : 10/8/2013 7:23:41 PM

Signer : secure.contoso.com

Signature : {86, 229, 217, 39...}

Name : .

QueryType : OPT

TTL : 32768

Section : Additional

Data : {}

この例では、secure.contoso.comの検証要件を満たすために、DNS 応答で RRSIG レコードが送信されます。有効なトラストアンカーは、再帰 DNS サーバー dns1.contoso.comでも構成されます。

DNS クライアントが DNSSEC に対応していない場合、NRPT 規則は適用されず、DNSSEC 検証を必要とする NRPT 規則が存在する場合でも、クエリは DO=0で送信されます。

例 6: 次の例では、例 5 と同じクエリが実行されますが、有効なトラストアンカーは dns1.contoso.comに構成されません。

Resolve-DnsName -name finance.secure.contoso.com -type A -server dns1.contoso.com

Resolve-DnsName : finance.secure.contoso.com : Unsecured DNS packet

At line:1 char:1

+ Resolve-DnsName -name finance.secure.contoso.com -type A -server dns1.contoso.co ...

+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

+ CategoryInfo : ResourceUnavailable: (finance.secure.contoso.com:String) [Resolve-DnsName], Win32Excepti

on

+ FullyQualifiedErrorId : DNS\_ERROR\_UNSECURE\_PACKET,Microsoft.DnsClient.Commands.ResolveDnsName

この例では、DNS 解決はメッセージ DNS_ERROR_UNSECURE_PACKETで失敗します。 NRPT では検証が必要ですが、ゾーン secure.contoso.comの有効なトラストアンカーがないため、解決は失敗します。 Resolve-DnsName コマンドレットは、発生したエラーの種類の詳細な結果を報告します。 DNS クライアントがこのホストに接続するために finance.secure.contoso.com を解決しようとすると、失敗します。

DNSSEC シナリオ

DNSSEC は、一意のサーバーとクライアント設定を使用してさまざまな環境に展開できます。DNS クエリと応答がどのように影響を受けるかを理解することが重要です。

次の 4 つの DNSSEC 関連ステートメントについて考えてみましょう。各ステートメントは、特定のシナリオでの DNSSEC の動作に影響します。

finance.secure.contoso.com リソースレコードは DNSSEC で正しく署名されています。
再帰 DNS サーバーは、finance.secure.contoso.comのクエリに対する応答を検証できます。
DNS クライアントは DNSSEC 対応です。
DNS クライアントは、secure.contoso.com 名前空間内のすべてのクエリの検証を要求するように構成されています。

これら 4 つのステートメントのそれぞれについて詳しく考えてみましょう。

DNSSEC 署名の状態 : DNSSEC はゾーン内のすべてのレコードに署名します。この条件は、secure.contoso.com リソースレコードだけでなく、finance.secure.contoso.com ゾーンの状態を指します。一部のレコードには署名できて、他のレコードには署名できないということはできません。したがって、finance.secure.contoso.com の DNSSEC ステータスは、secure.contoso.comの DNSSEC ステータスによって異なります。
- 正しく署名された: secure.contoso.com ゾーンは、有効な方法でサインインできるため、finance.secure.contoso.com を正規のものとして検証できます。有効にするには、ゾーンに有効な期限切れキーを使用して署名する必要があり、必要なすべての DNSSEC 関連のリソースレコードが存在する必要があります。
- 署名されていない: secure.contoso.com ゾーンが署名されていない可能性があります。その場合、finance.secure.contoso.comに関連付けられている RRSIG レコードがなく、finance.secure.contoso.com のクエリに対する DNS 応答を検証できません。クライアントが検証を必要とする場合、再帰 DNS サーバーに送信される DNS クエリは失敗します。DNS クライアントは、未検証の応答を受け入れないためです。クライアントが権限のあるサーバーに直接クエリを実行した場合、応答は既に本物と見なされているため、検証は失敗しません。
- 正しく署名されていない: secure.contoso.com ゾーンは署名されている可能性がありますが、有効な方法ではありません。たとえば、1 つ以上の DNSSEC 署名キーの有効期限が切れている可能性があります。ゾーンに最初に署名した後は、セキュリティで保護された DNSSEC 操作状態を維持するために、署名キーの有効期間が切れる前に、ゾーンに新しいキーを使用して定期的に再署名する必要があります。 DNSSEC 署名キーの有効期間は、セキュリティを維持するのに十分な短さである必要がありますが、管理が容易になるのに十分な長さである必要があります。 Windows Server 2012 および Windows Server 2012 R2 の DNSSEC では、自動キーロールオーバーがサポートされており、DNSSEC 署名付きゾーンのセキュリティと管理の容易さの両方が提供されます。
検証状態: secure.contoso.com ゾーンの有効なトラストアンカー (公開暗号化キー) を持つ再帰 DNS サーバーは、finance.secure.contoso.com リソースレコードの DNS 応答を検証できます。再帰 DNS サーバーは、ゾーンへの署名に使用される DNSSEC 標準とアルゴリズムもサポートする必要があります。
- を検証できます:再帰 DNS サーバーが、secure.contoso.com ゾーンへの署名に使用されるすべての暗号アルゴリズムをサポートしており、署名されたリソースレコードに関連付けられている DNSSEC 署名の暗号化解除に使用できる有効なトラストアンカーがある場合は、finance.secure.contoso.com リソースレコードを正規のものとして検証できます。
- を検証できません:DNSSEC に対応していない DNS サーバーは検証できません。同様に、現在ゾーン secure.contoso.comの有効なトラストアンカーがない DNS サーバーでは、finance.secure.contoso.comの DNS 応答を検証することはできません。ゾーンが再署名されるとき、たとえばキーのロールオーバー中などに、トラストアンカーを更新する必要があります。 Windows Server 2012 および Windows Server 2012 R2 の DNSSEC では、RFC 5011 "DNS セキュリティ (DNSSEC) トラストアンカーの自動更新" に基づき、キーロールオーバー時にトラストアンカーの自動更新がサポートされています。
DNSSEC 対応の状態: DNS クライアントの DNSSEC 対応の状態は、実行されているオペレーティングシステムによって異なります。 Windows 7 または Windows Server 2008 R2 以降のオペレーティングシステムの Windows DNS クライアントサービスは、DNSSEC 対応の非検証スタブリゾルバーです。以前の Windows オペレーティングシステムは、DNSSEC 対応ではありません。 DNS クライアントは、DNS クエリを送信するときに DNSSEC に対応しているかどうかを DNS サーバーに通知します。
- クライアントとサーバーの両方が DNSSEC 対応のです。クライアントとサーバーの両方が DNSSEC 対応の場合、サーバーからクライアントへの DNS 応答には、DNSSEC 認証データ (AD) フラグが含まれます。 DNSSEC で DNS 応答が検証されると、AD=1 が送信されます。 DNS 応答が検証されなかった場合は、AD=0 が送信されます。
- DNS サーバーが DNSSEC 対応のではない: DNS サーバーが DNSSEC 対応でない場合、検証は実行されず、DNS クライアントが DNSSEC に対応しているかどうかに関係なく、AD フラグが設定 (AD=0) されません。
- DNS クライアントが DNSSEC 対応のではない: DNS クライアントが DNSSEC に対応していない場合、DNS サーバーは DNSSEC を認識していても、クライアントへの応答で AD フラグを設定しません。ただし、DNS サーバーが DNSSEC 対応で、ゾーンのトラストアンカーがある場合、サーバーは権限のあるサーバーからの応答を検証しようとします。検証に失敗すると、DNS サーバーのエラーが DNS クライアントに返されます。検証が成功すると、クエリ結果がクライアントに返されます。この方法では、DNSSEC 対応の再帰 DNS サーバーは、DNSSEC に対応していない DNS クライアントを保護できます。このシナリオでは、ゾーンが署名されていない場合、検証は試行されず、応答は通常どおりクライアントに返されます。
検証要件の: この設定により、DNS サーバーからの応答における DNSSEC データ (AD フラグ) に対する DNSSEC 対応 DNS クライアントの要件が決定されます。 DNS クライアントが検証を必要とするためには、DNSSEC に対応している必要があります。 DNSSEC に対応していない DNS クライアントは、DNSSEC 検証を強制することはできません。 DNS クライアントが権限のある DNS サーバーに直接クエリを実行している場合、ゾーンが署名されていない場合でも、応答が検証されます。これは、権限のある DNS サーバーが常に本物の応答を返すからです。
- 検証が必要: 検証が必要な場合、クライアントは AD=1 を受け取る必要があります (検証が成功しました)、または DNS 応答を拒否します。検証が失敗した場合、または試行されなかった場合 (AD=0)、DNS 解決は失敗します。これは、ゾーンが署名されていない場合でも当てはまります。これは、再帰的で不正な DNS サーバーに対するクエリにのみ適用されます。
- 検証は必要ありません: 検証が必要ない場合、クライアントは DNSSEC 対応ではない再帰 DNS サーバーからの応答を受け入れます。ただし、再帰 DNS サーバーが DNSSEC に対応していて検証が失敗した場合、クライアントが検証を必要としない場合でも、サーバーのフェールオーバーがクライアントに返されます。

次の手順

DNS サーバーの DNSSEC の詳細については、次の記事を参照してください。