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

[アーティクル]
06/16/2023

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

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

再帰 DNS

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

重要

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

DNSKEY

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

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

この検証プロセスを次の図に示します。

Diagram showing a summary of the DNSSEC validation process.

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

DNS クエリと応答プロセス

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

次の例では、DNS クライアントコンピューターは再帰 (キャッシュ) DNS サーバーを照会します。さらに、再帰 DNS サーバーは、権威 DNS サーバーに照会してから応答を返します。この例では、クライアントまたはサーバーで、まだ DNS データがキャッシュされていないことを想定しています。 DNSSEC データが DNS 応答を正規として検証するのは、ゾーンが署名されていて、DNSSEC 対応のサーバーとクライアントを使用している場合のみです。

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

Diagram showing the recursive DNS query process as summarized in the following table.

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

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

DNSSEC データを含める

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

DO: DO ビットは DNS クエリに含まれます。DO とは "DNSSEC OK" の省略形です。 DO ビットがセットされている (DO=1) 場合、クライアントは DNSSEC 対応であり、DNS サーバーが応答で DNSSEC データを返しても問題ありません。 DO ビットがセットされていない (DO=0) 場合、クライアントは DNSSEC 非対応であり、DNS サーバーは DNS 応答に DNSSEC データを含めることができません。 DNS クライアントが DNSSEC 非対応の場合でも、DNS クライアントを引き続き DNSSEC を使用して保護できます。この状況では、DNS クライアントは、DNS クエリを送信する任意のコンピューターです。再帰 DNS サーバーは、権威 DNS サーバーにクエリを送信する場合、DNSSEC 対応であることを示す必要があります。この結果、権威 DNS サーバーが応答で DNSSEC データを送信します。
AD: AD ビットは DNS 応答に含まれます。AD とは "authenticated data (認証されたデータ)" の省略形です。 AD ビットがセットされている (AD=1) 場合は、DNS 応答が DNSSEC を使用して検証されており、認証済みであることを意味します。 Windows 8 を実行しているコンピューターなど、検証に対応していない DNSSEC 対応コンピューターは、DNSSEC 検証を実行しません。ただし、DNS 応答が認証済みであることを要求するよう構成できます。 AD ビットが設定されていない (AD=0) 場合、DNS 応答は検証されませんでした。検証が試行されなかったか、検証に失敗したために、AD ビットが設定されない場合があります。
CD: CD ビットは DNS クエリに含まれます。CD とは "checking disabled (確認が無効)" の省略形です。クエリに CD ビットがセットされている (CD=1) 場合は、検証が正常に実行されているかどうかに関係なく、DNS 応答を送信する必要があります。 CD ビットがセットされていない (CD=0) 場合、検証が要求されて、失敗していたときは、DNS 応答は送信されません。 CD ビットがクリアされている (CD=0) 場合、これは "確認が有効" という意味であり、DNSSEC 検証を行うことができます。 CD ビットはクエリでセットされている (CD=1) 場合があります。これは、ホストが Windows Server 2012 以降を実行する再帰 DNS サーバーなどの DNSSEC 検証を実行できるためです。 Windows DNS クライアントを実行するコンピューターなど、検証に対応していないスタブリゾルバーは、常に CD=0 を設定します。

DNS のパケットヘッダーに設定できる 4 つ目の重要なフラグ (ビット) は、AA ビットです。このフラグは、DNSSEC では新しいものではありませんが、DNSSEC の展開時に使用することができます。

AA: AA ビットは DNS 応答に含まれます。AA とは "authoritative answer (権限のある回答)" の省略形です。 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 クエリを表示するために使用できます。

重要

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

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

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: 次の例では、dnssecok パラメーターを追加することで、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 である場合、dnssecok パラメーターが含まれていなくても、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 : {}

この例では、RRSIG レコードが DNS 応答で送信され、secure.contoso.com の検証の要件を満たします。有効なトラストアンカーも、再帰 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 は、ゾーン内のすべてのレコードに署名し、この条件は finance.secure.contoso.com リソースレコードの状態だけではなく、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 対応状態は、DNS クライアントが実行しているオペレーティングシステムによって異なります。 Windows 7 または Windows Server 2008 R2 以降のオペレーティングシステムの Windows DNS クライアントサービスは、DNSSEC 対応で、検証に対応していないスタブリゾルバーです。以前の Windows オペレーティングシステムは、DNSSEC 非対応です。 DNS クライアントは、DNS クエリを送信するときに、DNS サーバーに DNSSEC 対応であるかどうかを通知します。
- クライアントとサーバーの両方が 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 クライアントが検証を要求するには、DNS クライアントは DNSSEC 対応である必要があります。 DNSSEC 非対応の DNS クライアントから、強制的に DNSSEC 検証を要求することはできません。 DNS クライアントが、権威 DNS サーバーを直接照会する場合、ゾーンが署名されていない場合でも、応答は検証されます。これは、権威 DNS サーバーは常に認証済みの応答を返すためです。
- 検証が必要: 検証が必要な場合、クライアントは AD=1 (検証に成功) を受け取る必要があります。そうでない場合は、DNS の応答を拒否します。検証が失敗したか、試行されなかった場合 (AD=0) は、DNS 解決は失敗します。これは、ゾーンが署名されていない場合でも当てはまります。これは、非権威再帰 DNS サーバーに対するクエリにのみ適用されます。
- 検証が不要: 検証が不要な場合、クライアントは、DNSSEC 非対応の再帰 DNS サーバーからの応答を受け入れます。ただし、再帰 DNS サーバーが DNSSEC 対応で、検証が失敗する場合、クライアントに検証が必要ない場合でも、そのサーバーはクライアントにサーバーのフェールオーバーを返します。

次のステップ

DNS サーバーの DNSSEC の詳細に関する記事をいくつか次に示します。

Share via