1. ルートゾーンKSK/日本では
| /DNSKEY /JPCERT /JPNIC /JPRS /Microsoftサポートblog /asahi /dns-oarc.net /e-ontap /itmedia /janog39 /named.conf /nisc /open-resolver調査 /watch /お騒がせ見出し /伝言ゲーム /総務省 |
Contents
ICANN公式ページはこれ： https://www.icann.org/resources/pages/ksk-rollover /icann
ルートゾーンKSKのロールオーバー(日本語） https://www.icann.org/resources/pages/ksk-rollover-2017-05-31-ja
https://www.icann.org/news/announcement-2017-09-27-ja (延期されたのは新KSKでの署名)
どちらも、フラグメント問題には触れられていない。だが、... /DNSKEY
1.1. 日本では
署名延期はほとんど話題にならず、当日を過ぎてもなんの騒ぎもtweetもなかった。
- まったく影響がない、つまりDNSSECは使われていない、あるいはDNSにも関心がない、ということか。
-- ToshinoriMaeno 2017-10-12 23:21:22
誰を相手にした説明なのか、それが問題だ。(落語が作れそうな）
現在、多くのフルリゾルバーではDNSSEC検証を有効にしていない場合もDNSSEC署名を...
/伝言ゲーム /itmedia /asahi /JPNIC /JPCERT
/Microsoftサポートblogがすっきりしている。 Windows の DNS サーバー上での対策の必要性 (必要なしw) https://blogs.technet.microsoft.com/jpntsblog/2017/08/09/dnssec/
1.2. FAQ
Q. DNSSECを使っていないのに、なぜKSKロールオーバーに対応しなければいけないのか。 Q. DNSSECを使いたくないのに、DNSSEC検証を有効にしなければ名前解決できなくなるのか。 （これは総務省のFUDらしい。） Q. DNSSECを使っていないのに、DNS返答が大きくなるというのは本当か。
- これらの対する返答はすべてノーです。
影響の大きいのは/総務省の発表だ。(DNSSECを使っていなくても影響があると言っているようだ。）-- ToshinoriMaeno 2017-07-28 22:57:08 DNSとDNSSECを区別していないのは意図的らしい。-- ToshinoriMaeno 2017-08-09 10:40:17
結論：DNSSECを使っていなければ、影響はない。-- ToshinoriMaeno 2017-08-01 22:48:49
- BINDであれば、dnssec-validate no; optionがあればいいらしい。(defaultは?)
- Unboundも同種の設定があるらしいが、詳細は不明。
- Knot resolver はdnssec moduleを入れなければいいようだ。
つまり、お騒がせな発表が多いということ。(総務省のはそれを意図しているという伝聞もある）
/e-ontap : http://www.e-ontap.com/blog/20170807.html
DNSSECの仕組みとKSKロールオーバへの対応 http://www.e-ontap.com/dns/DNSSEC-seminar2017.pdf
/JPNIC 更新： https://www.nic.ad.jp/ja/dns/ksk-rollover/
https://www.nic.ad.jp/ja/topics/2017/20170531-02.html
現状での解釈 -- ToshinoriMaeno 2017-07-28 13:20:38
「DNSSEC検証の有無に関わらず」という表現(DNSSECのBIND用語を知らないひとには誤解される表現)が 「DNSSECを無効にしていても」影響を受けるという表現(誤報)に変化して伝わっている。
まさに伝言ゲームだ。
大部分のキャッシュサーバーがDNSSEC enable状態であれば、実害は少ないのだが、 私のようにDNSSECをまったく使っていないものには大きな迷惑だ。:-< -- ToshinoriMaeno 2017-07-28 13:42:59
(これも表はDNSSECではなく、DNSと言っている。しかも「運用変更」だって。）
NISC ＤＮＳの世界的な運用変更に伴うキャッシュＤＮＳサーバーの設定更新の必要性について
- - 内閣官房内閣サイバーセキュリティセンター（ＮＩＳＣ）
https://www.nisc.go.jp/active/kihon/dns_taisaku.html (キャッシュＤＮＳサーバーを運用する方宛）
https://www.nisc.go.jp/active/general/pdf/taisaku_170718.pdf
※DNSSECを無効にしている方も下記影響・対応の②についてご確認ください。 影響 ①検索結果の正当性が確認できなくなり利用者のネット利用に不具合が生じる。 ②検索結果の受信データ量(UDPメッセージサイズ)が増大することから、 利用者のネット利用に不具合が生じる可能性がある。
- この部分がなにを指しているのか、不明。にもかかわらず、しっかりと警告している。
なお本年9月19日までに必要な処置が講じられない場合、 Webアクセスやメール送信などができない利用者が生じる可能性があります。
パニックを起こしたいのだろうか。-- ToshinoriMaeno 2017-07-27 02:12:54
ＤＮＳの世界的な運用変更に伴い必要となる対策について www.nisc.go.jp/conference/cs/taisaku/ciso/dai13/.../13shiryou03.pd...
- 総務省資料平成２９年７月１４日
1.3. JANOG
- DNSSECに関する最近の話題として、取り上げられている。4-2 節か。
現在、多くのフルリゾルバーではDNSSEC検証を有効にしていない場合もDNSSEC署名月の応答を受けとっているため、 今回のKSKロールオーバーによる影響を、該当するすべてのフルリゾルバーにおいて考慮する必要がある。
フラグメント化に関連して、DNSSECを使っていなくても問題が起きるという風説がある。
/janog39 1月20日 JPRS 米谷
「KSKロールオーバーとは関係なく、大きいパケットの問題がある」、という意味なら正しい。
「KSKロールオーバーが原因で、DNSSECを使っていなくてもフラグメント化問題が起きる」という説は怪しい。
フルリゾルバーはDNSSEC検証の有無に関わらずDNSKEYを取得しているため
これを追跡している。-- ToshinoriMaeno 2017-07-23 23:16:54
- BINDとUnboundはこういう動作をするらしい。
1.4. internetweek
ルートゾーンのKSKロールオーバーについて(ISPから見た事前確認・準備のポイント) 末松慶文 2017年6月1日 Internet Week ショーケース @名古屋
https://internetweek.jp/sc-program/day1-suematsu.pdf /末松
「KSKロールオーバー」に伴い講ずべき措置、総務省が国内関係者に告知、 9月19日以降にウェブアクセスやメール送信ができなくなる場合も
- 岩崎 宰守 2017年7月24日 18:26
http://internet.watch.impress.co.jp/docs/news/1072181.html
- 総務省の告知の紹介だが、問題のある記述の部分は飛ばしている。
-- ToshinoriMaeno 2017-07-28 22:53:54
1.5. bind
bind resolver はdefault で
dnssec-enable yes;
1.6. unbound
Unbound: Howto Turn Off DNSSEC http://www.unbound.net/documentation/howto_turnoff_dnssec.html
Please be warned, do not take disabling DNSSEC lightly, it may make you vulnerable to certain kinds of attacks.
ここに書かれた設定を行っても、DNSSECをすべて使わなくなるわけではなさそう。:-<
1.7. internet.watch
/watch --- 小山 祐司（一般社団法人日本ネットワークインフォメーションセンター） 2017年6月22日 12:00 「Internet Weekショーケース in 名古屋」の発表から http://internet.watch.impress.co.jp/docs/special/1066659.html
「うちはDNSSECを使っていないから大丈夫」と侮るなかれ。DNSSECを利用していなくても影響を受けるのだ。 DNSSEC検証の有効・無効問わず、名前解決ができなくなる
自分が使っているリゾルバー(キャッシュサーバー)がDNSSECを使っていれば、影響を受ける可能性はある。 と言いたいのであれば、そこは正しい。-- ToshinoriMaeno 2017-07-23 23:12:29
だが、それがKSK変更がらみのフラグメント化が理由なのか。
以下は間違いだ。検証は簡単ではない。-- ToshinoriMaeno 2017-07-23 23:07:54
IPフラグメントで名前解決に成功するかしないかは、次の方法で簡単に確認できるとのことだ。 DNSパケットが通るすべての通信経路を確認して、可能な範囲で検証することが必要である。
コマンドラインでの確認方法: dig +bufsize=4096 +short rs.dns-oarc.net txt
- これがなにをやっているか、分かるひとであれば、問題は少ないだろう。
-- ToshinoriMaeno 2017-07-23 01:35:46
1.8. 総務省
DNSにおける電子署名鍵の更改について 平成２９年7月１４日 総務省総合通信基盤局データ通信課
https://www.nisc.go.jp/conference/cs/taisaku/ciso/dai13/pdf/13shiryou03.pdf
- ２．対応が必要となる者
- DNSを用いた検索を実際に行う「キャッシュDNSサーバー」の運用者全て
これに含まれるNISCの資料に疑問がある。
これか： 9/15ページ
○ また、ルートKSKの円滑な更改のために、一時的に新旧両方のKSK公開鍵を送信する期間がある。 当該期間は、送信されるデータ量が増大し、IPフラグメントが生じることがある ※ISP等の事業者は、自らのDNSの応答に係る経路上の機器の設定が IPフラグメントに対応可能か否かを事前に確認しておく必要がある
DNSSECを利用するリゾルバーの話だ。
「ルートDNSサーバーの挙動」についてもおかしな記述がある。 ???
※ なお、ルートDNSサーバーは、応答相手のDNSSEC対応・非対応に関わらず公開鍵情報を送信してしまうため、 DNSSEC非対応の機器についてもIPフラグメントによる問題が生じる可能がある。
この部分がおかしい。DNSの動作を理解していないひとが書いたものか。
- DNSKEYを問い合わせているわけではないのに、DNSKEYが返ってくることは考えづらい。観測したことはない。
一方で、こんな記述もある。
フルリゾルバーはDNSSEC検証の有無に関わらずDNSKEYを取得している
ところで、10/15ページにはこうある。
- クイックガイド:ルートKSKロールオーバーに向けたシステムの準備 (ICANNの説明）
DNSSECを使用していない場合、システムはロールオーバーの影響を受けません。
ルートサーバーのDNSKEYリソースレコード（DNSKEY RR）の応答サイズが増加します。
http://www.soumu.go.jp/main_content/000497803.pdf
- 不完全な資料
1.9. JPRS
2017年6月1日Internet Weekショーケースin名古屋 https://internetweek.jp/sc-program/day1-yoneya.pdf
米谷嘉朗 2017年6月28日 DNSOPS.JP DNS Summer Day https://dnsops.jp/event/20170628/20170628-RootKSKRO-02.pdf
- スライド 9/16
影響を受ける対象者とその影響 • フルリゾルバー運用者 – 応答サイズが増加したDNSKEYがIPフラグメントにより受け取れなくなる可能性がある • DNSSEC検証の有効・無効に関係なし • DNSSEC検証を有効にしている場合、DNSKEYが受け取れないとすべてのDNSSEC検証が失敗し名前解決できなくなる
- ここのふたつ目の記述がおかしい。「DNSSEC検証」がなにを指すか、が問題なのかも。
DNSSECを使っていないひとに分かるように書いてないのが最大の問題だ。-- ToshinoriMaeno 2017-07-26 06:15:41
ルートゾーンKSKロールオーバーによる影響とその確認方法について
- 株式会社日本レジストリサービス（JPRS） 初版作成 2017/07/10（Mon）
https://jprs.jp/tech/notice/2017-07-10-root-zone-ksk-rollover.html
ルートゾーンKSKロールオーバーの一部のステップにおいて、ルートサーバー のDNSKEYリソースレコード（DNSKEY RR）の応答サイズが増加します。 これによりIPフラグメントが発生し、DNS応答を正しく受け取れなくなる可能性があります。 なお、その可能性はDNSSEC検証の有効・無効には関係ありません。
- 最後の文がどういう意味なのか。なにか、誤解があるのではないか。
- IPフラグメントが発生する理由はroot zone KSK変更だけが理由ではない。
- DNSSECの利用が発生条件ではないのは確かだが、誤解を招く表現だ。
- DNSKEYが関係するのはDNSSECを使っている場合であろう。
- IPフラグメントが発生したから、返答が受け取れなくなるというものでもない。
- ルートゾーンKSKロールオーバーの概要と影響の確認方法
<https://jprs.jp/tech/notice/2017-07-10-root-zone-ksk-rollover.pdf>
- ルートゾーンKSKロールオーバーの概要と影響の確認方法
1.10. JPNIC
最終更新2017年5月31日 https://www.nic.ad.jp/ja/translation/icann/2016/20160722.html
- 「DNSSECバリデーションを行っているリゾルバーを利用している人が影響を受ける」は正しい。
1.10.1. 影響
影響があるのはどういう場合なのかの説明がない。
これによりIPフラグメントが発生し、DNS応答を正しく受け取れなくなる可能性があります。 なお、その可能性はDNSSEC検証の有効・無効には関係ありません。
この記述がおかしい。誤解されている。
- DNSSECを使っていないリゾルバーにまで影響するように読めてしまいます。
- 「DNSSEC検証を無効」にしていると影響するのだろうか。 root server情報をpriming操作するときに、DNSSEC利用の有無に関係なく、 DNSKEYを検索するリゾルバーがあるらしい。
-- ToshinoriMaeno 2017-07-21 23:25:42
DNSの応答の「IPフラグメントが発生する」のはKSKロールオーバーだけではない。
- DNSSECを使っていれば、発生している可能性は以前からある。
-- ToshinoriMaeno 2017-07-23 11:49:00
▼重要日付（ステップ開始日）と継続期間
・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バイトに増加
1.11. 以下、あわてふためく様子
なぜこれが「DNS運用の大規模変更」というタイトルになるのだろう。
ＤＮＳの世界的な運用変更
DNSが使えなくなるトラブル、9月19日に発生する恐れ：ITpro
ＤＮＳの世界的な運用変更に伴うキャッシュＤＮＳサーバーの設定更新の必要性について - 内閣官房内閣サイバーセキュリティセンター（ＮＩＳＣ）
総務省(NISCの受け売りならまだ良かったのに） http://www.soumu.go.jp/menu_news/s-news/02kiban04_04000212.html
https://japan.zdnet.com/article/35104517/
この影響を受ける恐れがあるのは、 インターネットサービス事業者などキャッシュDNSサーバの全ての運用者とされるが、 状況によってはDNSSECを導入していない場合や、 企業や学校などのネットワークにも及ぶ可能性があるとされる。
2017年08月03日 何をするべき？9月に迫るDNSの世界的な運用変更 https://cloudadvisor.jp/blog/dnssec_update
1.12. 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: