PDF 277KB

Practical Cache Server Operation
～量と質、様々なQueryに対応するには～
Internet Week 2004
NTTコミュニケーションズ(OCN)
大島 治彦
2004/12/03
1
Today’s Topic
ｲﾝﾀｰﾈｯﾄの普及によりCache Serverは常に忙しい。
｢異常/正常｣どちらのQueryも増え続ける。
どうする？
„
様々なﾀｲﾌﾟの大量Query
„
Authorative Serverとの関係
„
Cache Serverのｽｹｰﾗﾋﾞﾘﾃｨ
2004/12/03
2
1
大量Query(1)
2004/12/03
3
同一SrcIPからの大量Query
„
DoS、不正ｱｸｾｽ、ﾕｰｻﾞの設定ﾐｽ
(ServFail、NXDomain、PrivateIP逆引き･･･)
„
Webｻｰﾊﾞのﾛｸﾞ解析ﾂｰﾙ
(大量の逆引き)
2004/12/03
4
2
検知と対処
„
CPU使用率、Queryﾚｰﾄ(qps)、nslookup遅延
の閾値
„
QueryﾛｸﾞやF/WでのSrcIPの特定
„
BINDのBlackholeやF/Wでｱｸｾｽ拒否
5
2004/12/03
大量Query(2)
2004/12/03
6
3
大量のSrcIPからの特定のQuery
Wormが特定のｻｲﾄをｱﾀｯｸ
(MS Blast、Mydoom、Netsky、Antinny…)
„ DDoS(FQDNを引くもの)
„
ｱﾀｯｸﾄﾗﾌｨｯｸで被攻撃ｻｲﾄとﾈｯﾄﾜｰｸが輻輳
„ ｸﾗｲｱﾝﾄがNXDomainをｷｬｯｼｭせず、連続
QueryでCache Serverが高負荷
„
7
2004/12/03
対処
„
Forwardersと偽ｿﾞｰﾝｻｰﾊﾞでの代理応答
高負荷
高負荷
から救われる
から救われる
被攻撃ｻｲﾄ
偽zone管理用
偽zone管理用
DNSサーバ
DNSサーバ
DDoS攻撃
DDoS攻撃
から救われる
から救われる
forwarders設定
網内で廃棄
Wormに感染した
エンドユーザ
③DDoS攻撃
③DDoS攻撃
②網内廃棄用の
②網内廃棄用の
IPｱﾄﾞﾚｽを返す
IPｱﾄﾞﾚｽを返す
2004/12/03
Cache
Cache Server
Server
①被攻撃ｻｲﾄの
①被攻撃ｻｲﾄの
名前解決要求
名前解決要求
8
4
Authoritative Serverとの関係
9
2004/12/03
原因不明のCache Server高負荷
Query数は正常、でもCache Serverは高負荷
„ 何故かTCPのSYN_SENTの数と連動
„
140
120
CPU Utilization of Named(%)
100
Numbers of SYN_SENT for DNS
80
60
40
20
0
6/8 0:00
2004/12/03
6/8 6:00
6/8 12:00
6/8 18:00
6/9 0:00
6/9 6:00
10
5
TCP Connectionが何故増える？
TC(Truncated)ﾋﾞｯﾄが立ったﾊﾟｹｯﾄ数と連動
„
600
600
500
500
400
400
300
300
200
200
100
100
0
6/5
0
6/6
6/7
6/8
Number of TCP packets sent to
authoritative servers (per 5 min.)
6/5
6/6
6/7
6/8
Number of truncated answers from
authoritative servers (per 5 min.)
11
2004/12/03
SYN_SENT発生のメカニズム
Authorative Serverが大きなRR Setを登録
„ しかも、EDNS0に対応せずTCPもﾌｨﾙﾀ
„
User
query
Authoritative
Authoritative server
server
Cache
Cache server
server
(1) query(UDP)
(2) Response with TC bit(UDP)
(3) Resend query(TCP)
(3) Retry
(4) Try another connection
No response
No response
No response
Timeout
ServFail
(結果は
結果はｷｬｯｼｭしない
ｷｬｯｼｭしない)
しない)
注)
注) 高負荷が発生するのはBIND8。BIND9では発生しない。
高負荷が発生するのはBIND8。BIND9では発生しない。
2004/12/03
12
6
対処は？
„
Authoritative Serverの管理者への依頼
… RR
Setのｻｲｽﾞを小さく
… TCPでのｱｸｾｽを許可
… EDNS0への対応
„
BINDのBlackhole設定で該当ﾕｰｻﾞからの
Queryを拒否
„
Forwarders設定と偽ｿﾞｰﾝｻｰﾊﾞでの代理応
答
13
2004/12/03
EDNS0とTCPﾌｨﾙﾀの関係
„
Cache Server
Authoritative Server
„
EDNS0
対応
EDNS0
対応
TCP
対応
(RFCでは必須)
○
○
×
○
×
×
×
○
×
×
×
×
2004/12/03
TCPを開ければ
問題なし。
TCPが開けられ
ないとEDNS0が
必須。
TCPをﾌｨﾙﾀすると
TCPをﾌｨﾙﾀすると
512ｵｸﾃｯﾄ超で
512ｵｸﾃｯﾄ超で
SYN_SENTが発生
SYN_SENTが発生
ないのはここだけ
ないのはここだけ
14
7
512ｵｸﾃｯﾄ以下が基本だが．．．
„
AAAAでTCPへのfallbackが増加へ
現在のAAAAのQuery比率⇒約2%
„
EDNS0も直ぐには対応できない
„
ｾｷｭﾘﾃｨ面、性能面でもTCPは開けたくない
„
そもそもAuthoritative Server依存の対策は辛い
2004/12/03
15
Cache Serverの自律的な回避
„
Cache Serverが自分で身を守る(実装変更)
… TCﾋﾞｯﾄが立ったﾊﾟｹｯﾄが帰ってきてもTCPに
fallbackしない(RFC違反)
… 一度TCPにfallbackしても応答の無いRRはTTL
の間Cacheし、再帰問合せをせずにServFailを
返す(Internet Draft)
2004/12/03
16
8
Cache Serverのｽｹｰﾗﾋﾞﾘﾃｨ
17
2004/12/03
規制できないQuery数の増加
ﾌﾞﾛｰﾄﾞﾊﾞﾝﾄﾞ化と利用動向の変化
„ 慢性的に存在するｳｨﾙｽ、ﾜｰﾑの影響
„
Query数
Netsky
ｸｴﾘｰ数(主にMX)
の絶対量を大幅
に底上げ現在も
そのまま
11月 12月 1月 2月 3月 4月 5月
2004/12/03
18
9
Cache Serverの負荷分散
Pri
Sec
Cache
Cache
ﾕｰｻﾞ
„
地域毎、ｻｰﾋﾞｽ毎に利用す
るCacheを分散し、Primary
とSecondaryで運用
„
分散数を増やし、Cache1台
当たりのqpsは低めで運用
„
qpsが上がり負荷が厳しくな
れば、再分散 or 設備更改
2004/12/03
19
Pri/Secでの構成の限界
„
Cache1台あたりは数千qps程度。
⇒ｽｹｰﾙしない。
„
ﾕｰｻﾞが設定するのはPriとSecの2つ
⇒PrimaryとSecondaryの切り替えが遅い
„
高信頼性&大容量のCacheｻｰﾊﾞが有効
2004/12/03
20
10
負荷分散装置＆複数台Cache
Pri
Sec
LB
LB
ﾕｰｻﾞ
„
負荷分散装置をﾌﾛﾝﾄ、
裏側に複数のCache配
置でQueryを分散
„
ﾕｰｻﾞは負荷分散装置の
VIPを利用
„
Cache故障時は負荷分
散装置が自動切り離し
21
2004/12/03
Cacheの台数の最適値？
1.4
„
闇雲に台数を増や
せばｷｬｯｼｭが有効
に機能しない
„
実際のﾄﾗﾌｨｯｸを分
析すると10台程度
までが最適台数
1.2
20
1
15
0.8
10
キャッシュミス率
一台あたりの負荷
5
0.6
0.4
0.2
0
0
0
10 20 30 40 50 60 70 80 90 100
負荷分散サーバ台数
2004/12/03
1台 あ た り の 負 荷
キ ャ ッ シ ュ ミ ス 率 (%)
25
(注)OCNの実ﾄﾗﾌｨｯｸの場合
22
11
まとめ
„
Authoritative Serverが注目されがちだが、
Cache Serverも非常に大切
„
Cache Serverは自分で自分の身を守る
„
Queryの中身にも敏感に
2004/12/03
23
12