• Save
キャッシュ・権威 兼用型浸透問題への対処
Upcoming SlideShare
Loading in...5
×
 

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

on

  • 2,178 views

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

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

Statistics

Views

Total Views
2,178
Views on SlideShare
1,887
Embed Views
291

Actions

Likes
3
Downloads
0
Comments
0

2 Embeds 291

http://d.hatena.ne.jp 247
https://twitter.com 44

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

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

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