DNS関連のトラブル事例：ミス、地雷編

こんにちは、m//t です。
毎日暑いですね。職場近くの蝉たちも賑やかすぎて……

という書き出しのまま時が過ぎ、朝夕はかなり過ごしやすくなり、夜にはもう秋の虫たちが大合唱しています。

が、
せっかくなので、予定していた写真はそのまま貼り付けていきます(汗)

さて今回は DNS 関連のミス＆地雷編をお送りします。
分けて書く予定だったのですが、地雷もミスであることが多いので……

なお、いつものお約束、本稿には前職でDNS関連サポートを担当していた経験や個人的にもDNS関連サーバを運用している中での経験も多く含んでいます。また、DNS関連セミナーやイベント等で紹介されていた事例を含む場合もありますのでご了承ください。
※特に明言しないかぎり、bind環境でのお話とお考えください。

前稿：
　　移転問題編
　　浸透問題編

設定ミス

作業中のミスや思い違いで想定通りの結果が得られないケース。

ゾーンファイル

ラベルの省略

「subdom サブドメインについて MX レコードを追加してほしい」というご依頼がありました。

$TTL    3600
@               IN      SOA     dns0.example.jp. root.example.jp. (
                                2018061500      ; Serial
                                3600            ; Refresh
                                600             ; Retry
                                1209600         ; Expire
                                1200 )          ; Minimum
;
        259200  IN      NS      dns0.example.jp.
        259200  IN      NS      dns1.example.jp.
;
                IN      MX      10 mail
                IN      MX      20 mailv4
;
                IN      A       192.0.2.1          ;; helpme!!!
www             IN      A       192.0.2.1
                ・
                ・
                ・

これをこう変更してしまったり。

$TTL    3600
@               IN      SOA     dns0.example.jp. root.example.jp. (
                                2018061501      ; Serial
                                3600            ; Refresh
                                600             ; Retry
                                1209600         ; Expire
                                1200 )          ; Minimum
;
        259200  IN      NS      dns0.example.jp.
        259200  IN      NS      dns1.example.jp.
;
                IN      MX      10 mail
                IN      MX      20 mailv4
subdom          IN      MX      10 mail
subdom          IN      MX      20 mailv4
;
                IN      A       192.0.2.1          ;; helpme
www             IN      A       192.0.2.1
                ・
                ・
                ・

※ zone apex の Aレコードが牽けなくなる……

リソースレコード

NS、MX
「IPアドレスを書いてほしい」と依頼されることがありました。
```
@        259200  IN      NS      192.0.2.53.
@                IN      MX 10   192.0.2.53.
```
「エラーが出たけど、最後のドット外したら通ったので完了！」とか orz

CNAME
zone apex に対して CNAME レコードの追加を求められたり……

@        259200  IN      CNAME   host.example.jp.
@                IN      MX 10   mail

SPF (TXT)
長くなるので複数行に分けてみたり……

example.jp.      IN      TXT     "v=spf1 +ip4:192.168.100.0/24 "
                                 "+ip4:10.0.0.0/24 ~all"

見やすいようにと空白いくつも入れたり……

example.jp.      IN      TXT     "v=spf1   +ip4:192.168.100.0/24  +mx +a   -all"

参考「間違いから学ぶSPFレコードの正しい書き方」
https://salt.iajapan.org/wpmu/anti_spam/admin/operation/information/spf_i01/

地雷原

作業直後の確認で異常がなく、しばらくして作業ポイントあるいは作業とは異なる部分から不具合が発生するケース。

親子問題

お客様社内での管理部門が異なるからとサブドメインについて別のゾーンファイルで管理していたが、親ドメインの他社移転で生き別れとなり、サブドメインが参照できなくなった。

zone "example.jp"        { type master; file "master/E/example.jp.zone";        };
zone "subdom.example.jp" { type master; file "master/S/subdom.example.jp.zone"; };

※同一サーバ上に存在していたため、明示的に委任しなくても参照できていた。
　週末に親ドメイン引越し後、月曜日に子ドメインで異変に気づき発覚。

　親の引越しでサブドメインへのNS連携がなくなったのが原因。
　→ ゾーンファイルを分離するなら同一サーバ内でも親ゾーンに委任のNSレコードを入れておこう。

zoneステートメント

named.confから zoneステートメントを分離して includeファイルにしているケースは多々あると思いますが、複数存在する場合は要注意です。

# cat named.conf
……
include "include_file1.inc";
include "include_file2.inc";
……

# cat include_file1.inc
zone example1.jp {type master; file "DOMAINS/example1.jp"; };
zone example2.jp {type master; file "DOMAINS/example2.jp"; };
zone example3.jp {type master; file "DOMAINS/example3.jp"; };

# cat include_file2.inc
zone example11.jp {type master; file "DOMAINS/example11.jp"; };
zone example12.jp {type master; file "DOMAINS/example12.jp"; };
zone example13.jp {type master; file "DOMAINS/example13.jp"; };

#

全ての作業が終わった後、こんなことをした人がいた……

# cp -p include_file2.inc include_file1.inc

(実際には別includeファイルのバックアップを上書きした)

で、月日は流れ……
別のドメイン名で作業が入ります。
何が起きたか。

# rndc reload

なにも起きない。
自分が作業していた分の更新も確認できない。
そりゃそう、zoneステートメントの重複でエラーになってて処理されてない。
ここではまだ問題が発生してない。
「reloadで更新されないの、なんでかなぁ。とりあえず再起動してみるか……」

# service named restart

サービスはストップして、起動エラーになる。
しかも本人が作業したドメイン名以外でエラーが出てるから理解不能で……

重複エラーが出ていることで中身が同じincludeファイルの存在に気づいた者が上書きされたファイルをバックアップから戻して復旧。
セカンダリの権威DNSには影響しなかったため、被害は最小限で済みました。

ゾーンの書き戻し

やってしまったことは前項とほぼ同様ですが、これは結構大変でした。
とあるメールサーバのリプレースで IPアドレスを付け替えました。

$TTL    3600
@               IN      SOA     dns0.example.jp. root.example.jp. (
                                2013061500      ; Serial
                                3600            ; Refresh
                                600             ; Retry
                                1209600         ; Expire
                                1200 )          ; Minimum
;
        259200  IN      NS      dns0.example.jp.
        259200  IN      NS      dns1.example.jp.
;
                IN      MX      10 mail
;
mail            IN      A       192.0.2.1          ;; helpme!!!
                ・
                ・
                ・

これをバックアップして、

cp -p example.jp.zone example.jp.zone_20140501

こう変更します。

$TTL    3600
@               IN      SOA     dns0.example.jp. root.example.jp. (
                                2014050101      ; Serial
                                3600            ; Refresh
                                600             ; Retry
                                1209600         ; Expire
                                1200 )          ; Minimum
;
        259200  IN      NS      dns0.example.jp.
        259200  IN      NS      dns1.example.jp.
;
                IN      MX      10 mail
;
mail            IN      A       192.0.2.99          ;; helpme
                ・
                ・
                ・

変更内容を反映し、各種確認を行います。

rndc reload example.jp

そして全ての作業を完了後に地雷が入ります……

cp -p example.jp.zone_20140501 example.jp.zone
※事後調査による推定です。

SOAレコードの SERIAL値が先祖返りしているため、reloadしてもゾーンファイルは更新されません。
月日が経ち、メンテナンスのためサービスを再起動します。

service named restart

ここで古いゾーンファイルが適用されてしまいます。

セカンダリDNSはSERIAL値が若くなった(古い)ゾーンファイルを受け取らないので、ゾーン更新されずに残ります。
問合せに対して、プライマリDNSは古い(先祖返りした)応答を返す、セカンダリDNSは新しい情報を返す、という状況となり、1/2の確率で正解が返ります。

セカンダリDNSはプライマリとのzone同期ができないまま2週間を迎え、新しいはずのゾーンファイルを破棄(EXPIRE)してしまいます。
それによってゾーンファイルを持たない状態となり、プライマリのゾーン同期を受け入れ、両権威DNSサーバが古いゾーン情報に統一されてしまいました。

メールサーバのIPアドレス(Aレコード)は完全に先祖返りし、クライアントPCや外部のMTAから接続できない状態となったのでした。

対処はプライマリDNSでゾーン情報を新しい内容に置き換えて reload、セカンダリDNSへは即時同期されて完了。
自組織管理分についてキャッシュDNSサーバたちからキャッシュ情報をクリアして、他組織のキャッシュは触れないのでじっと1時間待って完全復旧。

最後に

作業ミスでうまくいかないケースや時間が経ってからある日突然おかしくなるケースなどについていくつかご紹介しました。
やはり手順を事前にしっかり確定すること、予定にない作業は行わないこと、思い込みで作業しないことが重要ではないでしょうか。

当社でもミスはないとは言えません。しかしながら同じミスを繰り返さないよう、改善を重ねながら安定したサービスを提供できるよう、努めていきます。

以上、昔話担当? の m//t でした。

m//t

　
　
　
　
　
COBOL系SE,PG から NetNews(nntp)配送管理者(tnn.netnews.stats集計担当) を経て現職。

社内業務改善(「やりたくない」がモチベーション)でいろいろ社内ツールを作ってきました。
ネットワーク系の機器をいじることも多いので、それらの管理や制御に関するツールもちらほら。
perlで書くことが多いですね。(COBOLやFORTRAN、Pascal でもいいですけど……)
どれだけ読みやすく書けるか、10年後の自分に手紙でも書くような気持ちで。

最近はDNSを少しかじったりしてますが、いろいろ悩ましいことが多すぎます (>_<)
好きなポート番号は53、119、123です。

LINK
クラウドベリージャム：プロフィールページ