UnboundとNSDの紹介　BIND9との比較編

UnboundとNSDの紹介
BIND9との比較編
日本Unboundユーザ会　東大亮 (平会員)
オープンソースカンファレンス 2014 Tokyo/Fall
2014/10/19
1

日本Unboundユーザ会に
ついて
• 滝澤さん (@ttkzw) が運営されてる謎の会
• http://unbound.jp
• UnboundやNSDやldnsのマニュアルの翻訳等
• 本家 (http://unbound.net) からも公認されてる
• 私はユーザ会のMLに参加してるだけ……
2

DNSサーバといえば？
• BIND9が第一選択とすることが、多いのではないでしょ
うか
• 前から使ってたし
• Google検索したら設定例出てくるし
• 書籍も多いし
• 急に「DNSサーバ作って！」と言われた時なんか、慣れ
たBIND9で構築してしまう
4

BIND9以外の選択肢の例
• 権威サーバ
• NSD
• PowerDNS
• Knot DNS
• Yadifa
• キャッシュサーバ
• Unbound
• PowerDNS recursor
• Deadwood
(MaraDNS)
5

なぜBIND9以外の
DNSサーバか？
• BIND9は歴史も長く、機能豊富のため、他の実装
ができることは、BIND9でも大体できる
• なぜBIND9以外の選択肢が必要なのか？
6

BIND9のいいところ
• 機能が豊富
• とにかく多い！
• なんでもできるとしても過言でない
• 使い方を知っている人が多い
• Google先生に聞けば設定例が出てくる
• そのへんのおじさんに聞けば大抵わかる
7

BIND9の残念なところ(1)
• （機能が豊富ゆえに）複雑すぎる
• ほとんどの用途では不要な機能が多数→現在も絶
賛肥大化中
• 権威サーバ機能とキャッシュサーバ機能が同時に
オンになっている等、運用上のトラブルの原因と
なるデフォルト設定
8

BIND9の残念なところ(2)
• 脆弱性が多い
• 毎年、セキュリティ脆弱性が複数発生
• パケット一発でプロセス停止、みたいな致命的なのが多い
• BIND9へのゼロデイアタックが発生したら全滅
• 性能は高いとは言えない
• 他の実装に比べると、BIND9の動作は遅い
9

NSD/Unboundのすすめ
• DNSサーバとして本当に必要な機能のみに絞った
シンプルな実装
• とはいっても、Unboundは機能豊富
• 脆弱性が少ない
• 性能がそこそこ高い
10

この発表について
• BIND9以外の実装に興味があるが、よく分からないので
不安がある方のために検討材料を提供
• 他の実装の例としてNSD/Unboundを、BIND9との比
較を中心に紹介
• BIND9ダメ！Unbound/NSDイイ！というつもりはな
く、メリット・デメリットを明確化したい
• NSD/Unboundのインストール方法や細かな設定方法に
はあまり触れません
11

NSDとは
• “Name Server Daemon”
• 権威DNSサーバ専用
• キャッシュサーバ（フルリゾルバサービス）機能は持たない
• BSDスタイルライセンス
• Unix系OSで動作(GNU/Linux, FreeBSD, Solaris,.. etc)
• 簡単にインストールできるよう、多くのLinuxディストリビュー
ション/FreeBSD/NetBSDでパッケージが用意されている
13

NSDとは(2)
• 蘭NLnet Labsと欧州RIPE NCCが共同で開発・保
守を行っている
• http://www.nlnetlabs.nl/projects/nsd/
• 現在、NSD 3.x系列／NSD 4.x系列の二つのバー
ジョン系列あり
• 新規に評価・使用するならNSD 4.x系列(最新は
4.1.0)がおすすめ
14

NSDとは(3)
• NSDが適するユースケース
• インターネット全体に公開するドメイン名の権威サーバ
• rootサーバ・TLDサーバで多くの実績あり。DNSホスティ
ングでも利用例が増えてきている
• マスタサーバにも、スレーブサーバにもなれる
• DNSSEC署名されたゾーンも提供可能
• 内部のみに公開するドメインの権威サーバとしてももちろん可
15

NSD4とBIND9の比較
機能編
• BIND9にあるが、NSDに無い主な機能は？
• 機能数だけみれば、NSDはBIND9より少ない（BIND9
NSD 4.1.0 vs BIND 9.9.5
はNSDが持つ全機能は網羅している）
• しかし、NSDは、通常の利用方法なら問題ない程度
の機能は持つ
• NSDには無くても、他の実装では提供されている場合
もあるので、どうしても必要ならそちらを検討するのも
いいかも
16

機能編(1)
NSD 4.1.0 vs BIND 9.9.5
• NSDに無い機能: Dynamic Update
• ゾーンファイルを編集せずに、ゾーンの特定のレコー
ドを変更する機能
• DHCPでPCのIPアドレスを動的に配っている環境
などで使用されることがある（PCのIPが変わるた
びにゾーン情報を更新）
• Knot DNSは Dynamic updateが可能の模様
17

機能編(2)
NSD 4.1.0 vs BIND 9.9.5
• NSDに無い機能: マスタサーバ側のIXFR機能
• ゾーン転送時に、ゾーン全体の転送(AXFR)ではなく、更新
差分のみをスレーブに提供する機能
• 超巨大なゾーン(TLDなど)を提供している場合でない限
り、転送量が問題になることはあまりない
• NSD4はスレーブサーバとしてのIXFR機能は実装している
• マスタ側がIXFR転送を提供してる場合は、差分転送は可能
18

機能編(3)
NSD 4.1.0 vs BIND 9.9.5
• NSDに無い機能: DNSSEC自動署名機能
• BIND9はDNSSEC自動署名機能(inline signing)
を持つが、NSD4は持たない
• NSD4でも、OpenDNSSEC、dnsseczonetool
等のDNSSEC自動署名ツールを併用すれば問題
なし
19

機能編(4)
• NSDに無い機能: キャッシュサーバ（リゾルバ）
• NSDは権威サーバ専用なので当然
• BIND9は権威サーバとキャッシュサーバの同居が
可能で、そのような運用も多数見られるが、セキュ
リティ上・運用上の問題を引き起こすことがある
ので、避けるべき
参考：「DNS移転失敗体験談」by oheso tori
　 http://www.slideshare.net/ohesotori/dns-23491023
20

機能編(5)
• NSDに無い機能: View機能
• DNS問い合わせのソースIPアドレス等によっ
て、応答を変える（応答に使用するゾーンファ
イルを変える）
• 本当に要ります？
21

設定編(1)
設定ファイルのスタイルには違いはあるが、設定内容はほとんど同じ
server:
username: “nsd”
zone:
NSD4設定ファイルBIND9設定ファイル
name: “example.net"
zonefile: “/etc/dns/master/example.net"
provide-xfr: 192.0.2.1 NOKEY
notify: 192.0.2.1 NOKEY
zone:
name: “example.com”
request-xfr: 192.0.2.2 NOKEY
allow-notify: 192.0.2.2 NOKEY
remote-control:
control-enable: yes
option {
recursion no;
};
zone “example.net” {
type master;
file “/etc/dns/master/example.net”
also-notify { 192.0.2.1; };
};
zone “example.com” {
type slave;
masters { 192.0.2.2; };
};
controls {
inet 127.0.0.1 allow { localhost; }
keys { rndc-key; };
};
22

設定編(2)
server:
username: “nsd”
zone:
zone:
マスタname: ーゾ“ーexample.ンの設定
com”
　参照request-するゾxfr: ーンフ192.0.2.2 ァイルのNOKEY
指定と、ゾーン転送を許可するslaveサーバと、ゾーン更新時
にnotifyを送信するslaveサーバの指定。NOKEYはTSIG使用しないという意味。
※remote-BIND9ではcontrol:
also-notify指定し要。BIND9control-でもステenable: ルスサーバ構yes
なくても、ゾーンファイルのNSレコードから自動的にnotify先を見つけてくれるが、NSD４では指定
成時や名前解決そのものが失敗する場合にうまくいかないため常に指定したほうがよい。
option {
recursion no;
};
type master;
allow-transfer { 192.0.2.1; };
also-notify { 192.0.2.1; };
};
type slave;
masters { 192.0.2.2; };
};
controls {
keys { rndc-key; };
};
23

設定編(3)
server:
username: “nsd”
スレーブゾーンの設定
　マzone:
スターサーバの設定。NSDはallow-notifyでnotifyを許可するマスタサーバを指定す
る必要がある。
　NSDでは、ゾーン転送で取得したゾーンはNSD DBファイル(nsd.db)に自動的に保存される
zone:
allow-notify: 192.0.2.2 NOKEY
remote-control:
control-enable: yes
option {
recursion no;
};
type master;
also-notify { 192.0.2.1; };
};
type slave;
masters { 192.0.2.2; };
};
controls {
keys { rndc-key; };
};
24

設定編(4)
server:
username: “nsd”
zone:
リモートコントロールクライアントの指定
NSDzone:
ではnsd-control（BIND9では rndc）というクライアントで制御できる
remote-control:
control-enable: yes
option {
recursion no;
};
type master;
also-notify { 192.0.2.1; };
};
type slave;
masters { 192.0.2.2; };
};
controls {
keys { rndc-key; };
};
25

設定編(5)
• ゾーンファイルは、基本的にはBIND9とNSDで同じも
のが使える
• BIND固有の$GENERATE構文は、NSDでは使えない
• $GENERATE構文含むゾーンファイルを読み込んでいるBIND9
マスタから、NSD4スレーブにゾーン転送するのは問題なし
26

運用編(1)
• BIND9 (named)の操作は rndc コマンドで行うが、
NSD4 (nsd)の操作は nsd-control コマンドで行う。使用
感は似ている。
• nsd-control start | stop
• NSDの起動 | 停止
• nsd-control reconfig
• 設定ファイル (nsd.conf)の再読込
27

運用編(2)
• nsd-control reload [zone]
• zoneのゾーンファイルを再読込 ([zone]を省略
すれば全ゾーン再読込)
• nsd-control transfer <zone> | force_transfer <zone>
• スレーブゾーンを転送 | シリアルチェックせず
に強制転送 (rndc retransfer相当)
28

NSDのセキュリティ脆弱性
NSDは、BIND9に比べてセキュリティ脆弱性の発生頻度は小さい。
セキュリティ脆弱性発生頻度
2014※ 2013 2012 2011 2010
NSD 0 0 2 0 0
BIND9 2 2 4 2 1
※2014/10まで
・各年度のCVE発行数をカウント
　・BIND9は権威DNSサーバとして設定した場合に該当する脆弱性のみ抽出
　・各脆弱性の影響の大きさは考慮に入れずカウントしている
・NSDもBIND9も、サービス停止(DoS)攻撃の脆弱性がほとんどを占める
29

NSDの性能
ベンチマークによれば、NSD4はBIND9の3倍以上の応答性能
NSD4/BIND9　応答性能比較
NSD 4.1.0 qps 137,289
BIND 9.9.5-P1 qps 39,420
NSD/BIND qps/qps 3.48
テスト条件：
　ゾーン 0.com～9999.com を試験対象の権威DNSサーバにロードし、dnsperfでwww.1.com ～
www.9999.comのAレコードを計500万回問い合わせて query per secondを測定。NSD/BIND9とも
にCPU idleがほぼ0%に達していることを確認
テストマシン： Intel Core2duo 1.6GHz (2core) CentOS 6.5
30

NSDの気になるところ(1)
• スレーブゾーンのゾーン転送手順に難あり
• 極めて多数のゾーンを保持する用途（DNSホスティ
ング等）では高負荷の懸念
• ドキュメントには記載はされているが、実装を単
純にするために、こうしてるとのこと
• 私も開発元に改善を要望したことはあるが修正は
されていない
31

• マスタサーバに、当該ゾーンのSOA
レコードをUDPで問い合わせ
• ゾーンのシリアルが更新されてい
たら、マスタサーバからゾーン転
送開始
• シリアルが更新されていなかった
ら、ゾーン転送しない
BIND9 slave master
example.com SOA?
SOA serial=2014101801
example.com AXFR request
example.com
ゾーン転送
BIND9スレーブのゾーン転送手順
SOAのREFRESH時間毎に、以下を実施
32

• SOAレコードをUDPで問い合
わせしない。いきなりゾーン転
送開始
• ゾーン転送の先頭メッセージに
あるSOAレコードのシリアルを
見て、シリアル更新されていな
かったらTCP切断
NSD slave master
example.com AXFR request
example.com
ゾーン転送
NSDスレーブのゾーン転送手順
SOAのREFRESH時間毎に、以下を実施
serial更新有無にかかわらず、毎REFRESH時間に
ゾーン転送が行われる
　→ゾーン数が多いと、負荷が大きくなる懸念
33

NSDの噂
• NSDは、DNSラウンドロビンができない？
• NSD 4.1.0 (2014/9リリース)で実装されました
• round-robin: yes
• 滝澤さんの解説記事
• http://heartbeats.jp/hbblog/2014/09/nsd-roundrobin.
html
34

NSDまとめ
• BIND9ほどの豊富な機能があるわけではないが、通常の利用
では必要十分な機能が提供されている
• NSD4の制御はnsd-controlで行うが、BIND9のrndcと使用
感は似ている
• セキュリティ脆弱性は少ない (2012/7以降発生していない)
• NSD4は約3倍の応答性能 (BIND9.9との比較)
• 運用上の問題（ゾーン転送手順）も無くはない・・・
35

Unboundとは
• “Unbound” ⇔ “BIND” ?
• DNSキャッシュサーバ（フルリゾルバサービス）専用
• 権威DNSサーバ機能は持たない（ローカルデータは定義可）
• BSDスタイルライセンス
• Unix系OS(GNU/Linux, FreeBSD,..etc)とWindowsで動作
• 簡単にインストールできるよう、多くのLinuxディストリビューション/
FreeBSD/NetBSDでパッケージが用意されている
• Windows版はインストーラ付きバイナリが提供され、Windowsサービス
として動作する
37

Unboundとは(2)
• 蘭NLnet Labsが保守を行っている
• Verisign, Kirei, Nominet, ep.netによるJava実装をNLnet
LabsがC言語で再実装
• http://unbound.net
• 2008/5に1.0.0 リリース、最新のバージョンは 1.4.22
• メンテナンスは活発だが、コードベースは安定しており、最近
では大きな変更は少ない
• 最新版を使用することを推奨
38

Unboundの主な機能
• DNSキャッシュサーバ機能
• ソースIP規制、TXID/port radomisationなどのキャッシュポイズニン
グ防止、IPv4/IPv6デュアルスタック等、一通りの機能は装備
• DNSSEC Validator機能
• RSA2048, SHA-256, NSEC3, ECDSA, ECCGOST等、標準的なも
のはもちろん、最新規格のアルゴリズムを実装。RFC5011 Trust
Anchor自動更新にも対応
• 権威DNSサーバ機能は無いが、ローカルデータは設定可能
• dns64やdnstapのような新機能も最近追加 (次回リリースで入る予定)
39

Unboundが適する
ユースケース
• インターネット上のドメイン名を解決するためのフルリゾ
ルバサーバ。以下のどの用途にも適する
• xSPで提供されているような、多数の端末やVPS向けに
サービスするDNSキャッシュサーバ
• ローカルで自分専用に動作させるDNSキャッシュサーバ
• 最近はxSPのキャッシュサーバもDDoSで止まるこ
とがあるので、自前のキャッシュサーバを用意する
のもお勧め
40

UnboundとBIND9の比較
機能編(1)
• UnboundとBIND9の機能比較
• キャッシュサーバとしては、Unboundもそれな
りに機能豊富。BIND9に無い機能もいくつか搭載
している
• Unbound固有の機能、BIND9固有の機能それぞ
れがある
41

機能編(2)
• Unboundに無い、BIND9にある主な機能
• 権威DNSサーバ機能
• Unboundはキャッシュサーバ専用。ただしローカルデータ
は定義可
• 「www.example.comのAレコードのクエリは、権威サーバに
聞きに行かずに192.0.2.1で応答する」という設定は可能
• View
• クライアントのソースIPなどにより動作を変える機能。
キャッシュサーバに要る？
42

機能編(3)
• Unboundに有り、BIND9に無い主な機能
• Negative Trust Anchor
• 指定したドメイン名をDNSSEC Validationしない機能。権
威サーバ側のDNSSEC運用ミスでbogusになったドメイン
を一時的に引けるようにする
• キャッシュポイズニング攻撃の部分的検知
• カミンスキー型などのポイズニング攻撃を検知*し、一定の
閾値を超えたらログ出力・キャッシュクリア（攻撃検知は
可能、防御できるわけではない）
• デフォルトではオフ
43
* TXIDの不一致をカウント

Negative Trust Anchorの必要性
最近の主要TLDのDNSSEC運用ミス事例
日時ドメイン原因
2012/12/27 .mil (米軍) RRSIG期限切れ
2013/6/23 .biz DS->KSKミスマッチ
2013/8/14 .gov (米政府) DS->KSKミスマッチ
2013/11/16 174.in-addr.arpa DS->KSKミスマッチ
2014/5/20 172.in-addr.arpa DS->KSKミスマッチ
DNSSEC validatorは、当該TLDゾーンからの応答を全てbogusとし、配下のドメ
インが全て解決できなくなった（いずれも数時間で回復）
Unboundは、指定したドメインのDNSSEC検証を一時的にオフ(Negative
Trust Anchor)にして、名前解決可能な状況に回復させることができる
　設定例: domain-insecure: example.com
44

セキュリティ脆弱性の
頻度の比較
Unboundは、BIND9に比べてセキュリティ脆弱性の発生頻度は小さい。
セキュリティ脆弱性発生頻度
2014※ 2013 2012 2011 2010
Unbound 0 0 1 2 1
BIND9 2 4 7 5 7
※2014/10まで
・各年度のCVE発行数をカウント
　・BIND9はキャッシュサーバとして設定した場合に該当する脆弱性のみ抽出
　・各脆弱性の影響の大きさは考慮に入れずカウントしている
・UnboundもBIND9も、サービス停止(DoS)攻撃の脆弱性がほとんどを占める
45

名前解決速度
ベンチマークによれば、Unboundは、BIND9の3倍程度
の性能を出している
キャッシュヒット率→ 0% 80% 90% 100%
Unbound 1.4.22 qps 84,026 273,744 367,826 542,733
BIND9.9.5 qps 24,577 81,393 107,765 160,238
Unbound/BIND qps/qps 3.42 3.36 3.41 3.39
テスト条件
　権威サーバに以下のドメインを作成し、キャッシュヒット率を変化させながら応答速度(query per second)をdnsperfで測定
　1.cached.com～10000000.cached.com　→キャッシュ済みとしておく
1.nocached.com～1000000.nocached.com →キャッシュミス時に権威サーバに１回だけ再無し帰問い合わせ
テスト対象のキャッシュサーバと、権威サーバは同じNWセグメントに存在、DNSSEC署名無し。
　CPU idle はほぼ0%に達していることを確認。
テストマシン：Xeon E3-1220 3GHz (4core), メモリ 4GB
46

名前解決成功率測定
• Unboundに対する不安
• ドメイン運用者は、BIND9のリゾルバでは自分のドメイン
名が引けるかテストしてるだろうが、Unboundではテスト
してないだろう？
• 相性問題のようなもので、Unboundで引けないドメインが
たくさんあるのではないか？
UnboundとBIND9に、多数のドメイン名を解決させて成功率・失
敗率を測定してみた
→　失敗率に大きな差がなければ、BIND9とUnboundは同等の性
能と言える
47

多数のDNSテストクエリを、同時にBIND9とUnboundに送出し、名前
解決成功率・失敗率を測定
www.google.com A
www.google.com AAAA
yahoo.co.jp MX
twitter.com A
……………
BIND9
BIND9
BIND9
BIND9
BIND9
Unbound
Unbound
Unbound
Unbound
Unbound
インターネット
（権威サーバ群）
擬似クライアントから、サーバ上
のBIND9/Unboundにクエリ送出
1台のサーバ上にBIND9とUnbound
を5プロセスずつ起動
擬似クライアント
Nominum dnsperf付属のテストクエリリスト*
*Nominum queryfile example
ftp://ftp.nominum.com/pub/nominum/dnsperf/data/
48

総クエリ3,000,000
(100%)
BIND9: 解決可
Unbound: 解決可
2,070,048クエリ
(69.0%)
BIND9: 解決不可
Unbound: 解決不可
928,540クエリ
(30.9%)
BIND9: 解決不可
Unbound: 解決可
849クエリ
(0.0283%)
BIND9: 解決可
563クエリ
(0.0188%)
名前解決可とは、クエリタイプ(A,AAAA,MX...)と同じタイプのレコードがANSWER
SECTIONに存在すること。 (5プロセスのどれかが可であれば、可とした)
名前解決不可とは、解決可以外の状況(NXDOMAIN/NODATA/SERVFAIL etc..) (5プロ
セスの全てが不可のとき、不可とした)
49
Unbound 1.4.20 vs BIND9.9.4

総クエリ3,000,000
(100%)
BIND9: 解決可
Unbound: 解決可
2,070,048クエリ
(69.0%)
BIND9: 解決不可
928,540クエリ
(30.9%)
BIND9: 解決不可
Unbound: 解決可
849クエリ
(0.0283%)
BIND9: 解決可
563クエリ
(0.0188%)
BIND9とUnboundの名前解決のアルゴリズムの違いにより
・BIND9で引けるがUnboundで引けないドメインがごくわずかに存在する
・一方で、Unboundで引けるがBIND9で引けないドメインも存在する
名前解決可が多いことが正しいわけではないが、極端な差は無いと言える
50
Unbound 1.4.20 vs BIND9.9.4

Unboundまとめ
• DNSキャッシュサーバとしては十分な機能を持つ。BIND9にない、独
自のすぐれた機能もある。
• セキュリティ脆弱性は少ない (2012/2以降発生していない)
• BIND9に比べて約3倍の応答性能
• BIND9に比べて名前解決できないドメインが極端に多い、等の不具合
も確認されない
• 気になる問題点は特に無い。あえて問題点として挙げるなら、BIND9
固有の機能(Viewやキャッシュ権威同居機能）を使用している状況から、
Unboundに移行するのが困難ということが考えられる
51

まとめ
• DNSサーバといえばBIND9の利用が多いが、それ以外のすぐれ
た選択肢がある
• BIND9以外の選択肢として、権威サーバNSD、キャッシュサー
バUnboundを紹介
• NSDは必要十分な機能に実装を絞ったシンプルな権威サーバ
実装で、高速かつセキュリティ脆弱性が少ない。気になる点
もあるが、多くの用途でBIND9の代替として利用可能
• Unboundは、キャッシュサーバとしては十分な機能を持ち、
BIND9に無い独自の機能も持つ。高速かつセキュリティ脆弱
性が少ない
52

UnboundとNSDの紹介　BIND9との比較編

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to UnboundとNSDの紹介　BIND9との比較編

Similar to UnboundとNSDの紹介　BIND9との比較編 (20)