DNSSECのルートゾーンKSKロールオーバーについて、ロールオーバー前後でDNSの検索に支障が出ないよう、各所から通達が出ている。
ルートゾーンKSKロールオーバーによる影響とその確認方法について (JPRS)
KSKロールオーバーについて (JPNIC)
(2017/10月予定だった切り替えが延期され、現在は 2018/10/11 に予定されています)
1. 管理下の DNS キャッシュは DNSSEC 検証をしているか
DNS キャッシュサーバーを管理している場合は、一応気を付けたほうが良い。管理下の DNS キャッシュサーバーに対して、dig コマンドでDNSSEC 対応済みドメイン (例: jprs.jp) の情報を検索したときに、回答に ad フラグが付いていたら「キャッシュサーバーでDNSSEC署名検証が有効になっている」状態なので、更新後の鍵を設定してやる必要があるかもしれない。
adフラグが付いている例:
$ dig jprs.jp. @mydns.example.com
; <<>> DiG 9.10.3-P4-Ubuntu <<>> jprs.jp.
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 26772
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 1, AUTHORITY: 4, ADDITIONAL: 9
...
(参考: DNSSECチュートリアル~実践編~)
2. RHEL 7 / CentOS 7 + BIND の場合
named.confにデフォルトで以下の設定が入っていて、DNSSEC署名検証が有効になっている。
options { ... dnssec-enable yes; dnssec-validation yes; /* Path to ISC DLV key */ bindkeys-file "/etc/named.iscdlv.key"; managed-keys-directory "/var/named/dynamic"; ... }; ... include "/etc/named.root.key";
対処法1. パッケージアップデート
/etc/named.iscdlv.key と /etc/named.root.key に、ルートゾーンの鍵が入っている。パッケージバージョンがbind-9.9.4-38.4以降であれば、上記2ファイルに新しい鍵が追加されるので、bindのパッケージをアップデートしてしまうのが一番手っ取り早く安心できる方法ではある。
対処法2. 自動更新に任せる
9.9.4-38.3以前のパッケージを使っている場合でも、RFC5011 の自動更新に対応している。named を起動すると更新後の鍵は /var/named/dynamic/managed-keys.bind{,.jnl} として自動保存される。このため、特に何かをする必要はない。
# とはいえ、CVE-2017-3142、CVE-2017-3143への対処が9.9.4-38.5以降で行われているので、パッケージを更新した方が良い。
3. RHEL 7 / CentOS 7 + Unbound の場合
デフォルトの /var/lib/unbound/root.key には古い鍵しか入っていないが、/etc/unbound/unbound.conf に以下の記述があり、自動更新が有効になっている。
server: ... auto-trust-anchor-file: "/var/lib/unbound/root.key" ...
unbound のデーモンを起動すると、/var/lib/unbound/root.key に新しい鍵が追加される。
このため、これらの設定を変更していなければ、特に対処の必要はない。
4. 確認、その他
EDNS0を無効化していないこと、経路上でTCP53が通ること、フラグメントパケットが通ることも確認しておく。
大きなサイズの DNS 応答に対応できているかどうかは、DNS-OARCが確認用のレコードを用意してくれているので、以下の dig コマンドで確認できる。
$ dig +bufsize=4096 +short rs.dns-oarc.net txt
非対応のキャッシュサーバだと、以下のような回答が返ってくる。
rst.x476.rs.dns-oarc.net. rst.x485.x476.rs.dns-oarc.net. rst.x490.x485.x476.rs.dns-oarc.net. "203.0.113.1 DNS reply size limit is at least 490" "203.0.113.1 lacks EDNS, defaults to 512" "Tested at 2017-08-31 01:19:47 UTC"