1. ルートゾーンKSK
2018年10月になる。https://www.icann.org/news/blog/update-on-the-root-ksk-rollover-project
Contents
DNSSECを使っていなければ、影響はありません。
/ICANNの説明にもあります。
/ヤマハ は珍しく、影響ないと言い切っている。:-) -- ToshinoriMaeno 2017-09-03 05:33:00
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
9/19近辺に返答が大きくなるのは、KSK更新というよりも、ZSK更新のせいと言った方がよさそう。-- ToshinoriMaeno 2017-09-19 23:55:05
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
- KSKの更新を必要とするのは誰かという観点から書かれているだけ。
3. 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
- KSKロールオーバーに関係なく、「フラグメント化パケットについての問題がある」、という意味なら間違いではない。
しかし、
- 「KSKロールオーバーが原因で、DNSSECを使っていなくてもフラグメント化問題が起きる」という説はかなり怪しい。
これを追跡している。 /日本では を見てください。-- ToshinoriMaeno 2017-07-23 23:16:54
http://internet.watch.impress.co.jp/docs/special/1066659.html
「うちはDNSSECを使っていないから大丈夫」と侮るなかれ。DNSSECを利用していなくても影響を受けるのだ。 DNSSEC検証の有効・無効問わず、名前解決ができなくなる
- この説明でも根拠は示されていない。(JPRSの受け売りか)
4.1. 総務省
DNSにおける電子署名鍵の更改について 平成29年7月14日 総務省総合通信基盤局データ通信課
https://www.nisc.go.jp/conference/cs/taisaku/ciso/dai13/pdf/13shiryou03.pdf
- 2.対応が必要となる者
- DNSを用いた検索を実際に行う「キャッシュDNSサーバー」の運用者全て
※ なお、ルートDNSサーバーは、応答相手のDNSSEC対応・非対応に関わらず公開鍵情報を送信してしまうため、 DNSSEC非対応の機器についてもIPフラグメントによる問題が生じる可能がある。
こういう事実は確認できていない。-- ToshinoriMaeno 2017-07-26 23:31:13
ところで、10/15ページにはこうある。
- クイックガイド:ルートKSKロールオーバーに向けたシステムの準備 (ICANNの説明)
DNSSECを使用していない場合、システムはロールオーバーの影響を受けません。
ルートサーバーのDNSKEYリソースレコード(DNSKEY RR)の応答サイズが増加します。
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バイトに増加
DNSの世界的な運用変更に伴うキャッシュDNSサーバーの設定更新の必要性について - 内閣官房内閣サイバーセキュリティセンター(NISC) http://www.soumu.go.jp/menu_news/s-news/02kiban04_04000212.html
5.1. primingとは
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