第1回はDNSの仕組みとDNSSECについて解説しました。
第2回は電子署名の仕組みとZSK(ゾーン署名鍵)の役割について解説しました。
第3回はZSKでは十分でない信頼性を補完するKSK(鍵署名鍵)について解説しました。
最終回となる本稿では、KSKロールオーバーが実施される前に必ず確認しておくべき事項をお伝えします。
いよいよKSKロールオーバーがJST(日本時間)の10月12日 午前1時（UTC 10月11日 午後4時）に実施されます。
実施前に改めて必要事項を確認し、万全の体制を整えることをお勧めします。
誰が対策するのか
(クリックで拡大)
第1回で触れた通り、KSKロールオーバーの対策を行うのはキャッシュDNSサーバの管理者です。しかし利用者であるユーザも影響の有無について理解する必要があります。
確認事項
KSKロールオーバーに関連して確認が必要な点を記載します。以下のキャッシュDNSサーバ環境はCentOS 7+BIND 9.9.4(chrootなし)を前提としています。
●DNSSECの検証機能を利用しているか確認する
digコマンドが利用できる環境で以下のコマンドを実行します。「xxx.xxx.xxx.xxx」にはチェック対象のキャッシュDNSサーバのIPアドレスまたはFQDNを入力します。
|
$ dig @xxx.xxx.xxx.xxx dnssec-failed.org a +dnssec |
DNSSECの検証機能が有効なキャッシュDNSサーバであれば、「status: SERVFAIL」の応答となります。「dnssec-failed.org」はDNSSECの検証に失敗するドメインなので、ステータスがサーバエラーとなるのは正常です。
|
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL |
DNSSECの検証機能が無効なキャッシュDNSサーバであれば、「status: NOERROR」の応答となります。DNSSECの検証を行わないため、ステータスがエラーなしとなります。
|
;; ->>HEADER<<- opcode: QUERY, status: NOERROR |
●トラストアンカー(ルートゾーンKSK公開鍵)の確認
新旧のトラストアンカーは以下の通りです。
・既存のトラストアンカー(KSK-2010,Key ID: 19036)
|
AwEAAagAIKlVZrpC6Ia7gEzahOR+9W29euxhJhVVLOyQbSEW0O8gcCjF FVQUTf6v58fLjwBd0YI0EzrAcQqBGCzh/RStIoO8g0NfnfL2MTJRkxoX bfDaUeVPQuYEhg37NZWAJQ9VnMVDxP/VHL496M/QZxkjf5/Efucp2gaD X6RS6CXpoY68LsvPVjR0ZSwzz1apAzvN9dlzEheX7ICJBBtuA6G3LQpz W5hOA2hzCTMjJPJ8LbqF6dsV6DoBQzgul0sGIcGOYl7OyQdXfZ57relS Qageu+ipAdTTJ25AsRTAoub8ONGcLmqrAmRLKBP1dfwhYB4N7knNnulq QxA+Uk1ihz0= |
・新しいトラストアンカー(KSK-2017,Key ID: 20326)
|
AwEAAaz/tAm8yTn4Mfeh5eyI96WSVexTBAvkMgJzkKTOiW1vkIbzxeF3 +/4RgWOq7HrxRixHlFlExOLAJr5emLvN7SWXgnLh4+B5xQlNVz8Og8kv ArMtNROxVQuCaSnIDdD5LKyWbRd2n9WGe2R8PzgCmr3EgVLrjyBxWezF 0jLHwVN8efS3rCj/EWgvIWgb9tarpVUDK/b58Da+sqqls3eNbuv7pr+e oZG+SrDK6nWeL3c6H5Apxz7LjVc1uTIdsIXxuOLYA4/ilBmSVIzuDWfd RUfhHdY6+cn8HFRm+2hM8AnXGXws9555KrUB5qihylGa8subX2Nn6UwN R1AkUTV74bU= |
キャッシュDNSサーバ内で以下の2ファイルに新しいトラストアンカーが記載されていることを確認します。
|
/etc/named.iscdlv.key /etc/named.root.key |
<参考>
https://www.isc.org/downloads/bind/bind-keys/
https://ftp.isc.org/isc/bind9/keys/9.11/bind.keys.v9_11
● 自動更新ファイルの確認
キャッシュDNSサーバ内で以下の2ファイルに新しいトラストアンカーが記載されていることを確認します。
|
/var/named/dynamic/managed-keys.bind |
● DNS応答サイズ増大の対応確認
PCのWebブラウザで以下のURLへアクセスします。この時、名前解決に利用するDNSサーバにDNS応答サイズ増大対応のチェックをしたいキャッシュDNSサーバを設定しておきます。
・確認サイト：http://keysizetest.verisignlabs.com/
・結果
（クリックで拡大）
「1」～「4」がPASSになっていれば問題ありません。(「5」は必ずFAILになります)
＊DNS応答サイズが増大する理由としては新旧のZSKおよびKSK、計4つのDNSKEYが応答に含まれる期間があるためです。
＊DNSKEYの応答はDNSSECの利用有無にかかわらず発生します。
＊DNSSECが有効な場合はさらに署名情報(RRSIG)も応答に追加されるため、DNS応答サイズはより大きくなります。
MTU 1280(IPv6の最小MTU)と想定した場合、署名情報を含めるとMTUを超えてしまうため、IPフラグメンテーション(パケットの分割送信)が発生します。IPフラグメンテーションが発生した際、適切に対応できない環境では通信に問題が発生する可能性があります。そのため、前述のチェックでDNS応答サイズが増大しても(IPフラグメンテーションが発生しても)問題がないかチェックする必要があります。
●TCP53の通信が可能であることを確認
キャッシュDNSサーバがTCPによるDNSの通信が可能であるか確認します。DNSでは通常UDPが利用されますが、DNSサーバが扱えるUDP最大サイズを超えた場合TCPで再送する(TCPフォールバック)ためです。DNSサーバソフトウェアがTCPに対応しているだけでなく、キャッシュDNSサーバのネットワーク内でファイアウォールや通信機器によるTCP53の通信制限がないか確認が必要です。
注意が必要なケース
● アプライアンスのDNSサーバを使用しているケース
DNSサーバはサーバOSでDNSサーバソフトウェアを稼働させる構成がよく知られています。しかし独自のDNSサーバソフトウェアとそれを稼働させるハードウェアが一体となったアプライアンスのDNSサーバが存在します。
KSKロールオーバーへの対応についてマニュアルやベンダーのWebサイトに記載されていない場合、DNSサーバのベンダーに問い合わせして確認する必要があります。
● 古いバージョンのDNSサーバを使用しているケース
多くの場合、DNSサーバソフトウェアのバージョンアップでKSKロールオーバーに対応できます。しかし「社内にあり外部公開をしていない」など様々な理由で古いバージョンのDNSサーバを利用していることがあるかもしれません。
KSKロールオーバーに未対応だったとしても急なバージョンアップはリスクが伴います。このような場合、信頼できるパブリックDNSサーバの利用やDNSSECの無効化など一時的な回避策を検討する必要があります。
最悪の場合はDNSSECの一時的な無効化を検討する
DNSSECはICANNをはじめDNSに関わる多くの組織で推奨されている技術です。同時に仕組みが複雑で運用が難しいこともよく知られています。
KSKロールオーバー未対応によるリスクは名前解決ができなくなることです。これは多くの場合、インターネットを利用できなくなることと同義です。ICANNのサイトに記載されている通り、KSKロールオーバーの対策が難しい場合はDNSSECの検証機能を一時的に無効化することを検討しましょう。
<参考>
https://www.icann.org/resources/press-material/release-2018-09-18-ja
KSKロールオーバーについての説明は本稿で最後となります。
KSKロールオーバー実施前に改めて必要事項を確認し対策しておくことが大切です。
＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝
>> CDNetworksのサービス全般についてはこちら
>> お問い合わせ、ご相談はこちら
株式会社シーディーネットワークス・ジャパン
TEL：03-5909-3373（営業部）
