DigiLoog

筆者がL2SWを買うとしたら、
サーバやルータを大量に接続する為に24ポート以上のスイッチを買う事が多かった。
直近でL2SWが必要になったので、同様に24ポートスイッチを買おうと思っていたのだが、
以前から弄ってみたかった2960-CXを通常よりも安く入手する事が出来た。

新しいNW機器を購入したら分解して中身を確認したくなる人種なので、
今回購入したCisco Catalyst 2960-CXも分解してみた。

傷やポート変形があるので少し安い値段でゲット。
12ポートスイッチはあまり買わないのだが値段に惹かれたので購入。
利用用途も当面は少ポート数で足りる可能性が高かったので上手く合致した。

自宅のキャッシュ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をソースビルドに変更して復旧させた。
サービスのハブとなっているサーバなので冗長化していたのだが、まさか冗長化部分が壊れるのは想定外。
根本的な原因は不明だが、アプリケーションアップグレードのレアケースとして良い経験になった。