FreeBSD - メンテナンス・トラブルシュート - DNS - ルートゾーン KSK ロールオーバー - 2017年の出来事

1.　概要

2.　簡単な内容

3.　DNS 応答サイズの確認

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

5.　トラストアンカーの更新

6.　経過報告

1.　概要

　今 (2017年8月3日) まで気づいてなかったのが迂闊なのですが。

　ある企業に勤めている、かつての部下からの連絡で知ったのだ。

　「総務省からメールが来てるんですが、「DNS」のルートサーバの鍵ファイルが変わるらしいんですけど。
　「DNS」サーバの設定を変更する必要があるかご存知ですか？」

　ほえぇぇ。知らなかった。で、あわくっていろいろと調べてみているのです。


　総務省の広報が「DNSの世界的な運用変更に伴うキャッシュDNSサーバーの設定更新の必要性」にあります。

　JPRS の「DNS関連技術情報」該当記事が「ルートゾーンKSKロールオーバーによる影響とその確認方法について」になります。

　JPNIC 日本ネットワークインフォメーションセンター の該当記事が「KSKロールオーバーについて」となっています。

2.　簡単な内容

　完全に理解しているわけではないのですが、内容とわたしの理解で言うとこうだ。

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

　DNS キャッシュサーバは、対応していなければ、何らかの対応を行う必要がある(らしい)。
　DNS コンテンツサーバは、基本的には対応不要(らしい)。

3.　DNS 応答サイズの確認

　DNS の応答サイズが大きくても (1424バイト超) 正常に受信できるかを確認します。

[ブラウザによる確認]

　ブラウザが動作するマシンであれば、あるサイトにアクセスして（リンク切れになってしまいました）。
　以下のように右端の４つの枠が「PASS」の緑表示になっていれば OK。 (一番下の枠は必ず「FAIL」赤になります)

[dig による確認]

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


> 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。


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

　キャッシュサーバに使用しているアプリケーションのバージョンが古い場合は、最新バージョンにしておきましょう。

　「bind」を使用している場合は以下を確認


named.conf


　で


edns no        を設定していないこと
max-udp-size   に小さい値を設定していないこと
edns-udp-size  に小さい値を設定していないこと


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


unboud.conf


　で


edns no        を設定していないこと
max-udp-size   に小さい値を設定していないこと
edns-udp-size  に小さい値を設定していないこと


5.　トラストアンカーの更新

　「JPNIC」に「bind」、「unbound」それぞれ、手動で更新する方法が紹介されていますのでそちらをご参照ください。
　「bind」で自動更新を有効にする方法も記述されていますのでそちらをご参照ください。

　「unbound」を使用している場合、下記の方法で自動更新を有効にすることをお勧めします。


unboud.conf


　に


auto-trust-anchor-file: "/ディレクトリ/unbound/root.key"


　と記述している箇所があるはずです。(ディレクトリ名はサーバの環境により異なります)
　上記の箇所がコメントアウトされていれば、コメントを外します。
　その上で、「unbound」を再起動します。
　再起動後に


root.key


　を「cat」で見てみたら


;;last_queried: [大きな数字] ;;[再起動した日時]
;;last_success: [大きな数字] ;;[再起動した日時]


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

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

6.　経過報告

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