15. ルートゾーン KSK ロールオーバー

 
15.1 能書き
15.2 簡単な内容
15.3 DNS 応答サイズの確認
15.4 DNS 応答サイズが小さかった場合
15.5 トラストアンカーの更新
15.6 経過報告

15.1 能書き

 今 (2017年8月3日) まで気づいてなかったのが迂闊なのですが。  ある企業に勤めている、かつての部下からの連絡で知ったのだ。  「総務省からメールが来てるんですが、DNS のルートサーバの鍵ファイルが変わるらしいんですけど。DNS サーバの設定を変更する必要があるかご存知ですか?」  ほえぇぇ。知らなかった。で、あわくっていろいろと調べてみているのです。  総務省の広報がこちら


 JPRS の「DNS関連技術情報」該当記事がこちら



 JPNIC 日本ネットワークインフォメーションセンター の該当記事がこちら


15.2 簡単な内容

 完全に理解しているわけではないのですが、内容とわたしの理解で言うとこうだ。  DNS ルートサーバ の公開鍵(KSK)はそもそもある程度の期間を置いたら更新するものである。  だが、2010年の DNSSEC 運用開始後、今日まで KSK の更新はなかったが、2016年10月から2018年3月にかけて更新を行うものである。  しかも、その更新において IPフラグメンテーション の発生するサイズ (1414~1424Bytes) の応答データが (1280bytes までは IPフラグメンテーションは発生しない(らしい)) 生まれるために DNS キャッシュサーバで、問題が生ずる可能性がある(らいい)。  DNS キャッシュサーバは、対応していなければ、何らかの対応を行う必要がある(らしい)。  DNS コンテンツサーバは、基本的には対応不要(らしい)。

15.3 DNS 応答サイズの確認

 DNS の応答サイズが大きくても (1424バイト超) 正常に受信できるかを確認します。 [ブラウザによる確認]  ブラウザが動作するマシンであれば下記のサイトにアクセスして

 以下のように右端の4つの枠が「PASS」の緑表示になっていれば OK。 (一番下の枠は必ず「FAIL」赤になります)



[dig による確認]

 dig が動作するのであれば (digbind の付属品なんですよね)

> dig +bufsize=4096 +short rs.dns-oarc.net txt

 の結果が

rst.x4090.rs.dns-oarc.net.
rst.x4058.x4090.rs.dns-oarc.net.
rst.x4064.x4058.x4090.rs.dns-oarc.net.
"... sent EDNS buffer size 4096"
"... DNS reply size limit is at least 4090"
"Tested at 2017-08-04 00:38:33 UTC"

 5行目の右端の数字が 1424 より大きければ OK。


[drill による確認]

drill -b 4096 rs.dns-oarc.net txt

 の結果が

;; ->>HEADER<<- opcode: QUERY, rcode: NOERROR, id: 8288
;; flags: qr rd ra ; QUERY: 1, ANSWER: 6, AUTHORITY: 1, ADDITIONAL: 0
;; QUESTION SECTION:
;; rs.dns-oarc.net.     IN      TXT

;; ANSWER SECTION:
rs.dns-oarc.net.        60      IN      CNAME rst.x4090.rs.dns-oarc.net.
rst.x4090.rs.dns-oarc.net.      59      IN    CNAME rst.x4058.x4090.rs.dns-oarc.net.
rst.x4058.x4090.rs.dns-oarc.net.        58    IN    CNAME rst.x4064.x4058.x4090.rs.dns-oarc.net.
rst.x4064.x4058.x4090.rs.dns-oarc.net.  57    IN    TXT   "... DNS reply size limit is at least 4090"
rst.x4064.x4058.x4090.rs.dns-oarc.net.  57    IN    TXT   "Tested at 2017-08-04 00:48:57 UTC"
rst.x4064.x4058.x4090.rs.dns-oarc.net.  57    IN    TXT   "... sent EDNS buffer size 4096"

;; AUTHORITY SECTION:
x4064.x4058.x4090.rs.dns-oarc.net.      57    IN    NS    ns00.x4064.x4058.x4090.rs.dns-oarc.net.

;; ADDITIONAL SECTION:

;; Query time: 1260 msec
;; EDNS: version 0; flags: ; udp: 4096
;; SERVER: ...
;; WHEN: Fri Aug  4 09:48:56 2017
;; MSG SIZE  rcvd: 300

 12行目の右端の数字が 1424 より大きければ OK。


15.4 DNS 応答サイズが小さかった場合

 キャッシュサーバに使用しているアプリケーションのバージョンが古い場合は、最新バージョンにしておきましょう。  bind を使用している場合は以下を確認
named.conf
 で
edns no        [を設定していないこと]
max-udp-size   [に小さい値を設定していないこと]
edns-udp-size  [に小さい値を設定していないこと]


 unbound を使用している場合は以下を確認

unboud.conf
 で
edns no        [を設定していないこと]
max-udp-size   [に小さい値を設定していないこと]
edns-udp-size  [に小さい値を設定していないこと]


15.5 トラストアンカーの更新

 JPNICbindunbound それぞれ、手動で更新する方法が紹介されていますのでそちらをご参照ください。  bind で自動更新を有効にする方法も記述されていますのでそちらをご参照ください。  unbound を使用している場合、下記の方法で自動更新を有効にすることをお勧めします。
unboud.conf
 に
auto-trust-anchor-file: "/ディレクトリ/unbound/root.key"

 と記述している箇所があるはずです。(ディレクトリ名はサーバの環境により異なります)

 上記の箇所がコメントアウトされていれば、コメントを外します。

 その上で、unbound を再起動します。

 再起動後に

root.key
 を cat で見てみたら
;;last_queried: [大きな数字] ;;[再起動した日時]
;;last_success: [大きな数字] ;;[再起動した日時]

 という行が表示されていれば、更新が機能しているはずです。

 あとは当面 2017年9月19日 に更新があるので、そのときに支障なく動作していれば、まずは一安心ということになります。

15.6 経過報告

 2017年9月28日現在(衆議院が解散しましたが・・・)、unbound は無事、動いているようですし、root.key も更新されているようです。  とりあえず、わたしの環境では、第一段階は通過したようです。