Skip to main content
Resources

最新のトラストアンカーによるDNS検証リゾルバの更新

このページは以下の言語でもご覧いただけます。

このページは、DNSリゾルバ(再帰リゾルバともいいます)の管理者を対象にしています。この情報は、次のいずれかの場合に役立ちます。

  • 新しいKSKがインストールされていない場合
  • KSKロールオーバー後にすべてのDNS要求でエラーが発生した場合

ここで説明する操作を行うことで、DNSSEC検証で最新のトラストアンカーを使用できます。

最新のトラストアンカーを使用しているかどうかを確認する方法は別の文書で説明しています。詳細については、こちらをご覧ください。KSKロールオーバーの詳細については、こちらをご覧ください。

Comcastがパブリックサービスとして運用している特別なドメイン「dnssec-failed.org」を使用すると、リゾルバがDNSSEC検証を行うかどうかをテストできます。このドメインでは、検証を行うリゾルバが応答を返さない設定になっています。シェルコマンドラインで次のコマンドを入力します。

dig @ADDRESS dnssec-failed.org a +dnssec

このコマンドで、ADDRESSは、使用するリゾルバのIPv4またはIPv6アドレスで置き換えます。

応答に次のものが含まれている場合:

;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL

リゾルバがDNSSEC検証を実行しています。(「SERVFAIL」というステータスは、検証に失敗したことを意味しますが、検証自体は実際に行われています。)

応答に次のものが含まれている場合:

;; ->>HEADER<<- opcode: QUERY, status: NOERROR

リゾルバはDNSSEC検証を実行していません。

以下のいくつかの例示には、RFC 4034で定義されたKSKのKey Tagを記載しています。示されているKey Tagは実際のものであり、19036がKSK2010の、20236がKSK2017のものです。

以下では、さまざまなリゾルバの実装を列挙し、各リゾルバの更新に必要な手順を説明します。


BIND

BINDバージョン9.9、9.10、9.11では、RFC 5011自動更新によるDNSSEC検証に対応しています。これらのバージョンの最新のサブバージョンには、トラストアンカーとしてKSK2017が含まれています。

まず、DNSSEC検証がコンフィグファイルに設定されていることを確認します。設定されていれば、optionsセクションにdnssec-validation auto;またはdnssec-validation yes;という行があります。dnssec-validationautoに設定されている場合には、ソフトウェアまたはコンフィグファイルを更新する必要はありません。BINDの停止と開始に使用する通常のコマンドでソフトウェアを再起動してください。これにより、dnssec-validation autoで最新のトラストアンカーが使用されます。

コンフィグファイルにdnssec-validation yes;がある場合、以下の手順を行う前に、この文字列をdnssec-validation auto;に変更し、サーバーを再起動する必要があります

ソフトウェアを更新できる場合:

  1. ソフトウェアのインストール手順に従って、BIND 9.9、BIND 9.10 または BIND 9.11の最新のサブバージョンに更新します。BIND 9.8は対応ソフトウェアではありません。このバージョンを実行している場合には、BIND 9.9以降に更新する必要があります。少なくとも次のサブバージョンが必要です。
    • BIND 9.9.10
    • BIND 9.10.5
    • BIND 9.11.1
  2. コンフィグファイルのoptionsセクションに、dnssec-validation auto;という行があることを確認します。
  3. BINDの停止と開始に使用する通常のコマンドを使用して、古いバージョンのBINDを停止し、新しいバージョンを開始します。

ソフトウェアを更新できない場合:

  1. 新しいトラストアンカーを含むようにbind.keysファイルを更新します。bind.keysファイルは、BINDの他のファイルと同じディレクトリに保存されています。また、named.confファイルのmanaged-keysセクションにトラストアンカーが含まれている場合、このセクションを更新できます。変更後のファイルまたは構成セクションは次のようになります。
managed-keys {
  . initial-key 257 3 8  "AwEAAagAIKlVZrpC6Ia7gEzahOR+9W29euxhJhVVLOyQbSEW0O8gcCjF
                 FVQUTf6v58fLjwBd0YI0EzrAcQqBGCzh/RStIoO8g0NfnfL2MTJRkxoX
                 bfDaUeVPQuYEhg37NZWAJQ9VnMVDxP/VHL496M/QZxkjf5/Efucp2gaD
                 X6RS6CXpoY68LsvPVjR0ZSwzz1apAzvN9dlzEheX7ICJBBtuA6G3LQpz
                 W5hOA2hzCTMjJPJ8LbqF6dsV6DoBQzgul0sGIcGOYl7OyQdXfZ57relS
                 Qageu+ipAdTTJ25AsRTAoub8ONGcLmqrAmRLKBP1dfwhYB4N7knNnulq
                 QxA+Uk1ihz0=";

  . initial-key 257 3 8  "AwEAAaz/tAm8yTn4Mfeh5eyI96WSVexTBAvkMgJzkKTOiW1vkIbzxeF3
                 +/4RgWOq7HrxRixHlFlExOLAJr5emLvN7SWXgnLh4+B5xQlNVz8Og8kv
                 ArMtNROxVQuCaSnIDdD5LKyWbRd2n9WGe2R8PzgCmr3EgVLrjyBxWezF
                 0jLHwVN8efS3rCj/EWgvIWgb9tarpVUDK/b58Da+sqqls3eNbuv7pr+e
                 oZG+SrDK6nWeL3c6H5Apxz7LjVc1uTIdsIXxuOLYA4/ilBmSVIzuDWfd
                 RUfhHdY6+cn8HFRm+2hM8AnXGXws9555KrUB5qihylGa8subX2Nn6UwN
                 R1AkUTV74bU=";
};

コンフィグファイルでdnssec-validationautoに設定されている場合、bind.keysファイルの内容が、コンフィグファイルのmanaged-keysブロックの内容と統合されます。詳細については、https://www.isc.org/downloads/bind/bind-keys/をご覧ください。

BINDの作成元であるISCは、BINDのDNSSECトラストアンカーの補足情報をhttps://kb.isc.org/article/AA-01529/169/KSK-2010-Rollover.htmlで公開しています。


Unbound

バージョン1.6.5より前のすべてのUnboundでは、ロールオーバー前の30日以内に起動された場合、新しいトラストアンカーを受け入れないという制限があります。

Unboundバージョン1.6.5以降を実行している場合:

  1. 次のコマンドで現在のトラストアンカーを削除します。
    rm root.key
  2. 次のコマンドでトラストアンカーの最新バージョンを取得します。
    unbound-anchor
  3. Unboundを開始する通常のコマンドでUnboundを再起動し、新しい設定を読み込みます。

Unboundバージョン1.6.4以前を実行し、ソフトウェアを更新できる場合:

  1. Unboundをバージョン1.6.5以降に更新します。
  2. 次のコマンドで現在のトラストアンカーを削除します。
    rm root.key
  3. 次のコマンドでトラストアンカーの最新バージョンを取得します。
    unbound-anchor
  4. Unboundを開始する通常のコマンドでUnboundの新しいバージョンを再起動し、新しい設定を読み込みます。

バージョン1.6.4以前のUnboundを実行しているときに、root.keyファイルの鍵の1つが[ VALID ]ではなく、ソフトウェアを更新できない場合:

  1. 両方の鍵が[ VALID ]に設定されている新しいroot.keyファイルをNLnet Labsから取得する方法については、https://www.unbound.net/root-11sep-11oct.htmlをご覧ください。
  2. Unboundを開始する通常のコマンドでUnboundを再起動し、新しい設定を読み込みます。

PowerDNS Recursor

PowerDNS Recursorバージョン4はDNSSEC検証に対応していますが、RFC 5011自動更新によるDNSSEC検証には対応していません。PowerDNS Recursorの場合、トラストアンカーを変更するたびに新しいトラストアンカーのセットを取得する必要があります。PowerDNS Recursorのバージョン4.0.5以降では、インストールされたトラストアンカーにKSK2017が含まれています。

ソフトウェアを更新できる場合:

  1. ソフトウェアのインストール手順に従って、PowerDNS Recursorを最新のサブバージョンに更新します。取得したバージョンが4.0.5以降であることを確認します。
  2. サーバーの停止と開始に使用する通常のコマンドを使用して、PowerDNS Recursorの現在のバージョンを終了し、新しいバージョンを開始します。

ソフトウェアを更新できない場合:

  1. メインのPowerDNS設定にlua-config-file行がない場合には、追加する必要があります。次のように、この行は追加のPowerDNS設定を含むファイルを参照します。
    lua-config-file=/etc/pdns/luaconf.txt
  2. lua-config-file行に指定されているファイルに、次の2行を追加します。
    addDS('.', "19036 8 2  49AAC11D7B6F6446702E54A1607371607A1A41855200FD2CE1CDDE32F24E8FB5")
    addDS('.', "20326 8 2  E06D44B80B8F1D39A95C0B0D7C65D08458E880409BBC683457104237C7F8EC8D")
  3. サーバーの停止と開始に使用する通常のコマンドでPowerDNS Recursorを再起動します。

Knot Resolver

Knot Resolverは、すべてのバージョンでDNSSEC検証に対応しています。RFC 5011自動更新も使用できます。トラストアンカーの最新バージョンを取得するには、鍵を含む現行バージョンのファイルを削除してKnot Resolverを再起動します。現在使用しているKnot Resolverのバージョンを更新する必要はありません。最新のトラストアンカーを取得してKnot Resolverを再起動するだけです。

  1. コンフィグファイルで、次の行があることを確認します。
    trust_anchors.file = 'root.keys'
  2. このファイルに、1903620326を含む行がない場合には、通常のコマンドでサーバーを停止し、root.keysファイルを削除してサーバーを再起動します。これにより、Knot ResolverがIANAから最新のトラストアンカーを含むファイルを取得します。

Windows Server 2012R2、2016

Windows Server(2012R2と2016の両方)は、RFC 5011自動更新によるDNSSEC検証に対応しています。トラストアンカーの最新バージョンを取得するには、現行バージョンのファイルを更新してWindows Serverを再起動します。以下のコマンドはWindows PowerShellを使用します。

通常、トラストアンカーは自動的に更新されます。トラストアンカーの更新時間を確認するには、次のコマンドを使用します。

Get-DnsServerTrustPoint

次の結果が表示されます。

TrustPointName    TrustPointState   LastActiveRefreshTime   NextActiveRefreshTime
--------------    ---------------    ---------------------    ---------------------
.                 Active            9/11/2017  7:45:03 PM    9/12/2017 7:45:03 PM

時間はUTCです。トラストアンカーが正しく更新されない場合には、次のもので置き換えます。

Add-DnsServerTrustAnchor -Root

トラストアンカーが追加されると、Get-DnsServerTrustPointコマンドの出力に更新後のLastActiveRefreshTimeが表示されます。

注:Add-DnsServerTrustAnchor -Rootが失敗した場合には、サーバーでDNSSECが有効になっていることを確認します。次の3つのコマンドを使用します。

$a = Get-DnsServerSetting -All
$a.EnableDnsSec = 1
$a | Set-DnsServerSetting

次のコマンドを実行して、RootTrustAnchorsURLhttps://data.iana.org/root-anchors/root-anchors.xmlを参照していることを確認します。

(Get-DnsServerSetting -All).RootTrustAnchorsURL

Add-DnsServerTrustAnchor -Rootコマンドが機能しない場合には、ファイアウォールで転送が遮断されている可能性があります。セキュリティレベルの高い環境では、この現象が起きる可能性があります。DSトラストアンカーを手動で追加するには、ダイジェスト、アルゴリズム、鍵タグに関する情報が必要です。DNSKEYトラストアンカーを追加するには、公開のDNSKEY(Base64Data)が必要です。鍵セット(DNSKEYアンカー)またはDSSETファイル(DSアンカー)にアクセスできる場合には、トラストアンカーをインポートすることもできます。ルートトラストアンカーのダイジェスト、アルゴリズム(ダイジェストタイプ)、鍵タグについては、https://data.iana.org/root-anchors/root-anchors.xmlをご覧ください。

次のコマンドを実行すると、ルートゾーンにDSトラストアンカーを手動で追加できます。

Add-DnsServerTrustAnchor -Name "."-CryptoAlgorithm  RSASHA256 -Digest  49AAC11D7B6F6446702E54A1607371607A1A41855200FD2CE1CDDE32F24E8FB5 -DigestType  SHA256 -KeyTag 19036 -ComputerName localhost -PassThru

Add-DnsServerTrustAnchor -Name "."-CryptoAlgorithm  RSASHA256 -Digest  E06D44B80B8F1D39A95C0B0D7C65D08458E880409BBC683457104237C7F8EC8D -DigestType  SHA256 -KeyTag 20326 -ComputerName localhost -PassThru

トラストアンカーの更新後にDNSサービスを再起動する必要はありません。必要であれば、次のコマンドを使用してDNSサーバーキャッシュをクリアしてください。

Clear-DnsServerCache -Force

Microsoftは、詳細情報をhttps://technet.microsoft.com/en-us/itpro/powershell/windows/dnsserver/add-dnsservertrustanchorで公開しています。


Nominum Cacheserve 7

Nominum Cacheserve 7(バージョン7.1.2.3、7.2.0.3、7.2.1.2もしくはそれ以上)は、RFC5011管理鍵によるDNSSEC検証に対応しています。古いバージョンでも検証は可能ですが、ロールオーバーコードに問題があるため、使用しないでください。

ソフトウェアを更新できる場合:

  1. 最新のDNSSECルート鍵を取得する最も簡単な方法は、管理鍵を使用して次のバージョンにCacheserveを更新する方法です。
    • 7.1.2.3
    • 7.2.0.3
    • 7.2.1.2

もしくは新しいルート鍵がすでに組み込まれ、機能している後続のバージョンを使います。

ソフトウェアを更新できない場合:

  1. https://support.nominum.com/view-article/965を参照するか、Nominum(https://support.nominum.com/)にお問い合わせください。

Infoblox NIOS

Infobox NIOSはDNSSEC検証に対応していますが、RFC 5011自動更新によるDNSSEC検証には対応していません。Infobox NIOSの場合、トラストアンカーを変更するたびに新しいトラストアンカーのセットを設定する必要があります。

NIOSで新しいルートゾーンの鍵署名鍵(KSK)をトラストアンカーとして追加する方法は次のとおりです。

  1. NIOS GUIにログインします。
  2. [Data Management]、[DNS]の順に移動します。
  3. ツールバーの[Grid DNS Properties]をクリックします。
  4. [Advanced Mode]をオンにします。
  5. [DNSSEC]タブを選択します。
  6. 下にスクロールし、[Trust Anchors]に移動します。
  7. [Add]ボタンをクリックして、鍵の詳細を入力します。ゾーンは「.」、アルゴリズムは「RSA/SHA-256(8)」にします。
  8. [Public Key]列に鍵を貼り付けます。公開鍵は次のとおりです。
AwEAAaz/tAm8yTn4Mfeh5eyI96WSVexTBAvkMgJzkKTOiW1vkIbzxeF3
+/4RgWOq7HrxRixHlFlExOLAJr5emLvN7SWXgnLh4+B5xQlNVz8Og8kv
ArMtNROxVQuCaSnIDdD5LKyWbRd2n9WGe2R8PzgCmr3EgVLrjyBxWezF
0jLHwVN8efS3rCj/EWgvIWgb9tarpVUDK/b58Da+sqqls3eNbuv7pr+e
oZG+SrDK6nWeL3c6H5Apxz7LjVc1uTIdsIXxuOLYA4/ilBmSVIzuDWfd
RUfhHdY6+cn8HFRm+2hM8AnXGXws9555KrUB5qihylGa8subX2Nn6UwN
R1AkUTV74bU=

メンバーレベルから追加する場合:

  1. NIOS GUIにログインします。
  2. [Data Management]、[DNS]、[Members/Servers]の順に移動します。
  3. DNSサーバーを選択します。
  4. [Edit]をクリックします。
  5. [Advanced Mode]をオンにします。
  6. [DNSSEC]を選択します。
  7. 下にスクロールし、[Trust Anchors]に移動します。
  8. [Add]ボタンをクリックして、鍵の詳細を入力します。ゾーンは「.」、アルゴリズムは「RSA/SHA-256(8)」にします。
  9. [Public Key]列に鍵を貼り付けます。公開鍵は次のとおりです。
AwEAAaz/tAm8yTn4Mfeh5eyI96WSVexTBAvkMgJzkKTOiW1vkIbzxeF3
+/4RgWOq7HrxRixHlFlExOLAJr5emLvN7SWXgnLh4+B5xQlNVz8Og8kv
ArMtNROxVQuCaSnIDdD5LKyWbRd2n9WGe2R8PzgCmr3EgVLrjyBxWezF
0jLHwVN8efS3rCj/EWgvIWgb9tarpVUDK/b58Da+sqqls3eNbuv7pr+e
oZG+SrDK6nWeL3c6H5Apxz7LjVc1uTIdsIXxuOLYA4/ilBmSVIzuDWfd
RUfhHdY6+cn8HFRm+2hM8AnXGXws9555KrUB5qihylGa8subX2Nn6UwN
R1AkUTV74bU=

この文書は、JPNICおよびJPRSの支援により、以下をICANNが翻訳したものです。

https://www.icann.org/dns-resolvers-updating-latest-trust-anchor JPNIC、JPRSおよびICANNは、ICANN文書の日本語翻訳に関して協力する旨の覚書を2015年6月22日に締結しています。ICANNはこの翻訳を参考のために提供します。

Domain Name System
Internationalized Domain Name ,IDN,"IDNs are domain names that include characters used in the local representation of languages that are not written with the twenty-six letters of the basic Latin alphabet ""a-z"". An IDN can contain Latin letters with diacritical marks, as required by many European languages, or may consist of characters from non-Latin scripts such as Arabic or Chinese. Many languages also use other types of digits than the European ""0-9"". The basic Latin alphabet together with the European-Arabic digits are, for the purpose of domain names, termed ""ASCII characters"" (ASCII = American Standard Code for Information Interchange). These are also included in the broader range of ""Unicode characters"" that provides the basis for IDNs. The ""hostname rule"" requires that all domain names of the type under consideration here are stored in the DNS using only the ASCII characters listed above, with the one further addition of the hyphen ""-"". The Unicode form of an IDN therefore requires special encoding before it is entered into the DNS. The following terminology is used when distinguishing between these forms: A domain name consists of a series of ""labels"" (separated by ""dots""). The ASCII form of an IDN label is termed an ""A-label"". All operations defined in the DNS protocol use A-labels exclusively. The Unicode form, which a user expects to be displayed, is termed a ""U-label"". The difference may be illustrated with the Hindi word for ""test"" — परीका — appearing here as a U-label would (in the Devanagari script). A special form of ""ASCII compatible encoding"" (abbreviated ACE) is applied to this to produce the corresponding A-label: xn--11b5bs1di. A domain name that only includes ASCII letters, digits, and hyphens is termed an ""LDH label"". Although the definitions of A-labels and LDH-labels overlap, a name consisting exclusively of LDH labels, such as""icann.org"" is not an IDN."