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

1. キャッシュ・権威
兼用型浸透問題への対処
Version 1.0
@hdais
1

2. About
• この話に関して
• http://www.slideshare.net/ohesotori/
dns-23491023
• キャッシュ・権威兼用型浸透問題（勝
手に命名）を防止するDNSサーバの構
成・設定について考えてみる
2

3. なんでそんな設定が？
• 負荷が多くない環境で権威とキャッシュを別々の
サーバで運用するのはコスト高
• 別々にすると、冗長のため権威２台／キャッシュ２台の
計４台サーバが要る(IPアドレスも要る)
• そんなに買えない。少し前まで仮想化なんていうのも
のもなかった
• BINDは古くから、キャッシュと権威の兼用が可能だっ
た！
• よほど先見の明がなけりゃ、兼用にしちゃうよ
ね...
• 結局、最低限の2台で権威・キャッシュ兼用サーバ運用
(ns1, ns2)
3

4. なんでそんな設定が？(cont.)
• 直すのも簡単ではない！
• 顧客のマスタDNSサーバに、AXFR要求許可するソースIPと
してISPのns1とns2が設定されてる
• 顧客のホストのresolv.confに「参照用サーバ」としてISPの
ns1とns2が設定されている
• 何年もそういう運用だったから、その設定は大量に！
• 権威とキャッシュの分離はns1,ns2のアドレス変更を
意味する➡収容している顧客が多い場合は困難！
4

5. どうにかしよう
• やはり、キャッシュサーバと権威サーバを物理的に
（少なくともVMレベルで）分離することが原則
• 分離すると、トラフィック増対応や冗長構成が楽に
なる
• オープンリゾルバ対策も楽になる
• キャッシュのIPを変えるか、権威のIPを変えるかは
時と場合による（顧客がどれだけ協力的かも）
• キャッシュと権威の物理的分離の手順も、一大テー
マだよね
5

6. 兼用サーバの典型的な
BIND9設定
options {
recursion yes;
allow-query { any; };
};
zone "example.com" {
file "example.com.zone";
type master;
};
キャッシュとして動作する（デ
フォルトでyesなので記載してい
ない場合も)
当然のようにオープンリゾルバ
権威データの設定
6

7. 何が問題か？
• BINDのデフォルトでは、キャッシュ（リゾルバ）
部分と、権威部分が混在して動作する
• リゾルバは、他の権威サーバから得たデータのキ
ャッシュだけでなく、ローカルの権威データ
(example.com)も参照し、その内容を応答してしま
う
• これが兼用型浸透問題の原因！
7

8. 兼用ではなく混在が問題
• キャッシュへのクエリと、権威へのクエリが混在
して処理されることが問題
• キャッシュと権威の兼用サーバでも、この２つを
正しく区別・分離して動作するようにBINDを設
定すればよい
8

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. 混在設定の修正をしてみる
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. 他の項目でクエリ分類してview
振分すると？
• クエリのsrc IP (macth-clients)
• ISP環境では、srcIPで、権威／キャッシュどちらに
向けられたクエリか区別することは困難
• クエリのdst IP (match-destinations)
• サーバに複数のIPをつけて、namedにそれらのIPを
listenさせつつmatch-desitinationでview分離すること
は、物理サーバ(仮想サーバ)を分離することに等し
い
11

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. 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. RD bitで処理viewを分離
した時の注意点(3)
• 一時的な回避のための設定と認識すべし
• そもそも、本設定はBIND9の機能に依
存し過ぎ。BIND10では同機能は未実装
の模様
• 同様の設定は BIND9以外で可能なもの
は知られていない (ややウソ：
PowerDNSではできないことはない）
• 権威とキャッシュは物理的分離の作業は
進めるべき
14

15. END
15