![NSD4とBIND9の比較
運用編(2)
• nsd-control reload [zone]
• zoneのゾーンファイルを再読込 ([zone]を省略
すれば全ゾーン再読込)
• nsd-control transfer <zone> | force_transfer <zone>
• スレーブゾーンを転送 | シリアルチェックせず
に強制転送 (rndc retransfer相当)
28](https://image.slidesharecdn.com/nsd-unbound-intro-141019234019-conversion-gate02/85/Unbound-NSD-BIND9-28-320.jpg)
UnboundとNSDの紹介 BIND9との比較編
- 1. UnboundとNSDの紹介 BIND9との比較編 日本Unboundユーザ会 東 大亮 (平会員) オープンソースカンファレンス 2014 Tokyo/Fall 2014/10/19 1
- 2. 日本Unboundユーザ会に ついて • 滝澤さん (@ttkzw) が運営されてる謎の会 • http://unbound.jp • UnboundやNSDやldnsのマニュアルの翻訳等 • 本家 (http://unbound.net) からも公認されてる • 私はユーザ会のMLに参加してるだけ…… 2
- 3. はじめに 3
- 4. DNSサーバといえば？ • BIND9が第一選択とすることが、多いのではないでしょ うか • 前から使ってたし • Google検索したら設定例出てくるし • 書籍も多いし • 急に「DNSサーバ作って！」と言われた時なんか、慣れ たBIND9で構築してしまう 4
- 5. BIND9以外の選択肢の例 • 権威サーバ • NSD • PowerDNS • Knot DNS • Yadifa • キャッシュサーバ • Unbound • PowerDNS recursor • Deadwood (MaraDNS) 5
- 6. なぜBIND9以外の DNSサーバか？ • BIND9は歴史も長く、機能豊富のため、他の実装 ができることは、BIND9でも大体できる • なぜBIND9以外の選択肢が必要なのか？ 6
- 7. BIND9のいいところ • 機能が豊富 • とにかく多い！ • なんでもできるとしても過言でない • 使い方を知っている人が多い • Google先生に聞けば設定例が出てくる • そのへんのおじさんに聞けば大抵わかる 7
- 8. BIND9の残念なところ(1) • （機能が豊富ゆえに）複雑すぎる • ほとんどの用途では不要な機能が多数→現在も絶 賛肥大化中 • 権威サーバ機能とキャッシュサーバ機能が同時に オンになっている等、運用上のトラブルの原因と なるデフォルト設定 8
- 9. BIND9の残念なところ(2) • 脆弱性が多い • 毎年、セキュリティ脆弱性が複数発生 • パケット一発でプロセス停止、みたいな致命的なのが多い • BIND9へのゼロデイアタックが発生したら全滅 • 性能は高いとは言えない • 他の実装に比べると、BIND9の動作は遅い 9
- 10. NSD/Unboundのすすめ • DNSサーバとして本当に必要な機能のみに絞った シンプルな実装 • とはいっても、Unboundは機能豊富 • 脆弱性が少ない • 性能がそこそこ高い 10
- 11. この発表について • BIND9以外の実装に興味があるが、よく分からないので 不安がある方のために検討材料を提供 • 他の実装の例としてNSD/Unboundを、BIND9との比 較を中心に紹介 • BIND9ダメ！Unbound/NSDイイ！というつもりはな く、メリット・デメリットを明確化したい • NSD/Unboundのインストール方法や細かな設定方法に はあまり触れません 11
- 12. NSDの紹介 12
- 13. NSDとは • “Name Server Daemon” • 権威DNSサーバ専用 • キャッシュサーバ（フルリゾルバサービス）機能は持たない • BSDスタイルライセンス • Unix系OSで動作(GNU/Linux, FreeBSD, Solaris,.. etc) • 簡単にインストールできるよう、多くのLinuxディストリビュー ション/FreeBSD/NetBSDでパッケージが用意されている 13
- 14. 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
- 15. NSDとは(3) • NSDが適するユースケース • インターネット全体に公開するドメイン名の権威サーバ • rootサーバ・TLDサーバで多くの実績あり。DNSホスティ ングでも利用例が増えてきている • マスタサーバにも、スレーブサーバにもなれる • DNSSEC署名されたゾーンも提供可能 • 内部のみに公開するドメインの権威サーバとしてももちろん可 15
- 16. NSD4とBIND9の比較 機能編 • BIND9にあるが、NSDに無い主な機能は？ • 機能数だけみれば、NSDはBIND9より少ない（BIND9 NSD 4.1.0 vs BIND 9.9.5 はNSDが持つ全機能は網羅している） • しかし、NSDは、通常の利用方法なら問題ない程度 の機能は持つ • NSDには無くても、他の実装では提供されている場合 もあるので、どうしても必要ならそちらを検討するのも いいかも 16
- 17. NSD4とBIND9の比較 機能編(1) NSD 4.1.0 vs BIND 9.9.5 • NSDに無い機能: Dynamic Update • ゾーンファイルを編集せずに、ゾーンの特定のレコー ドを変更する機能 • DHCPでPCのIPアドレスを動的に配っている環境 などで使用されることがある（PCのIPが変わるた びにゾーン情報を更新） • Knot DNSは Dynamic updateが可能の模様 17
- 18. NSD4とBIND9の比較 機能編(2) NSD 4.1.0 vs BIND 9.9.5 • NSDに無い機能: マスタサーバ側のIXFR機能 • ゾーン転送時に、ゾーン全体の転送(AXFR)ではなく、更新 差分のみをスレーブに提供する機能 • 超巨大なゾーン(TLDなど)を提供している場合でない限 り、転送量が問題になることはあまりない • NSD4はスレーブサーバとしてのIXFR機能は実装している • マスタ側がIXFR転送を提供してる場合は、差分転送は可能 18
- 19. NSD4とBIND9の比較 機能編(3) NSD 4.1.0 vs BIND 9.9.5 • NSDに無い機能: DNSSEC自動署名機能 • BIND9はDNSSEC自動署名機能(inline signing) を持つが、NSD4は持たない • NSD4でも、OpenDNSSEC、dnsseczonetool 等のDNSSEC自動署名ツールを併用すれば問題 なし 19
- 20. NSD4とBIND9の比較 機能編(4) • NSDに無い機能: キャッシュサーバ（リゾルバ） • NSDは権威サーバ専用なので当然 • BIND9は権威サーバとキャッシュサーバの同居が 可能で、そのような運用も多数見られるが、セキュ リティ上・運用上の問題を引き起こすことがある ので、避けるべき 参考：「DNS移転失敗体験談」by oheso tori http://www.slideshare.net/ohesotori/dns-23491023 20
- 21. NSD4とBIND9の比較 機能編(5) • NSDに無い機能: View機能 • DNS問い合わせのソースIPアドレス等によっ て、応答を変える（応答に使用するゾーンファ イルを変える） • 本当に要ります？ 21
- 22. NSD4とBIND9の比較 設定編(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
- 23. NSD4とBIND9の比較 設定編(2) server: NSD4設定ファイルBIND9設定ファイル 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 指定と、ゾーン転送を許可するslaveサーバと、ゾーン更新時 にnotifyを送信するslaveサーバの指定。NOKEYはTSIG使用しないという意味。 ※remote-BIND9ではcontrol: also-notify指定し要。BIND9control-でもステenable: ルスサーバ構yes なくても、ゾーンファイルのNSレコードから自動的にnotify先を見つけてくれるが、NSD４では指定 成時や名前解決そのものが失敗する場合にうまくいかないため常に指定したほうがよい。 option { recursion no; }; zone “example.net” { type master; file “/etc/dns/master/example.net” allow-transfer { 192.0.2.1; }; 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; }; }; 23
- 24. NSD4とBIND9の比較 設定編(3) server: NSD4設定ファイルBIND9設定ファイル username: “nsd” スレーブゾーンの設定 マzone: スターサーバの設定。NSDはallow-notifyでnotifyを許可するマスタサーバを指定す る必要がある。 NSDでは、ゾーン転送で取得したゾーンはNSD DBファイル(nsd.db)に自動的に保存される 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” allow-transfer { 192.0.2.1; }; 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; }; }; 24
- 25. NSD4とBIND9の比較 設定編(4) server: NSD4設定ファイルBIND9設定ファイル 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 リモートコントロールクライアントの指定 NSDzone: ではnsd-control（BIND9では rndc）というクライアントで制御できる name: “example.com” request-xfr: 192.0.2.2 NOKEY remote-control: control-enable: yes option { recursion no; }; zone “example.net” { type master; file “/etc/dns/master/example.net” allow-transfer { 192.0.2.1; }; 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; }; }; 25
- 26. NSD4とBIND9の比較 設定編(5) • ゾーンファイルは、基本的にはBIND9とNSDで同じも のが使える • BIND固有の$GENERATE構文は、NSDでは使えない • $GENERATE構文含むゾーンファイルを読み込んでいるBIND9 マスタから、NSD4スレーブにゾーン転送するのは問題なし 26
- 27. NSD4とBIND9の比較 運用編(1) • BIND9 (named)の操作は rndc コマンドで行うが、 NSD4 (nsd)の操作は nsd-control コマンドで行う。使用 感は似ている。 • nsd-control start | stop • NSDの起動 | 停止 • nsd-control reconfig • 設定ファイル (nsd.conf)の再読込 27
- 28. NSD4とBIND9の比較 運用編(2) • nsd-control reload [zone] • zoneのゾーンファイルを再読込 ([zone]を省略 すれば全ゾーン再読込) • nsd-control transfer <zone> | force_transfer <zone> • スレーブゾーンを転送 | シリアルチェックせず に強制転送 (rndc retransfer相当) 28
- 29. 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
- 30. 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
- 31. NSDの気になるところ(1) • スレーブゾーンのゾーン転送手順に難あり • 極めて多数のゾーンを保持する用途（DNSホスティ ング等）では高負荷の懸念 • ドキュメントには記載はされているが、実装を単 純にするために、こうしてるとのこと • 私も開発元に改善を要望したことはあるが修正は されていない 31
- 32. NSDの気になるところ(2) • マスタサーバに、当該ゾーンのSOA レコードをUDPで問い合わせ • ゾーンのシリアルが更新されてい たら、マスタサーバからゾーン転 送開始 • シリアルが更新されていなかった ら、ゾーン転送しない BIND9 slave master example.com SOA? SOA serial=2014101801 example.com AXFR request example.com ゾーン転送 BIND9スレーブのゾーン転送手順 SOAのREFRESH時間毎に、以下を実施 32
- 33. NSDの気になるところ(3) • SOAレコードをUDPで問い合 わせしない。いきなりゾーン転 送開始 • ゾーン転送の先頭メッセージに あるSOAレコードのシリアルを 見て、シリアル更新されていな かったらTCP切断 NSD slave master example.com AXFR request example.com ゾーン転送 NSDスレーブのゾーン転送手順 SOAのREFRESH時間毎に、以下を実施 serial更新有無にかかわらず、毎REFRESH時間に ゾーン転送が行われる →ゾーン数が多いと、負荷が大きくなる懸念 33
- 34. NSDの噂 • NSDは、DNSラウンドロビンができない？ • NSD 4.1.0 (2014/9リリース)で実装されました • round-robin: yes • 滝澤さんの解説記事 • http://heartbeats.jp/hbblog/2014/09/nsd-roundrobin. html 34
- 35. NSDまとめ • BIND9ほどの豊富な機能があるわけではないが、通常の利用 では必要十分な機能が提供されている • NSD4の制御はnsd-controlで行うが、BIND9のrndcと使用 感は似ている • セキュリティ脆弱性は少ない (2012/7以降発生していない) • NSD4は約3倍の応答性能 (BIND9.9との比較) • 運用上の問題（ゾーン転送手順）も無くはない・・・ 35
- 36. Unboundの紹介 36
- 37. Unboundとは • “Unbound” ⇔ “BIND” ? • DNSキャッシュサーバ（フルリゾルバサービス）専用 • 権威DNSサーバ機能は持たない（ローカルデータは定義可） • BSDスタイルライセンス • Unix系OS(GNU/Linux, FreeBSD,..etc)とWindowsで動作 • 簡単にインストールできるよう、多くのLinuxディストリビューション/ FreeBSD/NetBSDでパッケージが用意されている • Windows版はインストーラ付きバイナリが提供され、Windowsサービス として動作する 37
- 38. 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
- 39. Unboundの主な機能 • DNSキャッシュサーバ機能 • ソースIP規制、TXID/port radomisationなどのキャッシュポイズニン グ防止、IPv4/IPv6デュアルスタック等、一通りの機能は装備 • DNSSEC Validator機能 • RSA2048, SHA-256, NSEC3, ECDSA, ECCGOST等、標準的なも のはもちろん、最新規格のアルゴリズムを実装。RFC5011 Trust Anchor自動更新にも対応 • 権威DNSサーバ機能は無いが、ローカルデータは設定可能 • dns64やdnstapのような新機能も最近追加 (次回リリースで入る予定) 39
- 40. Unboundが適する ユースケース • インターネット上のドメイン名を解決するためのフルリゾ ルバサーバ。以下のどの用途にも適する • xSPで提供されているような、多数の端末やVPS向けに サービスするDNSキャッシュサーバ • ローカルで自分専用に動作させるDNSキャッシュサーバ • 最近はxSPのキャッシュサーバもDDoSで止まるこ とがあるので、自前のキャッシュサーバを用意する のもお勧め 40
- 41. UnboundとBIND9の比較 機能編(1) • UnboundとBIND9の機能比較 • キャッシュサーバとしては、Unboundもそれな りに機能豊富。BIND9に無い機能もいくつか搭載 している • Unbound固有の機能、BIND9固有の機能それぞ れがある 41
- 42. UnboundとBIND9の比較 機能編(2) • Unboundに無い、BIND9にある主な機能 • 権威DNSサーバ機能 • Unboundはキャッシュサーバ専用。ただしローカルデータ は定義可 • 「www.example.comのAレコードのクエリは、権威サーバに 聞きに行かずに192.0.2.1で応答する」という設定は可能 • View • クライアントのソースIPなどにより動作を変える機能。 キャッシュサーバに要る？ 42
- 43. UnboundとBIND9の比較 機能編(3) • Unboundに有り、BIND9に無い主な機能 • Negative Trust Anchor • 指定したドメイン名をDNSSEC Validationしない機能。権 威サーバ側のDNSSEC運用ミスでbogusになったドメイン を一時的に引けるようにする • キャッシュポイズニング攻撃の部分的検知 • カミンスキー型などのポイズニング攻撃を検知*し、一定の 閾値を超えたらログ出力・キャッシュクリア（攻撃検知は 可能、防御できるわけではない） • デフォルトではオフ 43 * TXIDの不一致をカウント
- 44. 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
- 45. セキュリティ脆弱性の 頻度の比較 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
- 46. 名前解決速度 ベンチマークによれば、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
- 47. 名前解決成功率測定 • Unboundに対する不安 • ドメイン運用者は、BIND9のリゾルバでは自分のドメイン 名が引けるかテストしてるだろうが、Unboundではテスト してないだろう？ • 相性問題のようなもので、Unboundで引けないドメインが たくさんあるのではないか？ UnboundとBIND9に、多数のドメイン名を解決させて成功率・失 敗率を測定してみた → 失敗率に大きな差がなければ、BIND9とUnboundは同等の性 能と言える 47
- 48. 名前解決成功率測定 多数の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
- 49. 名前解決成功率測定 総クエリ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%) 名前解決可とは、クエリタイプ(A,AAAA,MX...)と同じタイプのレコードがANSWER SECTIONに存在すること。 (5プロセスのどれかが可であれば、可とした) 名前解決不可とは、解決可以外の状況(NXDOMAIN/NODATA/SERVFAIL etc..) (5プロ セスの全てが不可のとき、不可とした) 49 Unbound 1.4.20 vs BIND9.9.4
- 50. 名前解決成功率測定 総クエリ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
- 51. Unboundまとめ • DNSキャッシュサーバとしては十分な機能を持つ。BIND9にない、独 自のすぐれた機能もある。 • セキュリティ脆弱性は少ない (2012/2以降発生していない) • BIND9に比べて約3倍の応答性能 • BIND9に比べて名前解決できないドメインが極端に多い、等の不具合 も確認されない • 気になる問題点は特に無い。あえて問題点として挙げるなら、BIND9 固有の機能(Viewやキャッシュ権威同居機能）を使用している状況から、 Unboundに移行するのが困難ということが考えられる 51
- 52. まとめ • DNSサーバといえばBIND9の利用が多いが、それ以外のすぐれ た選択肢がある • BIND9以外の選択肢として、権威サーバNSD、キャッシュサー バUnboundを紹介 • NSDは必要十分な機能に実装を絞ったシンプルな権威サーバ 実装で、高速かつセキュリティ脆弱性が少ない。気になる点 もあるが、多くの用途でBIND9の代替として利用可能 • Unboundは、キャッシュサーバとしては十分な機能を持ち、 BIND9に無い独自の機能も持つ。高速かつセキュリティ脆弱 性が少ない 52
- 53. QUESTIONS? 53