DigiLoog

自宅のキャッシュDNSサーバではDNSSECのレコード署名を検証していたが、
一部ドメインや特殊構成のgTLDで名前解決が失敗する事に気づいた。

DNSSECについてはJPNICが解説しているのでそちらを参照。
権威DNSとレコード応答の正当性を検証する仕組みなので、
クエリや応答を暗号化する物では無い点に注意。
このレコード署名検証が失敗すると、不正な権威DNSからの応答と判断してSERVFAILする。

自宅のDNSサーバは、サーバ自身で名前解決を行うインターネットに接続したキャッシュDNS(親)と、
PCやスマホからのDNSクエリを一次受けして、
上位の親DNSに再転送するキャッシュDNS(子)で多段にしている。
今回は親・子の両キャッシュDNSサーバにBINDを使った上、dnssec-validationを有効化したら、
DNSSEC検証が失敗するドメインが出てきた。

………

確認出来たのはOpenSUSEのリポジトリとシャープのWebサイト。
良くある事なのでEDNS0やTCPフォールバックあたりを怪しんでログ調査していたが、
切り分けたら4KB近いDNSクエリでも正常に受信出来ていたのと、
一部ドメインのみで問題が出ており大多数はDNSSECも名前解決出来ていたので調査が難航した。

1週間程度格闘し、digコマンドにバッファ拡張オプションをつけたり、
cdflagでDNSSEC検証を無効化してわかったのは、次の5個を満たしている時に起こる場合がある点。

1. キャッシュDNSをforwardとroothintの多段構成にしている
2. DNSSECレコード署名検証を2台とも有効化している
3. 名前解決対象のFQDNがCNAMEを返す
4. CNAME先が別ドメイン
5. CNAME先のドメインでサブドメイン委任していない

5番目は実際に権威DNSを運用している人ならわかる内容だが、
本番運用ではサブドメイン委任をせず親ドメインのゾーンにサブドメインのレコードを書く場合がある。
今回はキャッシュDNSが少し特殊な構成なのと権威DNSのサブドメイン委任も特殊だったので、
DNSSECのレコード署名検証で不整合と判断されたのかもしれない。

………

流石に権威DNSに手を出す事は出来ないのと名前解決が出来ないのは少し困るので、
キャッシュDNSでdnssec-validationを無効化する事にした。

本来はNTAsを設定して逃げるのが筋だと思うが、
BINDでNTAsを設定しても最長1週間しか維持できないので常用は難しいと判断。
ちなみに、UnboundならNTAsで常時除外も出来るが、検証はBIND環境の話なのでそもそも出来なかった。

発展途上であるDNSSECは今回の様な問題が出る事がある上、
問題が出た時のデバッグに時間がかかるのが辛い所。
常用しているからこそ分かった事例なので、似たような事が起きたら今後も都度メモしようと思う。

ロードバランサ兼リバースプロキシとして利用しているサーバでは、
仮想IPの管理にCentOS8のAppStreamで配布しているバージョンのkeepalivedを走らせていた。
今まで不具合も出ずに動いていたので普段通りにOSのアップグレードを実行したら、
想定外の仮想IPが割り当たらなくなる不具合に当たった。

“ns-lab BB”のロードバランサ構成は以前書いた紹介記事を読んで貰えばわかるが、
一応説明を書くと、NICを2個接続してインライン構成にしつつ、
それぞれのNICでVRRPv3を喋ってIPv4・IPv6仮想IPを付与する構成となる。

今回の問題が発生したのは2021/06/04の早朝。
上に書いた通りパッケージのアップグレードを実施したら、
プライベートIPを付与しているNIC(eth0)側のIPv4のみ仮想IPが突然消えた。
ログは何も出ていなかったのでパケットを見たが正常にパケットは飛んできていた。
straceを読む余裕が無かったので不明だが、恐らく仮想IPを渡す所で不具合が発生したのでは無いかと思われる。

今までサーバを運用してきた直感だと、IPv6 Duplicate Address Detection・Non Local Bindあたりが怪しかった。
その上でデバッグログを有効化したりしてみたら、それっぽいログが出ていた事が判明。

Jun 4 07:04:54 server ***: (eth0-ipv4) removing VIPs.
Jun 4 07:04:54 server ***: (eth0-ipv6) removing VIPs.
Jun 4 07:04:54 server ***: (eth1-ipv4) removing VIPs.
Jun 4 07:04:54 server ***: (eth1-ipv6) removing VIPs.
Jun 4 07:04:54 server ***: bind unicast_src Unicast-IPv6 failed 22 - Invalid argument
Jun 4 07:04:54 server ***: (eth0-ipv6): entering FAULT state (src address not configured)
Jun 4 07:04:54 server ***: (eth0-ipv6) Entering FAULT STATE
Jun 4 07:04:54 server ***: VRRP_Group(eth0-vip) Syncing instances to FAULT state
Jun 4 07:04:54 server ***: (eth0-ipv4) Entering FAULT STATE
Jun 4 07:04:54 server ***: VRRP sockpool: [ifindex(  2), family(IPv4), proto(112), fd(14,15), unicast, address(Private-IPv4)]
Jun 4 07:04:54 server ***: VRRP sockpool: [ifindex(  2), family(IPv6), proto(112), fd(-1,-1), unicast, address(Unicast-IPv6)]
Jun 4 07:04:54 server ***: VRRP sockpool: [ifindex(  3), family(IPv4), proto(112), fd(16,17), unicast, address(Global-IPv4)]
Jun 4 07:04:54 server ***: VRRP sockpool: [ifindex(  3), family(IPv6), proto(112), fd(18,19), unicast, address(Unicast-IPv6)]
Jun 4 07:04:54 server ***: VRRP_Script(healthcheck) succeeded

keepalivedでvrrp_sync_groupやtrack_interfaceは入れてあるのでエラーが出ているIPv6が落ちるのは判るが、
IPv4・IPv6の片方だけ生き残るのは想定外だった。

今回は復旧優先という事もあり、IPv6 DADの無効化を入れつつkeepalivedをソースビルドに変更して復旧させた。
サービスのハブとなっているサーバなので冗長化していたのだが、まさか冗長化部分が壊れるのは想定外。
根本的な原因は不明だが、アプリケーションアップグレードのレアケースとして良い経験になった。

2021年5月17日にzabbix 5.4が公開されたので、自宅の監視サーバもアップグレードしてみた。
いつも通りにソースコードからビルドしたが、v5.0・v5.2系統と同じソースビルドが行えた。

インストール後の初回起動時にはデータベースのアップグレードが実行されるので、
サーバプロセスの立ち上げに時間を要する。
アップグレード状況は、zabbix-serverやzabbix-proxyのシステムログに出力される。

という事でアップグレードした結果はこちら。フッター部分のzabbixバージョンが5.4.0に上がった。

今回のバージョンで大きな変更は2つ。
1個目は、zabbixのスクリーン機能が廃止されてダッシュボードに機能統合された事。
スクリーンの方でピクセル単位のレイアウトデザインを実施していると、
ダッシュボード統合時に崩れるので注意しておいた方が良いかもしれない。
2個目は、トリガー条件などの評価式や演算子が変わった事。
筆者の環境では問題が生じなかったが、細かい条件を組んでいる環境ではこちらも確認した方が良い。

今回はトラブル無く普通にアップグレード出来たのでナレッジ的な事は書けないが、
ある意味、安全にアップグレード出来るバージョンとも言える。
ポイントリリースを毎回追いかけている人は少ないと思うが、
迷っている人はアップグレードして試してみると良いと思う。