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

2,554 views
2,414 views

Published on

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

0 Comments
8 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
2,554
On SlideShare
0
From Embeds
0
Number of Embeds
3
Actions
Shares
0
Downloads
0
Comments
0
Likes
8
Embeds 0
No embeds

No notes for slide

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

  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

×