Skip to main content
Resources

DNS検証リゾルバにおける現在のトラストアンカーの確認

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

このページは、DNSSEC検証で最新のトラストアンカーが使用されていることを確認したいDNSリゾルバ(再帰リゾルバともいいます)の管理者を対象にしています。実行しているリゾルバがKSKロールオーバーに対応しているかどうか分からない場合には、以下の手順で最新のトラストアンカーかどうかを確認できます。

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

ここで説明する情報は、DNSリゾルバがDNSSECを検証する場合にのみ必要になります。ICANNは、可能であればDNSSEC検証を推奨しますが、DNSSECをまだ検証していない場合、ここで説明する操作を行う必要はありません。

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-validation yes;がある場合、以下の手順を行う前に、この文字列をdnssec-validation auto;に変更し、サーバーを再起動する必要があります

使用中のトラストアンカーを含むファイルを生成するには、次のコマンドを実行します。

rndc secroots

このコマンドを実行すると、BINDの他のファイルが作成されているディレクトリにnamed.secrootsという名前のファイルが作成されます。このファイルには、./RSASHA256/20326という行と./RSASHA256/19036という行が含まれます。この両方の鍵が含まれていない場合には、この説明に従ってトラストアンカーを更新する必要があります。

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


Unbound

Unboundの構成ディレクトリ(通常は/etc/unbound)でroot.keyファイルを探します。このファイルに2つのDNSKEYレコードがあります。1つのレコードはid = 20326という文字列を含み、もう1つのレコードはid = 19036という文字列を含みます。両方のレコードに;;state=2 [ VALID ]が設定されています。このファイルに両方の鍵がないか、いずれかの鍵の状態が;;state=2 [ VALID ]でない場合、この説明に従ってトラストアンカーを更新する必要があります。


PowerDNS Recursor

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

コマンドラインインターフェースで、次のコマンドを実行します。

rec_control get-tas

. 20326を含む行と. 19036を含む行が表示されます。この両方の鍵が含まれていない場合には、この説明に従ってトラストアンカーを更新する必要があります。


Knot Resolver

Knot Resolverは、すべてのバージョンでDNSSEC検証に対応しています。RFC 5011自動更新も使用できます。

Knot Resolverのコンフィグディレクトリ(ディストリビューションによって異なります)でroot.keysファイルを探します。0101030803010001A80020A95566BA42E886BB804CDA84E47EF56DBという文字列を含む行と0101030803010001ACFFB409BCC939F831F7A1E5EC88F7A59255EC5という文字列を含む行があります。この両方の鍵が含まれていない場合には、この説明に従ってトラストアンカーを更新する必要があります。


Windows Server 2012R2、2016

Windows Server(2012R2と2016の両方)は、RFC 5011自動更新によるDNSSEC検証に対応しています。以下のコマンドはWindows PowerShellを使用します。

トラストアンカーの内容を確認するには、次のコマンドを使用します。

Get-DnsServerTrustAnchor -Name .

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

TrustAnchorName    TrustAnchorType    TrustAnchorState   TrustAnchorData
---------------    ---------------    ----------------   ---------------
.                  DNSKEY            Valid               [19036][DnsSec][RsaSha256][AwEAAagAIKlVZrpC6Ia7...
.                  DNSKEY            Valid               [20326][DnsSec][RsaSha256][AwEAAaz/tAm8yTn4Mfeh...

鍵タグがTrustAnchorDataに表示されます。ルートトラストアンカーの場合、鍵タグとして19036と20326の2つが表示されます。両方のトラストアンカーの状態が「Valid」になっているはずです。この両方の鍵が含まれていない場合には、この説明に従ってトラストアンカーを更新する必要があります。

現在サーバーで有効になっているトラストポイントをすべて表示するには、次のコマンドを使用します。

Get-DnsServerTrustPoint

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

TrustPointName    TrustPointState    LastActiveRefreshTime    NextActiveRefreshTime
--------------    ---------------    ---------------------    ---------------------
.                 Active            9/11/2017  8:37:02 PM    9/12/2017 8:37:02 PM

Nominum Cacheserve 7

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

nom-tell cacheserve resolver.mget fields='(trusted-keys  managed-keys-state)'

出力結果にtrusted-keysフィールドまたはmanaged-keys-stateフィールドがある場合、CacheserveはDNSSEC検証を実行しています。正しい鍵が使用されていることを確認してください。ルート('.')のmanaged-keys-stateでは、keyidに19036と20326の両方が表示され、stateにはvalidが表示されます。また、has-validatedフィールドはTrueに設定されます。trusted keysの場合、実際の鍵データを比較する必要があります。鍵を確認する場合、あるいは前述のように鍵の修正を行う場合には、この説明をご覧ください。


Infoblox NIOS

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

NIOSで現在のトラストアンカーを確認する方法は次のとおりです。

  1. NIOS GUIにログインします。
  2. [Data Management]、[DNS]の順に移動します。
  3. ツールバーの[Grid DNS Properties]をクリックします。
  4. [Advanced Mode]をオンにします。
  5. [DNSSEC]タブを選択します。
  6. 下にスクロールし、[Trust Anchors]に移動します。
  7. 設定済みのすべてのトラストアンカーが[Trust Anchors]テーブルに表示されます。[Zone]列で「.」を含むエントリを探し、[Secure Entry Point]列がチェックされていることを確認します。トラストアンカーがない場合、ルートゾーンの鍵署名鍵(KSK)は設定されていません。[Public Key]列の値の上にマウスカーソルを置くと、完全な値が表示されます。

メンバーレベルから確認する場合:

  1. NIOS GUIにログインします。
  2. [Data Management]、[DNS]、[Members/Servers]の順に移動します。
  3. DNSサーバーを選択します。
  4. [Edit]をクリックします。
  5. [Advanced Mode]をオンにします。
  6. [DNSSEC]を選択します。
  7. 下にスクロールし、[Trust Anchors]に移動します。
  8. 設定済みのすべてのトラストアンカーが[Trust Anchors]テーブルに表示されます。[Zone]列で「.」を含むエントリを探し、[Secure Entry Point]列がチェックされていることを確認します。トラストアンカーがない場合、ルートゾーンの鍵署名鍵は設定されていません。[Public Key]列の値の上にマウスカーソルを置くと、完全な値が表示されます。

古いルート鍵署名鍵は次のとおりです。

AwEAAagAIKlVZrpC6Ia7gEzahOR+9W29euxhJhVVLOyQbSEW0O8gcCjFFVQUTf6v58fLjwBd0YI0Ezr
AcQqBGCzh/RStIoO8g0NfnfL2MTJRkxoX bfDaUeVPQuYEhg37NZWAJQ9VnMVDxP/VHL496M/QZxkjf
5/Efucp2gaDX6RS6CXpoY68LsvPVjR0ZSwzz1apAzvN9dlzEheX7ICJBBtuA6G3LQpzW5hOA2hzCTMj
JPJ8LbqF6dsV6DoBQzgul0sGIcGOYl7OyQdXfZ57relSQageu+ipAdTTJ25AsRTAoub8ONGcLmqrAmR
LKBP1dfwhYB4N7knNnulqQxA+Uk1ihz0=

新しい(現在の)ルート鍵署名鍵は次のとおりです。

AwEAAaz/tAm8yTn4Mfeh5eyI96WSVexTBAvkMgJzkKTOiW1vkIbzxeF3+/4RgWOq7HrxRixHlFlExOL
AJr5emLvN7SWXgnLh4+B5xQlNVz8Og8kv  ArMtNROxVQuCaSnIDdD5LKyWbRd2n9WGe2R8PzgCmr3Eg
VLrjyBxWezF0jLHwVN8efS3rCj/EWgvIWgb9tarpVUDK/b58Da+sqqls3eNbuv7pr+eoZG+SrDK6nWe
L3c6H5Apxz7LjVc1uTIdsIXxuOLYA4/ilBmSVIzuDWfd  RUfhHdY6+cn8HFRm+2hM8AnXGXws9555Kr
UB5qihylGa8subX2Nn6UwNR1AkUTV74bU=

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

https://www.icann.org/dns-resolvers-checking-current-trust-anchors 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."