メインコンテンツへジャンプする

JPNICはインターネットの円滑な運営を支えるための組織です
文字サイズ:
プリント用ページ

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

2017年11月1日更新

バナー:KSKロールオーバー

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

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

0. 何が起きるか

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

1. 概要

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

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

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

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

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

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

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

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

図: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の実行例
    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. 関連リンク

JPNIC Blog :: 延期となったKSKロールオーバーについて
https://blog.nic.ad.jp/blog/postponed-ksk-rollover/
JPNIC News & Views vol.1516【定期号】特集:DNS運用者以外にも幅広い影響があります! ~DNSSEC導入後初のルートゾーンKSKロールオーバー実施~
https://www.nic.ad.jp/ja/mailmagazine/backnumber/2017/vol1516.html
ネット史上初めての「KSKロールオーバー」が始まる、名前解決できなくなる前にDNSサーバなど設定確認を! 今年9月は特に注意
http://internet.watch.impress.co.jp/docs/special/1066659.html
DNSSECバリデーションにおけるルートゾーンKSKロールオーバーに関する重要なお知らせ
https://www.nic.ad.jp/ja/topics/2017/20170531-02.html
ルートゾーンKSKのロールオーバー - ICANN
https://www.icann.org/resources/pages/ksk-rollover-2017-05-31-ja

JPNICで翻訳したICANN文書

三分でわかるKSKロールオーバーについて
https://www.nic.ad.jp/ja/translation/icann/2016/20160722.html
KSKロールオーバー:よくあるご質問と回答
https://www.nic.ad.jp/ja/translation/icann/2017/20170518.html

このページを評価してください

このWebページは役に立ちましたか?
ページの改良点等がございましたら自由にご記入ください。

このフォームをご利用した場合、ご連絡先の記入がないと、 回答を差し上げられません。 回答が必要な場合は、お問い合わせ先をご利用ください。