キャッシュDNSサーバーとしてBINDのみを使用している現場でUnboundを使い始めるまで
3月 11日 @ 9:00 PM - 9:45 PM 講演者:ナツヨさん
概要
オープンソースカンファレンス2018 Tokyo/Spring で発表した内容の再演です。 資料:https://www.ospn.jp/osc2018-spring/pdf/OSC2018_TokyoSpring_Unbound.pdf
DNSとは
名前解決、皆さんこんなイメージだと思います。 DNSがなくなると
- DNSがないとIPを直打ちしないといけない
- webが見れなくなる
- メール使えない
DNSサーバの名称
- キャッシュ(リゾルバ)
- 権威(コンテンツサーバ)
- 最近では名前を統一するRFC7719 https://www.nic.ad.jp/ja/basics/terms/authoritative-nameserver.html
DNSルートサーバ(DNSを調べるための一番大元となるサーバ)は全部で13台(13種類)
なぜキャッシュと権威が2つあるのか?
- 1980年台インターネットの線があまり太くなかった(遅い)
- 一回クライアントからキャッシュDNSサーバに送られる
- イメージとしては Web proxy server にちかい。
- キャッシュDNSはクライアントからの再帰検索要求を受け付けると一定時間(TTL)その応答をおぼえている
- expire は権威サーバの話、secondary から primary のゾーン情報取れなかったときの話(プライマリが死んだときにセカンダリで保持する時間)
BINDとは
BINDのイメージ等
- 脆弱性が多い、やめたい…
- Webで調べるとホームページ作成ソフトが出てくる?
BINDとは
- History of BIND | Internet Systems Consortium
- 英語だと「縛る」とかの意味があるけど、The Berkeley Internet Name Domain の頭文字を集めたもの。
- もともとカリフォルニア大学バークレー校で米国国防総省先進研究プロジェクト管理(DARPA)の助成を受けて大学院の学生プロジェクトとして立ち上がった。
- 4系からはじまって、8系, 9系, 幻の10系。いまは9系(9.11.2/9.12が最新)。
- 幻の10系
- 9系から全部書き直しで開発を始めた
- 途中で開発停止 : ISC BIND 10 初期開発プロジェクト終了
- Bind10 PM のプレゼン資料が涙なしでは読めないので見てほしいとJRPSのひとに教わった
- Bind脆弱性が多いが、JPRSがいつも情報提供してくれているので助かっている。
なぜBindは脆弱性が多いのか?
- ごちゃごちゃしている、モノリシックな(密結合。モジュールに分割されていない)プログラム
- 2016年のIIJの人のプレゼン、american fuzzy lop (fuzzing test をするツール) というテストツールがあってこれからどんどん脆弱性が見つかるはず。
オープンソースカンファレンス2018 Tokyo/Spring 再演
このセッションのターゲット
- DNSの管理をしている人
- BINDの脆弱性対応に工数が取られている方
- BIND以外のソフトを検討・導入を考えている方
BINDからの卒業を決意するまで
- 普段からBINDの脆弱性対応に工数を取られていた
- 「どうしてこんな脆弱性の多い物を使うのか」と疑問に思っていた
- サービスの可用性の低下
- 2016年あたりが酷かった。年間11件とか
- その年開催のDNS Summer Day 2016のテーマが 「BINDからの卒業」だと知り参加した
どうやってUnboundに決めたの?
- Unbound、PowerDNS、NSD など紹介されていた
- 日本DNSオペレーターズグループ | DNS Summer Days 2016
- BIND使っているけど、BINDにこだわる必要は特にないなーと思った。
- 当時、キャッシュ3, 権威2(primary/secondary)
- キャッシュは外部への反復的な問い合わせもしていた
- 数千Query/sec
- ACLによるアクセス制限
- View 未使用 (source ip をみて応答を変えたりできる機能, BIND独自でBINDから離れられない理由のひとつ)
- 児童ポルノブロッキング実施 (外向けのプロバイダとかをしていないと知らないかも。)
- プロバイダとかで良くやっている。DNSを使ってブロッキングをする。ポルノ提供ドメインを管理している団体から情報をもらって、対象ドメイン名の問い合わせが来たら、本来のIPアドレス(Aレコード)ではなく違うIPを返す。違うIPはブロック画面とか(「このサイトは児童ポルノなのでこのプロバイダでは見れません」)(IP直ウチされると防げないけど)
- 権威は外部に公開
- 当時の現場担当者レベルでの話
- 興味本位で調べている人はいたが運用実績は BIND 以外なし
- BIND以外のものを使う場合、教育コストを考える必要があった。
- キャッシュと権威のどちらから始めるか?
- 権威は面倒くさそう: レコード更新とかの手順書を全部変えるのは大変。
- キャッシュの手順書変更は、権威に比べればはるかに楽なレベル。
- キャッシュ3台のうち1台をBINDに置き換えてマルチベンダ構成に → 可用性の向上を狙える
- BINDコロリ: パケット1発でBIND即死みたいな攻撃があった。全部BINDだとそう言うので全滅するリスクが。
どれにする?
- PowerDNS Recursor
- PowerDNSが権威・キャッシュそれぞれある。キャッシュの方が Recursor
- Unbound
- djbdns
- Debian/RHEL安定版でパッケージ採用がない
- 当時動かし方がわからなかった(本もあるけど古本しかない)
Unbound採用の理由
- 日本語情報が充実: 日本Unboundユーザ会、ネットに素晴らしいスライドが
- 児童ポルノブロッキングの具体的な設定例があった
- PowerDNSでもできると思われるけど当時はやり方の情報が見つけられなかった
どうやってUnboundによる運用を定着させたの?
- BIND Onlyのデメリットを知ってもらう
- 資料回覧
- Unboundこわくないよ
- 動くところを見せる: 動かすのが簡単。パッケージで入れるだけ(apt-get)。
- 大手プロバイダ利用実績: IIJでもつかっている。
- BINDとの機能・コマンド対比表: 現場で使っている機能が全部動くこと、named-checkconf相当のコマンドがある、児童ポルノブロッキングの更新がスクリプトで動いていたので、それでBIND/Unbound後外が出ないように吸収。
- ZabbixによるUnbound監視方法の提案 (サーバ上にいれるagent(zabbix-sender)でUnboundの統計情報を取る)
- 現場の反応
- 先輩が厳しくレビューしてくれた(偉い人目線のチェック)
- 上司もいきなり全部帰るのではなく1台からマルチベンダ構成にするなら、というので承諾してくれた。
- 理解のある先輩や上司に恵まれた事が大きい
今後はどうするの?
- 2016/9からUnbound稼働開始。今のところ大きな問題なし。
- 今後もマルチベンダ構成を継続。
- 今後の開発とか脆弱性の出方とかをみながら完全卒業を検討
- 権威サーバ側もBINDから卒業を考える
まとめ
- DNS Summer day2016をきっかけに
- Unboundを選択
- マルチベンダー構成で導入する
- 児童ポルノブロッキング対応が大きかった
- BINDオンリーのデメリットとUnbound怖くナイを布教
- 理解のある先輩や上司の支援も
- 2016/9からキャッシュのマルチベンダか。今後は権威も卒業させたい
聴取者の声
Q & A
-
Q. Unboundのセキュリティパッチとかってどのくらいの頻度ででてますか?
- Unboundの脆弱性頻度は https://jprs.jp/tech/index.html#dns-security-info を見るとだいたいわかります。
-
Q. BINDからUnboundまでの移行期間はどれくらいかかった?
- DNS Summer day 2016が6月で運用開始が9月
-
Q. ダウンタイムはどれくらいだった?
- IPアドレスは変えなかった。断自体は数分。顧客にDNSのIPを二つ以上渡しているので、顧客側の断はなかったはず。
-
Q. 実際変えてみてメリットってどう感じている?
- BINDとUnboundを同時に使っているので脆弱性対応の工数自体は減っていない。プラスしてUnboundの分が増えている。
- 1台でもunboundがあることで、コロリをくらっても全滅しないという心の平穏が得られる。(可用性向上)
-
Q. 今後全部Unboundにする予定はある?
- なやんでいる。今まで全部BINDだったんだし、全部Unboundでもいいんじゃないかという話もある。
- マルチベンダ構成で可用性を…という話をとるなら両方使うので継続か
- 個人的な意見としては、BIND面倒だから全部Unboundにしてしまえという気持ちはある。
-
Q. Unboundがわかる運用者とかエンジニアを広めていく活動も大事なのでは。周りの人の理解度はどれくらい?
- 状況、レビューをしてくれた先輩。後輩もひとりUnbound構築してもらったりした。
-
Q. Unboundの脆弱性ってどれくらいありましたでしょうか
- JPRSのサイト(DNS関連技術情報)を見よう! (https://jprs.jp/tech/index.html#dns-security-info )
-
Q. NSD とかは検討されましたか?
- しています(いまも)
- 今回まずはキャッシュからやってみた。当然権威がそのままなので、NSDにという話はある。次のリプレースのタイミングかなと個人的には考えている。
-
Q. 心の平穏とは?
- 即時対応しなくても全滅しないよ、という感じ
-
Q. Unboundの権威サーバー化の情報を探している
- 最近出た話
- キャッシュサーバを権威サーバと兼用すると危ない http://www.e-ontap.com/dns/weirdra/
-
Q. dig or nslookup?
- 好き嫌いをいえるほど使っていないけど、仕事だとdigを使う方が多い
- drill
-
Q. curl or wget?
- 最近は curl が好きです!
-
Q. マルチベンダー構成をしつつ卒業するとしたら今は何が良いか
- キャッシュサーバーは変な使い方してないのなら Unbound で。権威は悩んでいて NSD というのもある。それをするか PowerDNS にするか。
-
Q. Unbound でハマッタ所、苦労したところはありますか?
- 複雑な使い方をしていないせいか、そんなにない。上長の説得が一番たいへんだった。技術的な面は先輩に助けていただいた。
-
Q. Unbound のパフォーマンス面はどうですか?
- 問題になったことはない
- 3倍程度出るらしい
- unboundとBINDのチューニングだと次のスライド https://www.slideshare.net/hdais/dns-32071366
-
Q. 今まで攻撃で Unbound がダウンしたことはあるか?
- ない。