今さらルートゾーンKSKロールオーバーについてのまとめ
2018/10/3：延期されたスケジュールを反映しました[5]。残りの日程はすべて1年遅れです。2018年10月11日に新しい鍵による署名開始がやってきます。
さて、インターネット上の一大イベントのひとつ「ルートゾーンKSKロールオーバー」がやってきます。というか、話題にするのが遅くてもうやってきていますね。
その影響が表れる可能性がある最初の日、2017年9月19日まで1ヶ月を切りました。JPRSやJPNICなどインターネット関連の諸機関はもちろん、内閣官房など政府からも「気ぃ付けや！」というお達しが出ています。
というわけで、すでにロールオーバーのプロセスは始まってしまっているので今更ですが、そもそもルートゾーンKSKロールオーバーとは何なのか、どんな影響があるのか、自分のサーバーは大丈夫か確認する方法についてまとめました。
(ざっくりとだけ書いていますので、細かい部分はわかりやすさ優先しました。詳細な部分については参考資料などを別途参照してください）
「ルートゾーンKSKロールオーバー」とは
ルートゾーンKSKロールオーバーはDNSの世界の「DNSSEC」という技術に関わる話です。
KSKは「Key Signing Key（鍵署名鍵）」というものです。
DNSの通信に改ざんなどによる被害を防止するセキュリティ技術「DNSSEC」では、サーバー証明書などと同じく公開鍵暗号による「電子署名」を使っています。電子署名では、あるデータが信頼できることを証明するために署名をおこない、その署名をした人が信頼できることを証明するためにまた署名をおこない、ということを繰り返します。信頼できるかを検証するには、署名を辿っていって誰もが信頼する「信頼の起点（トラストアンカー）」にたどり着けば、「そのデータは信頼できる」と判断できるわけです。
ルート証明書がサーバー証明書の「トラストアンカー」であるように、ルートゾーンKSKはDNSSECの「トラストアンカー」にあたるものです。
そして、安全性向上のために、サーバー証明書に更新が必要なように、ルートゾーンKSKにも更新が必要とされています。それが「ルートゾーンKSKロールオーバー」です。
しかも、このルートゾーンKSKロールオーバーは今回が初めてなので、各所がざわざわしています。
どのような影響があるのか
ルートゾーンKSKロールオーバーは「キャッシュDNSサーバー*1」に影響します。問題となる影響の内容は大きく分けて2つです。
- サイズが大きくなったDNS応答を受け取れない可能性がある
- DNSSEC検証が失敗する可能性がある
厄介なところは、前者についてはDNSSECを使っていなくても影響が出る可能性があるというところです。
サイズが大きくなったDNS応答を受け取れない可能性がある
ルートゾーンKSKロールオーバーでは移行期間が設けられています（具体的なスケジュールは参考資料[2]のP15を参照）。移行期間中は、DNS応答の通信に新旧両方の情報が含まれるため、サイズが大きくなります。
利用しているネットワーク機器等の設定や仕様によっては、DNS応答のパケットが分割されてしまう「IPフラグメント*2」が発生し、応答を正しく受け取れない可能性があります。
つまり、DNSSECで検証をする以前に、DNSの応答が届かないので、DNSSECを使用しているかどうかに関わらず影響する可能性があります。
DNS応答パケットのサイズが、初めてIPフラグメントを起こす可能性のあるサイズになるのが「2017年9月19日」の予定です。
DNSSEC検証が失敗する可能性がある
ルートゾーンKSKロールオーバーにともなって、DNSSECのトラストアンカーが更新されるのは前述のとおりです。（実はこの更新は2017年6月20日にすでに始まっています）
移行期間内にDNSキャッシュサーバーが持っているトラストアンカーの情報が更新されなければ、それ以降はDNSSECの検証が失敗してしまいます。
DNSキャッシュサーバーで、トラストアンカーの自動更新（RFC 5011）機能が有効になっていない場合や、新旧両方のトラストアンカーが予め内蔵された製品でない場合、手動で更新が必要です。
ただし、こちらについては、DNSSEC検証が無効になっている環境では影響ありません。
影響がないか確認する方法
DNS応答の受信可能サイズを確認する
キャッシュサーバーが受信可能なDNSパケットサイズを確認します。もし今回のルートゾーンKSKロールオーバーにおける最大サイズ（1424バイト）よりも小さい場合は、ネットワーク機器などの設定を見直してください。
1. キャッシュサーバー上で次のコマンドを実行します。
$ dig +bufsize=4096 +short rs.dns-oarc.net txt
キャッシュサーバーの外から実行する場合は、@オプションを使います。
$ dig @192.168.0.1 +bufsize=4096 +short rs.dns-oarc.net txt
2. 応答の中の「DNS reply size limit is at least ****」を確認します。この数値が1424バイトを超えていれば問題ありません。（プロトコルの規格上は最大4096バイトのため、これに近い値が望ましいです）
$ dig +bufsize=4096 +short rs.dns-oarc.net txt rst.x4050.rs.dns-oarc.net. rst.x4058.x4050.rs.dns-oarc.net. rst.x4064.x4058.x4050.rs.dns-oarc.net. "Tested at 2017-08-20 11:09:39 UTC" "192.168.0.1 sent EDNS buffer size 4096" "192.168.0.1 DNS reply size limit is at least 4064"
digコマンドが使用できない場合は、自ネットワーク内から下記のVerisignのサイトにブラウザでアクセスして確認する方法もあります。項目1～4が「PASS」になっていればOKです（項目5は必ずFAILです）。
DNSSEC Key Size Test （Verisign Labs）http://keysizetest.verisignlabs.com/
トラストアンカーの自動更新設定と更新状況の確認
キャッシュサーバーとして、BINDやunboundを使っている場合は、参考資料[3]を参照してください。（サボり）
また、下記参考資料[4]のとおり、WindowsのDNSでは対策不要らしいです。
他の製品を使っている場合は、マニュアルやメーカーサポートに確認しましょう。
DNSSEC検証の有効/無効の確認
DNSSEC検証が無効になっていれば、問題の2つ目の影響はありませんが、BINDやunboundではデフォルトでDNSSEC検証は有効です。
BIND
named.conf で dnssec-validation no; が設定されていれば無効です。yesやautoの場合は有効です。
unbound
unbound.confでトラストアンカーファイルの指定がコメントアウトされ、module-config: "iterator" となっていれば、無効です。
Windows DNSサーバー
DNS管理ツールのサーバー名を右クリック→[プロパティ]→[詳細設定]タブで[リモート応答のDNSSEC検証を有効にする]のチェックがOFFなら無効です。
まとめ
ルートゾーンKSKロールオーバーに関する情報と対策を簡易的にまとめました。とりあえず、自分が関係するところで対策が必要なものは、今のところ見つかってないです。
最後にルートゾーンKSKロールオーバーのポイントとなるスケジュールです。それぞれに間に合うように確認や対策をおこないましょう。
| 2017/6/20 | 第1回ZSK事前公開 |
| 2017/9/19 | 第2回新ZSK事前公開（DNSKEYパケットサイズが1424バイトまで増加） |
2018/10/11 |
新KSKの利用開始 |
2019/1/11 |
旧KSKの失効開始（トラストアンカー未更新の場合、検証失敗の可能性） |
2018/3/22 |
旧KSKの完全削除（移行完了） |
（日付はUTCです）
参考資料
[1] ルートゾーンKSKロールオーバーの概要と影響の確認方法
https://dnsops.jp/event/20170628/20170628-RootKSKRO-02.pdf
[2] ルートゾーンのKSKロールオーバーについて
https://dnsops.jp/event/20170628/20170628-RootKSKRO-02.pdf
[3] Root KSK 更新に対応する方法
https://www.nic.ad.jp/ja/materials/iw/2015/proceedings/t5/t5-ishihara.pdf
[4] ルート ゾーン KSK の更新に伴う Windows の DNS サーバー上での対策の必要性
https://blogs.technet.microsoft.com/jpntsblog/2017/08/09/dnssec/
[5] 2018 KSK Rollover Back Out Plan
https://www.icann.org/en/system/files/files/2018-ksk-rollover-back-out-plan.pdf
