1. ルートゾーンKSK

/DNSKEY   /DNSSEC-bind   /ICANN   /ICANN-David   /ISC-BIND   /JPNIC   /JPRS   /dnskey_query   /priming   /ヤマハ   /日本では   /設定検査  

2018年10月になる。https://www.icann.org/news/blog/update-on-the-root-ksk-rollover-project

Contents

  1. ルートゾーンKSK
    1. サイトの見解
    2. この先を読む必要はありません
  2. ICANN
  3. ISC-BIND
  4. 日本では
    1. 総務省
    2. JPRS
    3. JPNIC
  5. 影響の説明不足
    1. primingとは
    2. ietf dnsops
DNSSECを使っていなければ、影響はありません。

/ICANNの説明にもあります。

/ICANN-David

https://indico.dns-oarc.net/event/27/session/5/contribution/21/material/slides/0.html

1.1. サイトの見解

 1. DNSSECを使っていないのであれば、原則対応は不要です。
  検証していないのに勝手に大きなパケットが送られてくることもありません。

 2. DNSSEC検証するように設定する必要なんてまったくありません。

 3. DNSSECを使っているなら、ICANNのページを見て、設定を確認すること。

 4. 大きなUDPパケットを受け取るようにする必要はありません。
　　DNSSECを使っていれば、長いDNS返答が送られてくることはあり得ます。
　　　それでも大きなUDPパケットを受け取れるように設定する必要はありません。（難しい）
　　[[DNS/毒盛]]される危険性を増やします。

DNS/TCPで問い合わせができることを確認しておくといいでしょう。 -- ToshinoriMaeno 2017-08-06 06:59:30

1.2. この先を読む必要はありません

/JPRSの追加説明が物語っている。 https://jprs.jp/tech/notice/2017-08-10-root-zone-ksk-rollover-qa.html

こういう記事もありますが、ただのオオカミ少年です。 

「うちはDNSSECを使っていないから大丈夫」と侮るなかれ。
　DNSSECを利用していなくても影響を受けるのだ。

ルートゾーンのKey Signning Keyが初めて変更になることが理由です。 

root serverにDNSKEYを問い合わせた場合の返答が大きくなります。

大きな返答が返るのは9/19だけの話ではありません。（日程を確認すること） -- ToshinoriMaeno 2017-08-28 11:01:57

KSK変更を分からないひともこの先を読む必要はありません。

https://tools.ietf.org/html/rfc7583

2. ICANN

DNSSEC関連での重要な告知：/ICANN公式ページ https://www.icann.org/resources/pages/ksk-rollover

ルートゾーンKSKのロールオーバー(日本語） https://www.icann.org/resources/pages/ksk-rollover-2017-05-31-ja

JPNICが公開している翻訳 https://www.nic.ad.jp/ja/translation/icann/2017/20170518.html

どちらも、フラグメント問題には触れられていない。

https://www.icann.org/en/system/files/files/sac-063-en.pdf /sac

Automated Trust Anchor Update Testbed https://automated-ksk-test.research.icann.org/

Quikc Guide https://www.icann.org/en/system/files/files/ksk-rollover-quick-guide-prepare-systems-03apr17-en.pdf 

If you don’t use DNSSEC, your system will not be affected by the rolloover

APNIC : https://www.apnic.net/manage-ip/apnic-services/dnssec/keyroll

3. ISC-BIND

/ISC-BIND　/設定検査 

If you are running authoritative services with BIND, or a resolver that is not doing DNSSEC-validation,
you should not see an impact.

BINにかぎらず、DNSSEC validationを行っていなければ、影響はない。

4. 日本では

/日本ではもご覧ください。

/JPRS/DNSSECを使っていなくても問題が起きるという解説がある。/DNSSEC-bind

しかし、

これを追跡している。 /日本では を見てください。-- ToshinoriMaeno 2017-07-23 23:16:54

http://internet.watch.impress.co.jp/docs/special/1066659.html 

 「うちはDNSSECを使っていないから大丈夫」と侮るなかれ。DNSSECを利用していなくても影響を受けるのだ。
DNSSEC検証の有効・無効問わず、名前解決ができなくなる

4.1. 総務省

DNSにおける電子署名鍵の更改について
平成２９年7月１４日
総務省総合通信基盤局データ通信課

https://www.nisc.go.jp/conference/cs/taisaku/ciso/dai13/pdf/13shiryou03.pdf 

※ なお、ルートDNSサーバーは、応答相手のDNSSEC対応・非対応に関わらず公開鍵情報を送信してしまうため、
　　DNSSEC非対応の機器についてもIPフラグメントによる問題が生じる可能がある。

ところで、10/15ページにはこうある。 

DNSSECを使用していない場合、システムはロールオーバーの影響を受けません。

/icann.org-letter 

ルートサーバーのDNSKEYリソースレコード（DNSKEY RR）の応答サイズが増加します。

/dnskey_query

http://www.soumu.go.jp/main_content/000497803.pdf

4.2. JPRS

https://dnsops.jp/event/20170628/20170628-RootKSKRO-02.pdf 

影響を受ける対象者とその影響
 • フルリゾルバー運用者
  – 応答サイズが増加したDNSKEYがIPフラグメントにより受け取れなくなる可能性がある
 •  DNSSEC検証の有効・無効に関係なし
 •  DNSSEC検証を有効にしている場合、DNSKEYが受け取れないとすべてのDNSSEC検証が失敗し名前解決できなくなる

https://jprs.jp/tech/notice/2017-07-10-root-zone-ksk-rollover.html 

　　DNSSEC検証の有効・無効には関係ありません。

ルートゾーンKSKロールオーバーの概要と影響の確認方法 <https://jprs.jp/tech/notice/2017-07-10-root-zone-ksk-rollover.pdf>

4.3. JPNIC

https://www.nic.ad.jp/ja/translation/icann/2016/20160722.html

5. 影響の説明不足

影響があるのはどういう場合なのかの説明がない。 

これによりIPフラグメントが発生し、DNS応答を正しく受け取れなくなる可能性があります。
なお、その可能性はDNSSEC検証の有効・無効には関係ありません。

DNSの応答の「IPフラグメントが発生する」のはKSKロールオーバーだけではない。 -- ToshinoriMaeno 2017-07-23 23:54:15

▼重要日付（ステップ開始日）と継続期間 

  ・2017年9月19日～2017年10月11日（ZSKロールオーバーに伴う新ZSKの事前公開）
    ※この期間、DNSKEY RRの応答サイズが1414バイトに増加
  ・2017年10月11日（新KSKでの署名開始）
  ・2017年12月20日～2018年1月11日（ZSKロールオーバーに伴う新ZSKの事前公開）
    ※この期間、DNSKEY RRの応答サイズが1414バイトに増加
  ・2018年1月11日～2018年3月22日（現KSK（KSK-2010）の失効のための事後公開）
    ※この期間、DNSKEY RRの応答サイズが1424バイトに増加

ＤＮＳの世界的な運用変更に伴うキャッシュＤＮＳサーバーの設定更新の必要性について - 内閣官房内閣サイバーセキュリティセンター（ＮＩＳＣ） http://www.soumu.go.jp/menu_news/s-news/02kiban04_04000212.html

5.1. primingとは

https://kb.isc.org/article/AA-01309/0/Root-hints-a-collection-of-operational-and-configuration-FAQs.html

Does named ever refresh the primed roots? 

Yes - named will re-prime the roots that it has in cache if and when the last authoritative server for "." expires or is otherwise removed from cache.  Reasons why named may no longer have a set of authoritative servers for "." in cache include:

5.2. ietf dnsops

fragmentation とKSK rolloverとを結びつけた話は確認できていない。 -- ToshinoriMaeno 2017-07-23 23:54:15