2015年12月05日

CentOS6で名前解決がボトルネックになった場合の対処方法

この記事は
DNS Advent Calendar 2015 - Qiitaの5日目
Linux Advent Calendar 2015 - Qiitaの5日目
の記事です。

とあるセキュリティアプライアンスを導入したときにハマったこと。

構成は以下の通り。
05_01.png

LANスイッチとルータの間にTransparentモードでセキュリティアプライアンス入れて
アクセスログとかアプリケーションコントロールとかやろうとしたんですね。

で、この構成にしたところ、同一LANにあるクライアント(Windows)から
サーバ(Linux)へのSSHが極端に遅くなりまして。

/etc/ssh/sshd_configのUseDNSをNoにしたところ
クライアント(Windows)→サーバ(Linux)のSSHは速くなりました。
(完全にLinux側の名前解決に問題が生じているな…)

しかしサーバ(Linux)から同一LANのサーバ(Linux)や
インターネット上のサーバ(Linux)へのSSHが遅くなったのは
その場では解決できず、一旦切り戻して検証環境を作って
切り分けをしました。

F/Wポリシーのログを見ると、どうやら戻りの通信を止めているようだ。
なぜ止められているのかはよくわからないのでtcpdumpをとったら
なぜか最初にAAAAを引きにいこうとしている。IPv6無効にしているのに。

で、「CentOS6 名前解決 遅い」でググったら、出てくる出てくる。
しかしそれらしいページを5つ見たら、5つとも違う対処方法が書いてあるw
結局このケースでうまくいったのは以下ページの手法でした。

CentOS6 (RedHat6) 名前解決に時間がかかる。

/etc/resolv.conf内に
options single-request-reopen
を追加したところ見事に解決。
posted by maroon at 15:07| Comment(0) | IT_設定関連メモ | このブログの読者になる | 更新情報をチェックする

2015年12月04日

NSDをSlaveにするとき問題になること

この記事はDNS Advent Calendar 2015 - Qiitaの4日目の記事です。

NSDというのはNLnet Labsというところが開発しているDNSサーバ(権威サーバ専用)です。
ちなみに全く触れてませんでしたがUnboundもNLnet Labsが開発しています。
http://www.nlnetlabs.nl/projects/nsd/
http://www.nlnetlabs.nl/projects/unbound/

NSDというのはBIND9よりもシンプルな実装で脆弱性も少なく高速!
というのがよく言われるアピールポイントなわけですが、
これをスレーブサーバにしようとするとちょっと問題がありまして。

NSDのゾーン転送って、シリアルをチェックしてないんですよ。
BIND9とかだと、ゾーンのシリアルをチェックして
・新しくなっていれば転送
・変更がなければ転送しない
という動きになるんですが

NSDの場合
・シリアル見ないから毎回マスターサーバのゾーンを全部とってくる
という挙動になるのです。

ゾーン数がそれほど多くなければまぁいいかなとも思うんですが
NSD使うかどうか検討してたとき、僕が管理してたDNSサーバ、
ゾーンが約7000あったんですね。
「うーんこりゃきついなー」ということになりました。
※ちなみにこの7000ゾーンのDNSサーバの話は後日何回かに分けてやる予定

このスライドの31〜33を見ていただけるとわかりやすいです。
http://www.slideshare.net/hdais/nsd-unboundintro
posted by maroon at 10:43| Comment(0) | IT_設定関連メモ | このブログの読者になる | 更新情報をチェックする

2015年12月03日

Unboundの性能測定/評価(試行錯誤中)

この記事はDNS Advent Calendar 2015 - Qiitaの3日目の記事です。

色々な会社のクラウドサーバを使ってUnbound立てて
パフォーマンステストをしているのですが
あまり納得のいく結果が出ていない状況です。

結果自体に妥当性があるのかどうかというのがまず疑問。
なんとなくグラフィカルでわかりやすいのでrespeerf-reportを
使っているけど、本当にそれでいいのかとか、わからない。

このへん読んで基本に立ち返ろうと思います。
http://dnsops.jp/event/20130718/20130718-stress-tool-hattori-1.pdf
https://www.nic.ad.jp/ja/materials/iw/2013/proceedings/d2/d2-hattori.pdf

今わかっていることとしては
Unboundのチューニングとクラウドサーバのスペック(CPU数とメモリ容量)を揃えたうえで
同じクエリファイルを使って同じ負荷のかけ方をした場合、まぁどこのサービスでも
同じような結果が出るのだけれど、稀に性能が出ないサービスがあったりする。
おそらく他ノードへの影響を与えないために制限をかけているのだろうけれど
コンピューティングリソースの問題なのかネットワーク帯域の問題なのか
現時点ではわからないので、そのへんも見極められるようになると良いなぁと。

ちなみに別にDNSサーバの管理をしているわけでもないし
自分でISP立ち上げるわけでもないので、Unboundのパフォーマンステストは
仕事には全く関係なく完全に趣味の領域なんだけど、楽しいから続けてる。
なぜ楽しいと思うのかは自分でもよくわかっていない。。
posted by maroon at 13:14| Comment(0) | IT_設定関連メモ | このブログの読者になる | 更新情報をチェックする
×

この広告は1年以上新しい記事の投稿がないブログに表示されております。