コンテンツプロバイダから見た権威 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 等の作り込みを自作でがんばる 売り物のアプライアンスを買うの２択。後者はこの用途であれば 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!