KSKロールオーバーについて

2018年10月17日更新

2016年10月から、 DNSの起点となるルートゾーンに対して重要な更新が行われています。 2017年9月には、ルートゾーンからの一部のDNS応答のサイズが一時的に増加する変更作業が行われました。また、2017年10月に予定されていたKSKの切り替え作業は延期となりましたが、 2018年2月1日付で発表された計画案では2018年10月11日に改めて実施されることとなりました。この更新に対して問題なく対応するためには、DNSサーバ運用者だけではなく、ネットワーク運用者も事前に調査し、必要があれば準備しておくことが重要です。 (意図せずDNSSEC検証が有効になっている場合もありますので、対象外とお考えの方もぜひご一読ください。)

2018年9月16日に開催されたICANN理事会において、KSKロールオーバーの最終的な実施可否について審議が行われ、予定通り2018年10月11日の実施が決定しました。協定世界時(UTC)では10月11日の午後4時、日本時間では10月12日の午前1時にロールオーバーが実施されました。

何が起きるか
概要
対応が求められる対象と内容
対象者別の確認と対処の方法
よくある質問と回答
関連リンク

0. 何が起きるか

ルートゾーンに含まれる鍵(KSK)が新しくなります(トラストアンカーの更新)。
一部のDNS応答のサイズ(DNSKEYの応答)が一時的に大きくなります(DNS応答サイズ増大への対応)。

大きくなったDNS応答を正しく受け取れない場合、 DNSSECに関わる通信に悪影響が出る可能性があります。その結果、インターネットの利用に問題が発生します。

1. 概要

DNSのルートゾーンにおけるKSK (Key Signing Key)の更新が行われることで、ルートゾーンから転送される一部のDNS応答のサイズが一時的に大きくなります。またDNSSEC検証を有効にしている場合に、古いKSKを使い続けていると正常に検証できなくなります。エンドユーザーにDNSのサービスを正常に提供し続けるためには、キャッシュサーバの運用をしている方やネットワークの管理をしている方が適切な対応を取ることが必要です。

2. 対応が求められる対象と内容

ルートゾーンKSKロールオーバーの実施にあたり対応が求められるのは、大きく分けて以下の3者になります。

キャッシュサーバ(フルリゾルバ)の運用者、ネットワーク運用者
権威サーバの運用者
顧客のネットワークを運用しているシステムインテグレーター(SIer)

BINDやUnboundなど、多くのキャッシュサーバはデフォルトでDNSSEC検証が有効になっています。 DNSSEC検証を有効にした覚えがなくとも、影響を受ける可能性があるのでご注意ください。

それぞれの対象者別に、注意すべき点を説明します。

3. 対象者別の確認と対処の方法

このKSKロールオーバーの更新で必要となる対応は、 DNSSEC検証を有効にしているキャッシュサーバ等のトラストアンカーを更新すること、およびKSKロールオーバーの更新作業中に発生するDNS応答のサイズ増大に対応することです。パケットの大きさが変化するタイミングは以下の通りです。

(※1)DNS応答のサイズは、今後このように変化する予定です。 VPN装置などのデフォルトMTU値やIPv6の最小MTUなどで用いられる1280バイトは、 IPフラグメンテーションが発生しやすくなると推測される値です。

(※2)2017年10月11日に予定されていた新しいKSKによる署名開始が延期となりました(https://www.nic.ad.jp/ja/topics/2017/20170928-01.html)。そのため、それ以降のパケットサイズの変化は、当初予定されていた時期・サイズと異なるものになります。

3.1. キャッシュサーバの運用者、ネットワーク運用者

トラストアンカーの更新
1. DNSSECの設定を確認します。ここ数年のBINDやunboundといったDNSキャッシュサーバは、デフォルトでDNSSEC検証が有効に設定されています。
2-a. DNSSEC検証を有効にしていない	2-b. DNSSEC検証を有効にしている
トラストアンカーを更新する必要はありません。	以下の2点を確認します。更新後のルートゾーンのKSKがあるか。自動更新機能であるRFC5011の機能が有効になっているか。 [手動更新] BINDの場合、named.confのtrusted-keysディレクティブで鍵を指定します。 Unboundの場合、/etc/unbound/root.keyとして鍵を置きます。またはunbound-anchorコマンドを利用して更新します。 [RFC5011による自動更新] BINDの場合、まずnamed.confのmanaged-keysディレクティブで現在の鍵(KSK-2010)を指定します。そして、作業ディレクトリ中のmanaged-keys.bindに更新後の鍵(KSK-2017)が追加されているか確認します。 Unboundの場合、 auto-trust-anchor-fileで現在の鍵(KSK-2010)を指定します。更新後の鍵(KSK-2017)が上記ファイルに追記されるので確認します。
DNS応答サイズ増大への対応
1. TCPによるDNSの通信が可能な設定になっているかを確認します。できない場合は、ファイアウォールやACLなどによってTCP port 53宛の通信が拒否されていないことを確認します。 (必須)
2. EDNS0の応答を受信できるかを確認します。(推奨) BINDの場合、/etc/named.confなどの設定ファイル中で、 "edns no"で無効にしていないことを確認します。なお、デフォルトはyesになっています。また、max-udp-sizeとedns-udp-sizeの値を小さく制限していないことを確認します。デフォルトの値は4096です。 Unboudの場合、/etc/unboud.confなどの設定ファイル中で、 max-udp-sizeとedns-buffer-sizeの値を小さく制限していないことを確認します。デフォルトの値は4096です。
3. 大きなサイズのDNS応答を受け取ることができることを確認します。確認Webサイト DNSSEC Key Size Test http://keysizetest.verisignlabs.com/ テスト結果の一例。チェックボックスの四つ目まで緑であればOK。 5番目の項目は、必ず失敗するようになっています。 DNSを用いた受信可能なパケットサイズの確認 OARC's DNS Reply Size Test Server https://www.dns-oarc.net/oarc/services/replysizetest $ `dig +bufsize=4096 +short rs.dns-oarc.net txt` digの実行例。 reply size limitの値が1424より大きいことを確認します。

大きなサイズのDNS応答を受け取れない場合の理由として、 IPフラグメンテーションの発生したパケットが届いていないことや、 IPパケットのリアセンブルが正常に行われていないことが考えられます。対処方法としては、以下が挙げられます。

キャッシュサーバからDNSルートサーバまでのPath MTUのサイズを確認する。
VPNやカプセリングなど、パケットのサイズが変わる箇所で、 IPフラグメンテーションが発生しないようにMTUサイズを調整する。
ファイアウォールなど、パケットのフィルタリングを行う箇所で、フラグメンテーションされたIPパケットがフィルタリングされないように設定することが考えられます。

3.2. 権威サーバの運用者

権威サーバでは対応の必要はありません。しかしユーザー側のDNSSEC検証の失敗により、自身の管理するドメイン名の名前解決ができなくなる可能性があります。そのため、ユーザーからの問い合わせ対応が必要になる場合があります。

3.3. システムインテグレータ

顧客のシステム内のDNSサーバやネットワーク機器の設定、運用状況を確認しておく必要があります。対応としては、上記1.および2.と同様です。

4. よくある質問と回答

Q. DNSサーバを運用していないのですが何か対応をする必要はありますか？

A. DNSサーバを運用していない方は、対応の必要はありません。ご利用中のDNSへの影響がお手元で確認された場合、キャッシュサーバや収容しているネットワークを運用されている方にお問い合わせください。

Q. 自宅のネットワークは関係ないと思いますが対応する必要はありますか？

A. ご自宅のネットワークでキャッシュサーバを運用していない場合には、対応の必要はありません。
一方、ご自宅のネットワークでキャッシュサーバを運用している場合には確認が必要になる場合があります。特にキャッシュサーバでDNSSEC検証を有効にする設定をしていないにも関わらず、 DNSSECに関する問い合わせを受けたときや、デフォルトでDNSSEC検証が有効になっている場合が挙げられます。
確認方法につきまして「3. 対象者別の確認と対処の方法」をご覧ください。

Q. IPv6のネットワークは関係ありますか？

A. IPv4では問題が無くIPv6で問題が発生したり、逆にIPv4で問題が発生してもIPv6で問題は無かったりといった例もありますので、 IPv4、IPv6を問わずに確認する事をお勧めします。 IPv6およびIPv4のネットワーク構築のために、 IPパケットのカプセル化を行っている場合などに大きくなったDNS応答を受信できない可能性が高くなります。
確認方法につきまして「3. 対象者別の確認と対処の方法」をご覧ください。

Q. 問題が発生したら誰に、何処に相談すればいいのですか？

A. キャッシュサーバを運用している管理者(組織内のシステム管理者、ネットワークの運用委託先、接続先ISP等)にお問い合わせください。

5. 関連リンク

初のKSKロールオーバー、成功裏に完了: https://www.icann.org/news/announcement-2018-10-15-en
ルートゾーンKSKロールオーバーが実施されました: https://www.nic.ad.jp/ja/topics/2018/20181012-01.html
間もなくルートゾーンKSKロールオーバーが実施されます(2018年10月10日): https://www.nic.ad.jp/ja/topics/2018/20181010-01.html
ICANN理事会がルートゾーンKSKロールオーバーの実施を承認(2018年9月19日): https://www.nic.ad.jp/ja/topics/2018/20180919-01.html
ルートゾーンKSKロールオーバーの対応はお済みですか？(2018年8月30日): https://blog.nic.ad.jp/blog/ksk-roll-update-2018-08/
DNS検証リゾルバにおける現在のトラストアンカーの確認(2018年6月3日): https://www.icann.org/resources/pages/dns-resolvers-checking-current-trust-anchors-2018-06-03-ja
最新のトラストアンカーによるDNS検証リゾルバの更新(2018年6月3日): https://www.icann.org/resources/pages/dns-resolvers-updating-latest-trust-anchor-2018-06-03-ja
KSKロールオーバー実施計画案に関する動き(2018年5月30日): https://blog.nic.ad.jp/blog/ksk-roll-update-2018-05/
ICANNがルートゾーンKSKロールオーバーの再開に向けた実施計画案を発表～パブリックコメントの募集も開始～(2018年2月2日): https://www.nic.ad.jp/ja/topics/2018/20180202-01.html
ICANNがルートゾーンKSKロールオーバーに関するアップデートを発表(2017年12月19日): https://www.nic.ad.jp/ja/topics/2017/20171219-01.html
JPNIC Blog :: 延期となったKSKロールオーバーについて(2017年10月25日): https://blog.nic.ad.jp/blog/postponed-ksk-rollover/
JPNIC News & Views vol.1516【定期号】特集:DNS運用者以外にも幅広い影響があります！～DNSSEC導入後初のルートゾーンKSKロールオーバー実施～(2017年7月18日): https://www.nic.ad.jp/ja/mailmagazine/backnumber/2017/vol1516.html
ネット史上初めての「KSKロールオーバー」が始まる、名前解決できなくなる前にDNSサーバなど設定確認を！　今年9月は特に注意(2017年6月22日): http://internet.watch.impress.co.jp/docs/special/1066659.html
DNSSECバリデーションにおけるルートゾーンKSKロールオーバーに関する重要なお知らせ(2017年5月31日): https://www.nic.ad.jp/ja/topics/2017/20170531-02.html
ルートゾーンKSKのロールオーバー - ICANN (2017年5月31日): https://www.icann.org/resources/pages/ksk-rollover-2017-05-31-ja