コンテンツプロバイダから見た 権威dnsサーバ
TRANSCRIPT
コンテンツプロバイダから見た権威 DNS サーバ
2016 年 12 月 1 日
株式会社 DMM.com ラボ
高嶋隆一
Internet Week 2016 D3 DNS DAY
Version 12/01
2
権威 DNS サーバの運用における
想定されるユースケース ユースケース毎に用いられる実装 ユースケース毎の注意点
を、コンテンツプロバイダの視点から説明し、議論する事 !
本セッションの目的
3
自己紹介
イマココ →
4
サービス提供用ドメイン名の利用のされ方から考えてみる
5
よくある web サービスのアーキテクチャ
www.example.comの権威 DNS サーバ
=GSLB(*1)
www.example.comの SLB(*2)
www.example.comの実サーバ
セッション振分けセッション振分けセッション振分け
example.comの権威 DNS サーバ
(*1)GSLB=Global Server Load Balancing :クライアントによって返す A/AAAA の内容を変える事により、複数の実サーバを持たせる負荷分散、冗長化の仕組み(*2)SLB=Server Load Balancing : UDP/TCP 等のセッションを複数の実サーバに振分ける負荷分散、冗長化の仕組み
所謂普通の権威 DNS サーバ。GSLB を使うため、このケースでは www の NS を GSLB に移譲
www の負荷分散、冗長を行う為、A/AAAA に複数のレコードを登録障害時に切り外す為、 A/AAAA のTTL が短いのは許して orz
NS 移譲
A/AAAA 振分け
6
名前解決の動き キャッシュ DNS
www.example.comの権威 DNS サーバ
=GSLB
www.example.comの SLB
www.example.comの実サーバ
セッション振分けセッション振分けセッション振分け
www.example.comの IP アドレスは?
1
www.example.comの IP アドレスは?
3
www.example.comの権威 DNS を教える
2
www.example.comの SLB のうち、どれかを A/AAAA として返答
4
example.comの権威 DNS サーバ
7
よくある web サービスのアーキテクチャ
www.example.comの権威 DNS サーバ
=GSLB
www.example.comの SLB
www.example.comの実サーバ
セッション振分けセッション振分けセッション振分け
example.comの権威 DNS サーバ
今回ユースケース紹介対象
8
ユースケースその 1:example.com の権威 DNS サーバ
自社データセンタ
9
example.com の権威 DNS サーバ
よくあった (?) ちょっと昔のケース
ゾーン転送ゾーン情報
キャッシュ DNS
admin
# vi example.com.zone# rndc reload
slavemaster
ns1.example.com
ns2.example.com
ゾーン情報
自社データセンタ
10
example.com の権威 DNS サーバ
ns1.example.com
ゾーン転送ゾーン情報
キャッシュ DNS
admin
# vi example.com.zone# rndc reload
オリジナルデータを持つサーバが直接クエリにも答える為メンテしづらい
基本的には admin(root) がゾーン情報を編集する事になり、権限分割するにはサブドメインを切るしかない
SLB 等の冗長化を未使用の為、 1 台の NS のメンテ、障害がクライアント待ち時間増加に繋がる
オンプレだとDoS/DDoS が怖い
ns2.example.com
ゾーン情報
slavemaster
11
example.com の権威 DNS サーバ
解決しようとするとこんな感じ
shadowmaster
slave
SLB
ゾーン転送
ns1.example.com
ns2.example.com 実サーバが一台落ちてもダウ
ンタイムが無い構成。ある程度の DoS/DDoS も防御
冗長、負荷分散を考慮した複数の実サーバ
クエリに答えるサーバとデータを編集するサーバを分離し、後者は隠蔽
権限分割を可能にする為の仕組みやそれらを容易にするAPI 、や UI を具備
今時のハードウェアアプライアンスならどれでもよいが、 Source IP アドレス毎の TCP/UDPのレートリミットができるとなおよい
複数の実装 ( 例 :BIND9+NSD) にしておく。負荷に応じてスケールアウトできる様な構成にしておくとなおよい
権限分離、 API 、 UI が必要な為、選択肢としては PowerDNS 等の作り込みを自作でがんばる 売り物のアプライアンスを買うの2択。後者はこの用途であれば VM 版でもよいのでコストはある程度抑えられる。
12
example.com の権威 DNS サーバ
実装
shadowmaster
slave
SLB
権威 DNS サーバの機能まるごとをRoute53 、 AzureDNS 、 Akamai Fast DNS 等のサービスを買ってしまうのも手。
自然と DDoS 対策も入ってくる。
ただ、クラウド DNS サービスやクラウドそのものが DDoS/ 不具合等で落ちる事例もあるので、 NS 毎にバラす等の考慮も必要
ゾーン編集機能も、権限分離、 API 、 UI 等豊富に提供されている。
13
example.com の権威 DNS サーバ
今時の (?) 実装
shadowmaster
slave
SLB
14
ユースケースその 2:www.example.com の権威 DNS サーバ =GSLB
自社 DC#A
15
GSLB
昔ながらのケース キャッシュ DNS
ns1-www.example.com ns2-www.example.com
自社 DC#B 自社 DC#C
SLB+ 実サーバ
GSLB
自社 DC#A
16
GSLB
最近は ... キャッシュ DNS
ns1-www.example.com ns2-www.example.com
自社 DC#B
SLB+ 実サーバ
GSLB
クラウド #A
17
GSLB
最近は ... キャッシュ DNS
ns1-www.example.com ns2-www.example.com
SLB+ 実サーバ
GSLB
クラウド #A
18
GSLB
こういうのもなくはないです。 キャッシュ DNS
ns1-www.example.com ns2-www.example.com
自社 DC#B 自社 DC#C
SLB+ 実サーバ
GSLB
昔ながらのハードウェアプライアンス LB を利用した形。最近はベアメタル版や VM 版もある為、スペックが絞れればリーズナブルにもなる。
gdnsd は DNS 負荷分散、ヘルスチェックを含めた実装として最近 hot 。一般的な権威 DNS サーバとヘルスチェックを自己実装して連携してできなくもない。
Amazon Route53 、 Akamai Global Traffic Management 、 Azure Traffic Manager 等、各社出揃ってきている。Web フロントをクラウドや CDN で使う場合には連携が強力でステキ。
19
GSLB 実装
実装
クラウドサービス
LB アプライアンス
オープンソース
20
Thank you!