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で現在のトラストアンカーを確認する方法は次のとおりです。
- NIOS GUIにログインします。
- [Data Management]、[DNS]の順に移動します。
- ツールバーの[Grid DNS Properties]をクリックします。
- [Advanced Mode]をオンにします。
- [DNSSEC]タブを選択します。
- 下にスクロールし、[Trust Anchors]に移動します。
- 設定済みのすべてのトラストアンカーが[Trust Anchors]テーブルに表示されます。[Zone]列で「.」を含むエントリを探し、[Secure Entry Point]列がチェックされていることを確認します。トラストアンカーがない場合、ルートゾーンの鍵署名鍵(KSK)は設定されていません。[Public Key]列の値の上にマウスカーソルを置くと、完全な値が表示されます。
メンバーレベルから確認する場合:
- NIOS GUIにログインします。
- [Data Management]、[DNS]、[Members/Servers]の順に移動します。
- DNSサーバーを選択します。
- [Edit]をクリックします。
- [Advanced Mode]をオンにします。
- [DNSSEC]を選択します。
- 下にスクロールし、[Trust Anchors]に移動します。
- 設定済みのすべてのトラストアンカーが[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はこの翻訳を参考のために提供します。