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

http://unbound.jp

http://unbound.net

はじめに

3

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の紹介

12

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が持つ全機能は網羅している）

• しかし、NSDは、通常の利用方法なら問題ない程度の機能は持つ

• NSDには無くても、他の実装では提供されている場合もあるので、どうしても必要ならそちらを検討するのもいいかも

NSD 4.1.0 vs BIND 9.9.5

16

NSD4とBIND9の比較機能編(1)

• NSDに無い機能: Dynamic Update

• ゾーンファイルを編集せずに、ゾーンの特定のレコードを変更する機能

• DHCPでPCのIPアドレスを動的に配っている環境などで使用されることがある（PCのIPが変わるたびにゾーン情報を更新）

• Knot DNSは Dynamic updateが可能の模様

NSD 4.1.0 vs BIND 9.9.5

17


• NSDに無い機能: マスタサーバ側のIXFR機能

• ゾーン転送時に、ゾーン全体の転送(AXFR)ではなく、更新差分のみをスレーブに提供する機能

• 超巨大なゾーン(TLDなど)を提供している場合でない限り、転送量が問題になることはあまりない

• NSD4はスレーブサーバとしてのIXFR機能は実装している

• マスタ側がIXFR転送を提供してる場合は、差分転送は可能

NSD 4.1.0 vs BIND 9.9.5

18


• NSDに無い機能: DNSSEC自動署名機能

• BIND9はDNSSEC自動署名機能(inline signing)を持つが、NSD4は持たない

• NSD4でも、OpenDNSSEC、dnsseczonetool等のDNSSEC自動署名ツールを併用すれば問題なし

NSD 4.1.0 vs BIND 9.9.5

19


• NSDに無い機能: キャッシュサーバ（リゾルバ）

• NSDは権威サーバ専用なので当然

• BIND9は権威サーバとキャッシュサーバの同居が可能で、そのような運用も多数見られるが、セキュリティ上・運用上の問題を引き起こすことがあるので、避けるべき

参考：「DNS移転失敗体験談」by oheso tori 　 http://www.slideshare.net/ohesotori/dns-23491023

20

http://www.slideshare.net/ohesotori/dns-23491023


• NSDに無い機能: View機能

• DNS問い合わせのソースIPアドレス等によって、応答を変える（応答に使用するゾーンファイルを変える）

• 本当に要ります？

21

NSD4とBIND9の比較設定編(1)

server: username: “nsd”

zone: 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; }; };

NSD4設定ファイル BIND9設定ファイル

設定ファイルのスタイルには違いはあるが、設定内容はほとんど同じ

22

http://example.net

http://example.net

http://example.com




zone: name: “example.com” request-xfr: 192.0.2.2 NOKEY



zone “example.net” { type master; file “/etc/dns/master/example.net” allow-transfer { 192.0.2.1; }; also-notify { 192.0.2.1; }; };




マスターゾーンの設定　参照するゾーンファイルの指定と、ゾーン転送を許可するslaveサーバと、ゾーン更新時にnotifyを送信するslaveサーバの指定。NOKEYはTSIG使用しないという意味。 ※BIND9ではalso-notify指定しなくても、ゾーンファイルのNSレコードから自動的にnotify先を見つけてくれるが、NSD４では指定要。BIND9でもステルスサーバ構成時や名前解決そのものが失敗する場合にうまくいかないため常に指定したほうがよい。

23

http://example.net

http://example.net

http://example.com




zone: name: “example.com” request-xfr: 192.0.2.2 NOKEY allow-notify: 192.0.2.2 NOKEY







スレーブゾーンの設定　マスターサーバの設定。NSDはallow-notifyでnotifyを許可するマスタサーバを指定する必要がある。　NSDでは、ゾーン転送で取得したゾーンはNSD DBファイル(nsd.db)に自動的に保存される

24

http://example.net

http://example.net

http://example.com




zone: name: “example.com” request-xfr: 192.0.2.2 NOKEY







リモートコントロールクライアントの指定 NSDではnsd-control（BIND9では rndc）というクライアントで制御できる

25

http://example.net

http://example.net

http://example.com


• ゾーンファイルは、基本的にはBIND9とNSDで同じものが使える

• BIND固有の$GENERATE構文は、NSDでは使えない

• $GENERATE構文含むゾーンファイルを読み込んでいるBIND9マスタから、NSD4スレーブにゾーン転送するのは問題なし

26

NSD4とBIND9の比較運用編(1)

• BIND9 (named)の操作は rndc コマンドで行うが、NSD4 (nsd)の操作は nsd-control コマンドで行う。使用感は似ている。

• nsd-control start | stop

• NSDの起動 | 停止

• nsd-control reconfig

• 設定ファイル (nsd.conf)の再読込27

NSD4とBIND9の比較運用編(2)

• nsd-control reload [zone]

• zoneのゾーンファイルを再読込 ([zone]を省略すれば全ゾーン再読込)

• nsd-control transfer <zone> | force_transfer <zone>

• スレーブゾーンを転送 | シリアルチェックせずに強制転送 (rndc retransfer相当)

28

NSDのセキュリティ脆弱性

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)攻撃の脆弱性がほとんどを占める

NSDは、BIND9に比べてセキュリティ脆弱性の発生頻度は小さい。

セキュリティ脆弱性発生頻度

29

NSDの性能

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

ベンチマークによれば、NSD4はBIND9の3倍以上の応答性能

NSD4/BIND9　応答性能比較

30

NSDの気になるところ(1)• スレーブゾーンのゾーン転送手順に難あり

• 極めて多数のゾーンを保持する用途（DNSホスティング等）では高負荷の懸念

• ドキュメントには記載はされているが、実装を単純にするために、こうしてるとのこと

• 私も開発元に改善を要望したことはあるが修正はされていない

31

NSDの気になるところ(2)

• マスタサーバに、当該ゾーンのSOAレコードをUDPで問い合わせ

• ゾーンのシリアルが更新されていたら、マスタサーバからゾーン転送開始

• シリアルが更新されていなかったら、ゾーン転送しない

example.com SOA?

SOA serial=2014101801

BIND9 slave master

example.com AXFR request

example.com ゾーン転送

BIND9スレーブのゾーン転送手順

SOAのREFRESH時間毎に、以下を実施

32

NSDの気になるところ(3)

• 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

http://heartbeats.jp/hbblog/2014/09/nsd-roundrobin.html

NSDまとめ• BIND9ほどの豊富な機能があるわけではないが、通常の利用では必要十分な機能が提供されている

• NSD4の制御はnsd-controlで行うが、BIND9のrndcと使用感は似ている

• セキュリティ脆弱性は少ない (2012/7以降発生していない)

• NSD4は約3倍の応答性能 (BIND9.9との比較)

• 運用上の問題（ゾーン転送手順）も無くはない・・・

35

Unboundの紹介

36

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


• Unboundに無い、BIND9にある主な機能

• 権威DNSサーバ機能

• Unboundはキャッシュサーバ専用。ただしローカルデータは定義可

• 「www.example.comのAレコードのクエリは、権威サーバに聞きに行かずに192.0.2.1で応答する」という設定は可能

• View

• クライアントのソースIPなどにより動作を変える機能。キャッシュサーバに要る？

42


• Unboundに有り、BIND9に無い主な機能

• Negative Trust Anchor

• 指定したドメイン名をDNSSEC Validationしない機能。権威サーバ側のDNSSEC運用ミスでbogusになったドメインを一時的に引けるようにする

• キャッシュポイズニング攻撃の部分的検知

• カミンスキー型などのポイズニング攻撃を検知*し、一定の閾値を超えたらログ出力・キャッシュクリア（攻撃検知は可能、防御できるわけではない）

• デフォルトではオフ

43* TXIDの不一致をカウント

Negative Trust Anchorの必要性

44

最近の主要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

http://example.com

セキュリティ脆弱性の頻度の比較

2014※ 2013 2012 2011 2010

Unbound 0 0 1 2 1

BIND9 2 4 7 5 7

※2014/10まで・各年度のCVE発行数をカウント　・BIND9はキャッシュサーバとして設定した場合に該当する脆弱性のみ抽出　・各脆弱性の影響の大きさは考慮に入れずカウントしている・UnboundもBIND9も、サービス停止(DoS)攻撃の脆弱性がほとんどを占める

Unboundは、BIND9に比べてセキュリティ脆弱性の発生頻度は小さい。

セキュリティ脆弱性発生頻度

45

名前解決速度

46

キャッシュヒット率→ 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

ベンチマークによれば、Unboundは、BIND9の3倍程度の性能を出している

名前解決成功率測定• 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 ……………

BIND9BIND9BIND9BIND9BIND9

UnboundUnboundUnbound

UnboundUnbound

インターネット（権威サーバ群）

擬似クライアントから、サーバ上のBIND9/Unboundにクエリ送出

1台のサーバ上にBIND9とUnboundを5プロセスずつ起動

擬似クライアント

Nominum dnsperf付属のテストクエリリスト*

*Nominum queryfile example

ftp://ftp.nominum.com/pub/nominum/dnsperf/data/

48

ftp://ftp.nominum.com/pub/nominum/dnsperf/data/

名前解決成功率測定

名前解決可とは、クエリタイプ(A,AAAA,MX...)と同じタイプのレコードがANSWER SECTIONに存在すること。 (5プロセスのどれかが可であれば、可とした)

名前解決不可とは、解決可以外の状況(NXDOMAIN/NODATA/SERVFAIL etc..) (5プロセスの全てが不可のとき、不可とした)

総クエリ 3,000,000 (100%)

BIND9: 解決可 Unbound: 解決可

2,070,048クエリ (69.0%)

BIND9: 解決不可 Unbound: 解決不可

928,540クエリ (30.9%)

BIND9: 解決不可 Unbound: 解決可

849クエリ (0.0283%)

BIND9: 解決可 Unbound: 解決不可

563クエリ (0.0188%)

49

Unbound 1.4.20 vs BIND9.9.4

名前解決成功率測定総クエリ 3,000,000

(100%)BIND9: 解決可 Unbound: 解決可

2,070,048クエリ (69.0%)

BIND9: 解決不可 Unbound: 解決不可

928,540クエリ (30.9%)

BIND9: 解決不可 Unbound: 解決可

849クエリ (0.0283%)

BIND9: 解決可 Unbound: 解決不可

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

QUESTIONS?

53

unboundとnsdの紹介 bind9との比較編

Technology

unboundとnsdの紹介　bind9との比較編