延期となったKSKロールオーバーについて
tech_team インターネットの技術ルートゾーンKSKロールオーバーの延期
2016年10月から1年以上かけて、 DNSの起点となるルートゾーンにおいて、DNSSECのトラストアンカーとなる鍵、KSK(Key signing Key)の更新が行われています。
これまで、2017年7月11日に予定されていた新しい鍵(KSK-2017)の公開、および2017年9月19日に予定されていたZSKロールオーバーが実施されました。DNSKEY応答サイズの増加にともなうIPフラグメンテーションによる障害など、事前に心配されていたような大きな問題は発生せず、順調に経過しました。スケジュール通りであれば、その後の2017年10月11日からは、現在の鍵(KSK-2010)での署名を停止し、同時に KSK-2017 を用いたゾーンの署名を開始するという、実際のロールオーバーが行われる予定でした。しかし2017年9月27日、DNSのルートゾーンを管理するICANNが、現在実施中のルートゾーンKSKロールオーバーに関するスケジュールを変更、具体的にはKSK-2017による署名の開始を延期すると発表しました。
- KSK Rollover Postponed
-
https://www.icann.org/news/announcement-2017-09-27-en (英語)
https://www.icann.org/news/announcement-2017-09-27-ja (日本語)
9月27日に出されたICANNのアナウンスでは、
「最近収集したデータで、非常に多くのインターネットサービスプロバイダー（ISP）とネットワーク事業者のリゾルバで変更への対応が完了していないことが明らかになったため、ロールオーバーの実施を延期することにしました。」
とありましたが、どのような調査を行ったのか、状況はどうだったのか、対応を完了していないリゾルバがどれくらいあったのかなど、詳細についてほとんど触れられていませんでした。
しかしその後、DNSに特化したカンファレンスである “OARC 27” でKSKロールオーバーに関する発表があったり、また、ICANNによる背景説明のブログ記事が公開されるなどがあり、詳細は少しずつ明らかになってきました。本記事ではそれらの内容を元に、KSKロールオーバーが延期となった状況についてご紹介します。
トラストアンカーのロールオーバー
DNSSECは、DNSのデータ生成元の認証およびデータの完全性を、電子署名によって担保しています。データが正しいものかどうかは、トラストアンカーから始まり特定のレコードまで信頼の連鎖(chain of trust)をたどりながらその電子署名を検証することで確認することができます。
DNSSECのトラストアンカーは、ルートゾーンのKSKがその役割を担っています。ルートゾーンKSKロールオーバーとはこのKSKを更新することを指し、更新作業はICANNが実施します。その一方、インターネット上でDNSSEC検証を有効にしているリゾルバは、ルートゾーンのKSK更新と同期する形で、自身の信頼しているトラストアンカーを新しいKSKに合わせる必要があります。これらの同期がうまくいかなかった場合、ルートゾーンのKSK更新後、リゾルバは署名検証に失敗しルートゾーンのレコードが引けなくなるため、名前解決ができなくなります。そのリゾルバを利用するユーザにとっては「DNSが使えない」状態になります。このようなことが発生しないよう、正しく更新することが重要です。
ICANNの懸念
さて、上記の通りリゾルバがトラストアンカーを正しく設定することが重要であるため、ICANNはKSKロールオーバーの実施にあたり、世界中のDNSSEC検証を有効にしているリゾルバが、トラストアンカーを正常に設定されているかどうかを懸念していました。
リゾルバのトラストアンカーがどのように設定されているかどうかは、これまでその管理者以外に知る方法がありませんでした。しかし2017年4月、”Trust Anchor Signaling” と呼ばれるトラストアンカーの通知機能がRFC 8145として標準化され、ルートサーバを含む権威サーバ側が、リゾルバで設定されているトラストアンカーを知ることができるようになりました。
Trust Anchor Signaling とは
Trust Anchor Signaling とは、DNSSEC検証を有効にしたリゾルバから、問い合わせ先の権威サーバに対して、どのような鍵を用いてDNSSECの署名検証をしているかを通知する機能です。
DNSSECにおいて署名を検証するには、署名に対応する公開鍵であるDNSKEYが必要です。通常、DNSKEYは権威サーバへ問い合わせすることで入手します。
Trust Anchor Signalingを有効にしたリゾルバは、権威サーバに対してDNSKEYを問い合わせる際にそのゾーンのKSK、ルートゾーンの場合はトラストアンカーの鍵タグ*1を通知します。リゾルバから問い合わせを受けた権威サーバはDNSKEYレコードを応答しますが、そのリゾルバからの問い合わせ内容を調べることで、リゾルバがどのDNSKEYを署名検証に用いているかを把握することができます*2)。
ただし、このTrust Anchor Signalingは2017年4月に標準化されたばかりであり、最近リリースされたBINDやunboundで実装されている程度です(BIND は9.10.5b1, 9.11.0b3 以降、 Unbound は 1.6.4 以降)。そのため普及はまだこれからといったところです。また、この機能はBINDの場合デフォルトで有効になっていますが、unboundの場合、1.6.7より前のバージョンでは無効になっており、明示的に設定しない限り通知は行われません(1.6.7からはデフォルトで有効になりました)。
- RFC 8145 – Signaling Trust Anchor Knowledge in DNS Security Extensions
- https://tools.ietf.org/html/rfc8145
- BIND Trust Anchor Telemetry in BIND 9.9.10, 9.10.5 and 9.11.0
- https://kb.isc.org/article/AA-01528/0/BIND-Trust-Anchor-Telemetry-in-BIND-9.9.10-9.10.5-and-9.11.0.html
- Unbound Downloads
- https://www.unbound.net/download.html
Trust Anchor Signaling による調査
OARC 27において、Verisign社のDuane Wessels 氏から Trust Anchor Signaling を用いたトラストアンカーの利用状況の調査について報告がありました。
その中で、A-root および J-root へシグナルを送信するリゾルバの数や、そのトラストアンカーの利用状況について紹介されました(図1,図2)。図中の赤はKSK-2010のみをトラストアンカーとして利用しているリゾルバ、緑はKSK-2010とKSK-2017の両方をトラストアンカーとして利用しているリゾルバの、それぞれ割合および通知元の数を表しています。
図1
https://indico.dns-oarc.net/event/27/session/1/contribution/11/material/slides/0.pdf
図2
https://indico.dns-oarc.net/event/27/session/1/contribution/11/material/slides/0.pdf
7月11日にKSK-2017がルートゾーンで公開された後、1ヶ月ほどはKSK-2010を引き続きトラストアンカーとしているリゾルバがほとんどですが、8月10日頃からKSK-2010とKSK-2017の両方をトラストアンカーとしているリゾルバが一気に増えています。これはRFC 5011による自動更新での待機期間である “Hold Down Timer” が経過し、リゾルバがKSK-2017をトラストアンカーとして取り扱い始めたものと考えられます。
しかしここで注目したい点は、その8月10日以降も赤い線、すなわちKSK-2010だけをトラストアンカーにしているリゾルバが、割合は少ないものの一定数存在し続けていることです。これはKSK-2017をトラストアンカーにできていないリゾルバが、ある程度インターネット上に存在していることを示しています。前述の通り、これらのリゾルバはこのままロールオーバーが実施された場合「DNSが使えない」状態になるということです。
この調査結果は8月下旬にICANNに報告されました。ICANNでも2017年9月の1ヶ月間、六つのルートサーバを対象に同様の調査を行いました。その結果おおよそ12,000のユニークIPアドレスから通知があり、そのうち6～8%ほどのリゾルバがKSK-2017をトラストアンカーにしていないことが判明しました。なお、ICANNによればこの中に含まれる日本国内のリゾルバは、世界の平均よりもやや高い割合になっているとのことです。
なお、プレゼンテーション後に行われた質疑では、調査結果に誤りのあるシグナルが含まれている可能性があるというコメントがありました。
一つ目は、BINDにおいて、DNSSEC検証を有効にしていないにもかかわらずトラストアンカーを通知することがあり、より慎重に結果を調べることが必要だというものです。DNSSEC検証を有効にしていなければ、RFC5011による自動更新が働かないため、KSK-2010のみのリゾルバと見えてしまうことになるためです。
二つ目は、フォワーダーとして動作しているDNSサーバを利用するリゾルバの存在です。フォワーダーを利用している別のリゾルバが、自身のトラストアンカーの設定状況について通知した場合、ルートサーバからはフォワーダーの設定状況に見えるため、通知内容や通知元について不確かなものになるということになります。特にフォワーダーを複数のリゾルバが利用している状況ではきちんとした調査結果が得られない可能性が高くなります。
KSKロールオーバーの延期
Trust Anchor Signaling を有効にしているリゾルバは、インターネット上のDNSSEC検証を有効にしているリゾルバ全体のうちごく限られた割合であり、さらにKSK-2010のみをトラストアンカーにしているリゾルバはそのうちの数パーセントです。しかしながら、ICANNはこれを重要視し、ロールオーバーの延期を決定しました。ICANNは、ロールオーバーを普段のオペレーションに悪影響を与えない形で慎重に行うことが大切だと考えており、延期をすることは細心の用心のためであると述べています。KSK-2010のみのリゾルバの割合がICANNの予想よりも高いため、KSKロールオーバーを進める前にその原因を把握することを望んでいます*3)。そのため、近い将来KSK-2010のみのリゾルバのリストを公開し、コミュニティと協力してそれらの特定や原因究明を行いたいとしています。
最後に
最後に、気になるロールオーバーの再開時期ですが、現在でも決まっていません。ルートゾーンKSKロールオーバーの計画である “KSK Rollover Operational Implementation Plan” では、作業フェーズの延長が必要になった場合、少なくとも1四半期延期するとしています(現在のフェーズは Phase D: Publication)。また、いつ次のフェーズ(Phase E: Rollover)に移行するかどうかは Root Zone Management Partners(ICANN, Verisign, NTIA) の判断による、となっています。ICANNは現在では2018年第1四半期を考えているとのことですが、KSK-2010のみのリゾルバについてどう対処するかによってさらに延びることが考えられます。
(*1) 鍵タグ(key tag)
DNSSECでは、ある電子署名がどの鍵を用いて生成されたかを、鍵タグ(Key Tag)と呼ばれる数値を用いて判別します。
鍵タグは16ビットの符号無し整数であり、公開鍵のレコードであるDNSKEYから、ある決まったアルゴリズムによって計算されます。電子署名のレコードであるRRSIGには、この鍵タグを格納するフィールドが含まれており、その署名をどのDNSKEYを用いて検証すれば良いかをこのフィールドから知ることができるようになっています。
(*2) Trust Anchor Signaling での二つの通知方法
Trust Anchor Signalingの通知方法はEDNS0を使うものと使わないものの、二通りの方法があります。
EDNS0のedns-key-tagオプションを使用した場合、DNSKEYの問い合わせ中にEDNS0を用いて鍵タグを含めます。edns-key-tagオプションを使用しない場合、DNSKEYの問い合わせとはまた別にDNS問い合わせを行い、鍵タグを通知します。
二通りある理由として、EDNS0を用いた場合、DNSサーバやDNSメッセージの中継ノードが未知のEDNS0オプションを含んだパケットを受け取ったときに、ENS0オプションの削除もしくはDNSメッセージそのものを破棄することがあるためです。そのため、EDNS0を使わない方法でDNS問い合わせによる通知が行えるようになっています。現在、BIND,unboundともにEDNS0を使わない実装となっています。
(*3)予想される原因
新しい鍵がトラストアンカーとして使用されない原因として、古い設定のままにしている、意図的に手動設定にして鍵を更新していない、RFC5011が正しく動作していない、Trust Anchor Signalingの実装に問題がある、調査手法に問題がある、などがあげられています。
参考
- KSKロールオーバーについて
- https://www.nic.ad.jp/ja/dns/ksk-rollover/
- ICANNがルートゾーンKSKロールオーバーの実施延期を発表
- https://www.nic.ad.jp/ja/topics/2017/20170928-01.html
- OARC 27
- https://indico.dns-oarc.net/event/27/
- The Story Behind ICANN’s Decision to Delay the KSK Rollover
- https://www.icann.org/news/blog/the-story-behind-icann-s-decision-to-delay-the-ksk-rollover
- Root Zone KSK Rollover is Postponed
- https://blog.verisign.com/domain-names/root-zone-ksk-rollover-postponed/
- A Look at RFC 8145 Trust Anchor Signaling for the 2017 KSK Rollover
- https://indico.dns-oarc.net/event/27/session/1/contribution/11/material/slides/0.pdf
- KSK Rollover Operational Implementation Plan
- https://www.icann.org/en/system/files/files/ksk-rollover-operational-implementation-plan-22jul16-en.pdf