DigiLoog

PC関係の事なら何でもいけるそんな処

Archive for the ‘Linux’ Category

OpenDMARCをアップグレードしたらレポート生成出来なくなった

2021年10月03日(日) - 21:34 | カテゴリ: Linux

自宅サーバのメールゲートウェイでは、OpenDMARCを使ってDMARCレポートを生成しているのだが、
OpenDMARCをv1.3からv1.4にアップグレードしたら、レポート生成時にエラーが出力される様になった。

実際に出力されたエラーログのサマリは次の通り。最初はDBが壊れたと思った (´・ω・`)

opendmarc-reports: can't extract report for domain example.com: Unknown column 'messages.arc' in 'field list'
opendmarc-expire: DELETE failed: Table 'opendmarc.arcauthresults' doesn't exist

DBにカラムが足りなそうだったので、リリースノートと公式ドキュメントを確認した所、
OpenDMARC v1.4.0でARC(Authenticated Received Chain)にも対応した影響で、
生成するレポート用データのフォーマットとDBカラムが変更になった様だった。

1.4.0 Add ARC support ... Update SQL schema to support new porting functionality for DKIM selectors

OpenDMARC v1.3以下はARCに対応していないので、当然ながらデータベースもARCを想定していない。
その為、v1.3.X以下を利用している環境をアップグレードした場合は追加されたARCカラムが存在しないので、
レポート生成データを格納するデータベースに情報をinsert出来ずエラーとなる。

比較的簡単なテーブル構造なので人力でカラムを追加しても解決出来るのだが、
今回はデータを格納しているデータベースを一度初期化してデータを作り直す事に。
生成したDMARCレポートは別の方法でバックアップしているので、
カラムを弄って整合性を崩すよりも一から作り直した方が安全と判断した。

作り直した後はエラーも発生せずにレポートを生成が出来ており従来通りの機能を使えている。
当面は自宅サーバでメール送受信をし続けるので、
コア機能のコンポーネントアップグレードには気を付けねばと改めて実感する出来事だった。



バックボーン管理鯖をopenSUSE 15.3にアップグレードした

2021年09月11日(土) - 23:54 | カテゴリ: Linux

ns-lab BBでは色んなLinuxディストリビューションを使う事でシステムが偏らないようにしている。
バックボーン設備も例に漏れずマルチディストリビューション構成なのだが、
その中でもDHCP兼バックボーン管理サーバを兼ねているopenSUSE 15.2をそのままにしていた。

冗長化していると言ってもDHCPサーバが止まるとPCや無線接続スマホが通信出来なくなるので、
慎重にアップグレードする必要があったのと、
自作プログラムも動いているので慎重にアップグレードする必要があった。

最近は毎週末がバタバタしていたのだが今日だけはなんとか時間を確保出来たので、
DHCP兼バックボーン管理サーバを、openSUSE 15.2からopenSUSE 15.3にアップグレードしてみた。


os-releaseも15.3に切り替わっていた。



DNSSEC検証が原因で名前解決が不安定になった

2021年07月09日(金) - 22:00 | カテゴリ: Linux

自宅のキャッシュ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は今回の様な問題が出る事がある上、
問題が出た時のデバッグに時間がかかるのが辛い所。
常用しているからこそ分かった事例なので、似たような事が起きたら今後も都度メモしようと思う。



  • 応援中

    けもの道☆ガーリッシュスクエア
    プリンセス☆シスターズ!