2015年12月06日

DNSサーバリプレイス話@Route53検討編

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

某Web屋さんでオンプレミスからパブリッククラウドへの移行を担当していたときの話。
もちろんWebサービスそのものの移行も担当してたんですが、もっぱら担当してたのは
その周辺環境、具体的に言うとメールサーバとDNSサーバの移行ですね。

DNSサーバは、クラウドに移行するなら「まずRoute53を検討するだろ」
というわけで検討しまして、移行できるものは移行したんですが
どうしてもRoute53に持って行けないものがありまして。

共用ホスティングサービスみたいなシステムがあったんですね。
店舗のHPと販促システムが一緒になったようなやつ。

これがコスト的には結構カツカツでやっていて、1ドメインあたりの売上が
Route53に移行した別のサイトよりも圧倒的に低かったんですね。
全部束になっても1個のサイトの売上に勝てないとかそんな感じでした。

そんな共用ホスティングですが、なんとドメインが約7000個。
これをそのままRoute53に持っていったら
ドメイン費用だけで70000円/月かかるわけです。
それにさらにリクエスト課金が発生するわけで…。

このサービス全体で見てもDNSの費用に70000円はかけられない
ということで、別の方法を考えましょうということになったわけです。

というわけで、次回へ続く。
posted by maroon at 22:21| Comment(0) | IT_設定関連メモ | このブログの読者になる | 更新情報をチェックする

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_設定関連メモ | このブログの読者になる | 更新情報をチェックする