Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

キャッシュ・権威 兼用型浸透問題への対処

3,223 views

Published on

DNS移転失敗体験談 http://www.slideshare.net/ohesotori/dns-23491023 について、回避設定の考察

  • Be the first to comment

キャッシュ・権威 兼用型浸透問題への対処

  1. 1. キャッシュ・権威 兼用型浸透問題への対処 Version 1.0 @hdais 1
  2. 2. About • この話に関して • http://www.slideshare.net/ohesotori/ dns-23491023 • キャッシュ・権威兼用型浸透問題(勝 手に命名)を防止するDNSサーバの構 成・設定について考えてみる 2
  3. 3. なんでそんな設定が? • 負荷が多くない環境で権威とキャッシュを別々の サーバで運用するのはコスト高 • 別々にすると、冗長のため権威2台/キャッシュ2台の 計4台サーバが要る(IPアドレスも要る) • そんなに買えない。少し前まで仮想化なんていうのも のもなかった • BINDは古くから、キャッシュと権威の兼用が可能だっ た! • よほど先見の明がなけりゃ、兼用にしちゃうよ ね... • 結局、最低限の2台で権威・キャッシュ兼用サーバ運用 (ns1, ns2) 3
  4. 4. なんでそんな設定が?(cont.) • 直すのも簡単ではない! • 顧客のマスタDNSサーバに、AXFR要求許可するソースIPと してISPのns1とns2が設定されてる • 顧客のホストのresolv.confに「参照用サーバ」としてISPの ns1とns2が設定されている • 何年もそういう運用だったから、その設定は大量に! • 権威とキャッシュの分離はns1,ns2のアドレス変更を 意味する➡収容している顧客が多い場合は困難! 4
  5. 5. どうにかしよう • やはり、キャッシュサーバと権威サーバを物理的に (少なくともVMレベルで)分離することが原則 • 分離すると、トラフィック増対応や冗長構成が楽に なる • オープンリゾルバ対策も楽になる • キャッシュのIPを変えるか、権威のIPを変えるかは 時と場合による(顧客がどれだけ協力的かも) • キャッシュと権威の物理的分離の手順も、一大テー マだよね 5
  6. 6. 兼用サーバの典型的な BIND9設定 options { recursion yes; allow-query { any; }; }; zone "example.com" { file "example.com.zone"; type master; }; キャッシュとして動作する(デ フォルトでyesなので記載してい ない場合も) 当然のようにオープンリゾルバ 権威データの設定 6
  7. 7. 何が問題か? • BINDのデフォルトでは、キャッシュ(リゾルバ) 部分と、権威部分が混在して動作する • リゾルバは、他の権威サーバから得たデータのキ ャッシュだけでなく、ローカルの権威データ (example.com)も参照し、その内容を応答してしま う • これが兼用型浸透問題の原因! 7
  8. 8. 兼用ではなく混在が問題 • キャッシュへのクエリと、権威へのクエリが混在 して処理されることが問題 • キャッシュと権威の兼用サーバでも、この2つを 正しく区別・分離して動作するようにBINDを設 定すればよい 8
  9. 9. どうやって区別・分離するか? • BIND9のview機能は、クエリを分類して別々の処 理が可能。分類後の処理で参照するデータも全く 別になる。 • 分類時に参照可能な項目 • クエリのsrc IP (macth-clients):よく知られてる • クエリのRD bit (match-recursive-only) • リゾルバへのクエリかどうか(RD=1)で分類 • クエリのdst IP (match-destinations) • BINDが複数のIPをlistenしてる時に、どのIPに着信した かでview振分 9
  10. 10. 混在設定の修正をしてみる options { ... }; acl cache-clients { 192.0.2.0/24; 127.0.0.0/8; }; view "cache" { match-recursive-only yes; allow-query { cache-clients; }; recursion yes; }; view "authority" { allow-query { any; }; recursion no; zone "example.com" { file "example.com.zone"; type master; }; }; キャッシュview。このviewには RD=1のクエリにだけマッチして 処理される acl cache-clientsにマッチするクライアント のみキャッシュサービスを提供する(オー プンリゾルバにしない) 権威view。キャッシュviewにマッ チしなかったクエリ(i.e. RD=0)に マッチする 10
  11. 11. 他の項目でクエリ分類してview 振分すると? • クエリのsrc IP (macth-clients) • ISP環境では、srcIPで、権威/キャッシュどちらに 向けられたクエリか区別することは困難 • クエリのdst IP (match-destinations) • サーバに複数のIPをつけて、namedにそれらのIPを listenさせつつmatch-desitinationでview分離すること は、物理サーバ(仮想サーバ)を分離することに等し い 11
  12. 12. RD bitで処理viewを分離 する時の注意点(1) view "authority" { match-recursive-only no; allow-query { any; }; recursion no; zone "example.com" { file "example.com.zone"; type master; }; }; view "cache" { match-recursive-only yes; allow-query { cache-clients; }; recursion yes; }; BIND9設定の上から下へ記載順に マッチするviewを捜すので注意! match-recursive-only yesは、RD=1 のクエリのみがマッチ、 match-recursive-only noは、 RD=0or1の両方のクエリがマッチ するので、 のように authority view を先に 書くとNG 12
  13. 13. RD bitで処理viewを分離 する時の注意点(2) • サーバにdigする時は、常に権威へのクエリか キャッシュへのクエリか意識する必要がある • 権威へのクエリ • dig @127.0.0.1 www.example.com +norec • キャッシュへのクエリ • dig @127.0.0.1 www.google.com +rec 13
  14. 14. RD bitで処理viewを分離 した時の注意点(3) • 一時的な回避のための設定と認識すべし • そもそも、本設定はBIND9の機能に依 存し過ぎ。BIND10では同機能は未実装 の模様 • 同様の設定は BIND9以外で可能なもの は知られていない (ややウソ: PowerDNSではできないことはない) • 権威とキャッシュは物理的分離の作業は 進めるべき 14
  15. 15. END 15

×