この記事は、 「ネットワーク上級編｜要件定義・設計・クラウド・自動化へ進む」 の第39回です。
第4章では、クラウドネットワークを構成するVPC・VNet、ルートテーブル、 ロードバランサー、NAT Gateway、VPN、専用線、複数クラウド接続などを学んできました。 今回は通信開始時の重要な入口となるクラウドDNSの設計を扱います。
クラウドDNSの設計｜Public・Private DNSとハイブリッド名前解決を理解する
クラウドDNSの設計では、DNSレコードを登録するだけでは不十分です。 「誰が・どこから・どの名前を解決するのか」を整理し、 Public DNS、Private DNS、オンプレミスDNS、DNS Resolverを組み合わせて 名前解決経路を設計する必要があります。
クラウド上のWebサーバーやデータベースが正常に稼働していても、 DNSによる名前解決ができなければ利用者からは 「システムへ接続できない」という障害に見えます。
クラウドDNSは単なる名前解決機能ではなく、 クラウド・オンプレミス・インターネットをつなぐ ネットワーク設計の一部として考える必要があります。
この記事を読み終えるとできること
- Public DNSとPrivate DNSを使い分けられる
- クラウドDNSの名前解決経路を説明できる
- Split Horizon DNSの考え方を理解できる
- オンプレミスとクラウドのDNS連携を設計できる
- DNSフォワーディングの方向を整理できる
- TTLを設計する理由を説明できる
- DNS障害時の確認ポイントを整理できる
- DNS設計内容を設計書へ落とし込める
クラウドDNSとは
クラウドDNS設計とは、クラウド上で利用する名前について、 誰が・どこから・どのDNSを使って名前解決するのかを決めることです。
アプリケーションへ接続するとき、利用者がサーバーのIPアドレスを 直接入力することはほとんどありません。
通常は次のようなDNS名を利用します。
www.example.comapi.example.comapp.internal.example.comdb.internal.example.com
DNSがこれらの名前をIPアドレスなどへ変換することで、 クライアントは接続先を特定できます。
ルーティングやファイアウォールが正しくても、 DNS名前解決に失敗すればアプリケーションへ接続できません。
そのためクラウドDNSは、サーバー担当だけではなく ネットワーク設計者も理解しておく必要があります。
クラウドDNSの全体像
企業のクラウド環境では、インターネット向けDNSと 内部向けDNSを分ける構成が一般的です。
Public DNSとPrivate DNSを分離した基本構成
社内利用者からPrivate DNSを利用する構成
DNS設計の最初の質問は 「誰が、どの名前を、どこから名前解決するのか」です。
Public DNSとPrivate DNS
Public DNS
インターネット上から名前解決するためのDNSです。
- 公開Webサイト
- 公開API
- 外部向けロードバランサー
- メールサービス
- VPN接続先
Private DNS
社内やクラウド内部など、限定した範囲で名前解決するDNSです。
- 内部アプリケーション
- データベース
- 監視サーバー
- 管理サーバー
- 内部API
| DNS名 | 利用者 | 設計例 |
|---|---|---|
| www.example.com | インターネット利用者 | Public DNS |
| api.example.com | 外部サービス | Public DNS |
| app.internal.example.com | 社員・内部サーバー | Private DNS |
| db.internal.example.com | アプリケーションサーバー | Private DNS |
PublicとPrivateの判断では、 「インターネットから名前解決する必要があるか」 を最初に確認します。
Split Horizon DNSとは
Split Horizon DNSとは、同じDNS名でも 問い合わせ元によって異なる応答を返す考え方です。
たとえば、
app.example.com
という同じ名前を使用しながら、 外部利用者と内部利用者で異なる接続先を返します。
Split Horizon DNSのイメージ
同じ名前を使いながら、内部通信ではPrivate IP、 外部通信ではPublic側の接続先を使用するといった設計ができます。
オンプレミスとクラウドのDNSを連携する
クラウドDNS設計で難しくなるのが、 オンプレミスとクラウドを組み合わせたハイブリッド環境です。
たとえばオンプレミスでは、
corp.example.com
を管理し、クラウドでは、
cloud.example.com
を管理するとします。
このとき社内PCから
app.cloud.example.com
を利用するなら、社内DNSからクラウドDNSへ問い合わせを送る仕組みが必要です。
逆にクラウド上のサーバーから
fileserver.corp.example.com
を利用するなら、クラウドからオンプレミスDNSへ問い合わせる仕組みが必要です。
ハイブリッドDNSの全体像
DNSフォワーディングを設計する
DNSフォワーディングとは、 特定の名前空間に対する問い合わせを別のDNSへ転送する仕組みです。
オンプレミスからクラウドへ
クラウドからオンプレミスへ
条件付きフォワーディング
すべてのDNS問い合わせを同じDNSへ送る必要はありません。
名前空間ごとに問い合わせ先を決めることで、 必要なDNSだけを適切な場所へ転送します。
| 対象ドメイン | 問い合わせ元 | 転送先 |
|---|---|---|
| corp.example.com | Cloud | On-Premises DNS |
| cloud.example.com | On-Premises | Cloud DNS Resolver |
| その他 | 各クライアント | 通常のDNS名前解決 |
DNSループを防ぐ
ハイブリッドDNSでは、フォワーディング先を誤ると DNS問い合わせが双方を行き来する構成になることがあります。
DNSフォワーディングを設計するときは、 各名前空間について「最終的にどのDNSが管理するか」を明確にします。
| 名前空間 | 管理主体 |
|---|---|
| example.com | Public DNS |
| corp.example.com | On-Premises DNS |
| cloud.example.com | Cloud Private DNS |
複数VPC・VNet・アカウント環境のDNS
大規模なクラウド環境では、 1つのVPCや1つのアカウントだけで構成されるとは限りません。
各ネットワークに独立したDNSを作ると、 次のような問題が発生する可能性があります。
- 同じDNSレコードを複数箇所で管理する
- 名前空間が重複する
- 設定差分が発生する
- 障害調査時の確認場所が増える
- DNS管理権限が分散する
そのため、環境によってはDNS Resolverなどを 共通ネットワークサービスとして集約します。
DNSを共通サービス化するイメージ
ただし、すべてを中央集約するのが正解とは限りません。 障害影響範囲、組織分離、運用権限などを考えて設計します。
TTLを設計する
DNSレコードにはTTL（Time To Live）があります。
TTLは、DNS Resolverなどが回答結果を どれくらいの時間キャッシュできるかを示す値です。
TTLを短くする
メリット
- DNS変更を比較的早く反映できる
- 切り替え作業を行いやすい
注意点
- DNS問い合わせ回数が増える
- キャッシュ効果が小さくなる
TTLを長くする
メリット
- DNS問い合わせを減らせる
- キャッシュを有効活用できる
注意点
- DNS変更の反映に時間がかかる
- 移行時に旧情報が残りやすい
移行前にTTLを下げる
移行直前にTTLを変更しても、 すでにキャッシュされている旧TTLにはすぐ反映されない点に注意します。
DNSの可用性を考える
DNSは多くの通信の入口です。
アプリケーションサーバーが正常でも、 DNS名前解決に失敗すれば利用者からはサービス停止に見えます。
DNS障害の原因として、たとえば次のものがあります。
- DNSレコードの誤削除
- DNSゾーンの設定ミス
- Resolverの設定ミス
- フォワーディングルールの設定ミス
- VPN・専用線障害
- ルーティング障害
- FirewallによるDNS通信遮断
- 権限設定ミス
マネージドDNSを使っているから障害を考えなくてよい、 というわけではありません。
サービス基盤自体の可用性と、 自分たちが設計・設定するDNS構成の可用性を分けて考えます。
DNSとネットワーク経路はセットで設計する
オンプレミスDNSからクラウドDNS Resolverへ問い合わせる構成では、 DNS設定だけでは通信できません。
DNS問い合わせが通る実際のネットワーク経路
DNS連携を設計するときは、少なくとも次を確認します。
- DNS ResolverのIPアドレス
- オンプレミスからResolverへのルーティング
- 戻り経路
- VPNまたは専用線の接続状態
- Firewallの許可設定
- UDP/TCP 53番ポートの到達性
DNS障害に見えても、 実際にはVPN・専用線・ルーティング・Firewallが原因の場合があります。
DNSのセキュリティ設計
内部DNSを不要に公開しない
内部サーバー名やPrivate IPアドレスを Public DNSへ不用意に登録しないようにします。
DNS変更権限を制限する
DNSレコードを変更できるユーザー・ロールを 必要最小限にします。
変更ログを残す
誰が・いつ・どのDNS設定を変更したのか 追跡できるようにします。
DNS問い合わせログを検討する
障害調査や異常通信調査のため、 DNS Query Logを利用できる構成を検討します。
DNSの監視・ログ設計
DNS監視では、単にDNSサービスが起動しているかだけでなく、 名前解決が実際に成功しているかを見る必要があります。
| 監視項目 | 確認目的 |
|---|---|
| DNS問い合わせ成功 | 名前解決が正常か |
| SERVFAIL | Resolverや転送先の異常を確認 |
| NXDOMAIN | 存在しない名前への問い合わせを確認 |
| Query数 | 異常増加や障害兆候を確認 |
| Resolver Endpoint | ハイブリッドDNSの状態確認 |
| DNS設定変更 | 誤変更・不正変更の検知 |
| VPN・専用線 | オンプレミスとのDNS経路確認 |
DNS設計書に残す内容
DNS設計書では、DNSレコードだけではなく 「どこから名前解決できるのか」まで記載します。
| 項目 | 設計例 |
|---|---|
| DNS Zone | cloud.example.com |
| 種別 | Private |
| 管理場所 | Cloud DNS |
| 利用ネットワーク | Production VPC |
| Record | app.cloud.example.com |
| Type | A |
| Value | 10.10.10.20 |
| TTL | 300秒 |
| 利用者 | Cloud VM・社内PC |
| On-Premisesからの利用 | あり |
| Forwarding | On-Premises → Cloud |
| 変更担当 | Network Team |
| 監視 | DNS Query Log |
DNS設計で確認するヒアリング項目
名前空間
- 現在使用しているドメインは何か
- PublicとPrivateでどの名前を利用するか
- オンプレミスDNSのゾーン構成はどうなっているか
- 既存システムと名前空間が重複しないか
利用場所
- インターネットから名前解決するか
- クラウド内部だけで利用するか
- オンプレミスから利用するか
- 別VPC・VNet・アカウントから利用するか
ハイブリッド接続
- オンプレミスDNSからクラウド名を解決するか
- クラウドからオンプレミス名を解決するか
- VPNまたは専用線が利用できるか
- DNS Resolverまで通信可能か
運用
- 誰がDNSレコードを管理するか
- 変更申請・承認フローはあるか
- ログをどれくらい保存するか
- 障害発生時の担当部署はどこか
移行
- 既存DNSから移行するか
- DNS切り替え日時はいつか
- TTLを事前変更する必要があるか
- 切り戻し条件は何か
DNSサービス名から設計を始めるのではなく、 「何を名前解決する必要があるのか」から設計を始めます。
クラウドDNS設計でよくある失敗
内部向けサーバー名をPublic DNSへ登録すると、 本来公開する必要がない情報まで外部から参照できる可能性があります。
オンプレミスからPrivate DNSを利用するには、 DNS Resolver、フォワーディング、VPN・専用線、 ルーティングなども含めて設計する必要があります。
どちらのDNS情報が正しいのか分からなくなるため、 名前空間ごとの管理主体を明確にします。
各ゾーンの管理主体と最終的な問い合わせ先を明確にします。
古いTTLでキャッシュ済みの情報が残っている可能性があるため、 TTL変更は移行計画へ事前に組み込みます。
DNS Resolverへの通信が届かなければ名前解決できません。 VPN・専用線・ルーティング・Firewallまで確認します。
DNS Zone、Resolver、Forwarding、ルーティング、 セキュリティ、TTL、監視まで一連の仕組みとして設計します。
クラウドDNS設計の判断順序
クラウドDNSを設計するときは、 次の順番で整理すると判断しやすくなります。
- 名前を整理する どのドメイン・サブドメインを使用するのか確認します。
- 利用者を整理する インターネット利用者、社員、サーバーなど誰が利用するのか確認します。
- 問い合わせ元を整理する インターネット、オンプレミス、クラウド、別アカウントなどを確認します。
- PublicかPrivateか決める 名前解決を公開する範囲を決めます。
- DNSの管理主体を決める 各名前空間をどのDNSが管理するのか明確にします。
- 他環境との連携を確認する オンプレミスや他VPC・VNetから名前解決する必要があるか確認します。
- フォワーディング方向を決める どの名前空間をどのDNSへ転送するか決めます。
- ネットワーク経路を確認する VPN、専用線、ルーティング、Firewallを確認します。
- TTL・監視・運用を決める 移行、ログ、変更権限、障害対応まで含めます。
DNSサービスを選ぶことが設計のスタートではありません。
名前解決要件を整理したあとで、 その要件を満たす構成を選択します。
顧客・上司への説明方法
設計レビューで、
「Private DNS ZoneとResolverを作ります」
だけでは、なぜ必要なのかが伝わりません。
次のように、技術と目的をセットで説明します。
社内システムのサーバー名はインターネットから名前解決できないよう、 Private DNSで管理します。
また、社内PCからクラウド上のサーバー名を利用できるように、 オンプレミスDNSとクラウドDNS Resolverを連携します。
これにより、利用者はIPアドレスを直接意識せず、 既存の社内DNSと同じようにクラウドシステムへアクセスできます。
設計レビューではさらに、
「Public DNS、Private DNS、オンプレミスDNSの役割を分離し、 各名前空間の管理主体と問い合わせ経路を明確にしています」
と説明できると、設計意図が伝わりやすくなります。
クラウドDNSで使われる英語表現
| 英語 | 意味 |
|---|---|
| Public DNS Zone | 公開DNSゾーン |
| Private DNS Zone | プライベートDNSゾーン |
| DNS Resolver | DNS名前解決を行う機能 |
| Inbound Endpoint | 外部からDNS問い合わせを受ける入口 |
| Outbound Endpoint | 外部DNSへ問い合わせる出口 |
| Forwarding Rule | DNS転送ルール |
| Conditional Forwarding | 条件付きDNS転送 |
| Authoritative DNS | 権威DNS |
| Recursive Resolver | 再帰問い合わせを行うResolver |
| Split Horizon DNS | 問い合わせ元によって異なる回答を返す構成 |
| Name Resolution | 名前解決 |
| DNS Query | DNS問い合わせ |
| DNS Response | DNS応答 |
| TTL | DNSキャッシュの有効時間 |
英語資料を調べるときの検索キーワード
hybrid DNS resolutionprivate DNS zoneDNS conditional forwardingon-premises cloud DNS resolutionDNS resolver inbound outboundsplit horizon DNS
理解度チェック
ここまでの内容を確認します。 解答を見る前に、自分で理由まで考えてください。
問題1．インターネットへ公開するWebサイトのDNSとして 適切なのはどれですか。
- Private DNSのみ
- Public DNS
- DHCP
- NAT Gateway
解答を見る
インターネット上の利用者から名前解決させるため、 Public DNSを使用します。
問題2．クラウド内部だけで使用するデータベース名の管理に 適したDNSはどれですか。
- Public DNS
- Private DNS
- インターネットDNSのみ
- DNSは使用しない
解答を見る
内部システムはPrivate DNSで管理することで、 名前解決可能な範囲を限定できます。
問題3．オンプレミスからクラウドのPrivate DNS名を 名前解決する場合に確認する項目を3つ以上挙げてください。
解答例を見る
- DNS Resolver
- DNS Forwarding
- VPN・専用線
- ルーティング
- Firewall
- DNSポートの到達性
問題4．Split Horizon DNSとは何ですか。
解答を見る
同じDNS名に対して、 問い合わせ元のネットワークなどに応じて 異なるDNS応答を返す構成です。
問題5．DNS切り替え前にTTLを確認する理由を説明してください。
解答を見る
Resolverなどへ旧DNS情報がキャッシュされるためです。 TTLが長い場合、DNSレコードを変更しても旧情報が一定時間利用される 可能性があります。
実践演習：ハイブリッドクラウドのDNSを設計する
次の企業ネットワークを想定して、 DNS設計を考えてください。
演習用ネットワーク
要件
www.example.comはインターネットから利用するapp.cloud.example.comは社内PCとクラウドVMだけから利用する- クラウドVMから
fileserver.corp.example.comを名前解決する - インターネットから内部サーバー名は名前解決させない
課題1．PublicとPrivateを分類する
次の名前を、どのDNSで管理するか考えてください。
app.cloud.example.com →
fileserver.corp.example.com →
課題1の解答を見る
- www.example.com：Public DNS
- app.cloud.example.com：Cloud Private DNS
- fileserver.corp.example.com：On-Premises DNS
課題2．社内からクラウドへのDNS経路を書く
社内PCから
app.cloud.example.com
を名前解決する経路を書いてください。
課題2の解答を見る
社内PC → On-Premises DNS → 条件付きForwarding → Cloud DNS Resolver → Cloud Private DNS
課題3．クラウドからオンプレミスへのDNS経路を書く
Cloud VMから
fileserver.corp.example.com
を名前解決する経路を書いてください。
課題3の解答を見る
Cloud VM → Cloud DNS Resolver → Outbound Forwarding → VPN → On-Premises DNS
課題4．障害時の確認ポイントを考える
社内PCからクラウド内部の名前だけ解決できなくなりました。 確認すべき項目を5つ以上挙げてください。
2.
3.
4.
5.
課題4の解答例を見る
- Private DNSレコードが存在するか
- DNS Forwarding Ruleが正しいか
- DNS Resolverが正常か
- VPNが正常か
- Resolverまでのルーティングが正しいか
- 戻り経路があるか
- FirewallでDNS通信が許可されているか
- 問い合わせログがResolverまで到達しているか
- 古いDNSキャッシュが残っていないか
自分の言葉で説明する課題
設計レビューで、顧客から次の質問を受けました。
「クラウドにPrivate DNSを作るだけではなく、 なぜDNS Resolverまで必要なのですか？」
説明例を見る
Private DNSはクラウド内部の名前を管理する仕組みですが、 オンプレミスなど別のネットワークから利用する場合は、 DNS問い合わせをクラウド側へ届ける仕組みが必要です。
そのため、DNS Resolverやフォワーディング、 VPN・専用線、ルーティングまで含めて 名前解決経路を設計します。
まとめ
- クラウドDNS設計では、 「誰が・どこから・どの名前を解決するか」を最初に整理する
- インターネット向けの名前にはPublic DNSを使用する
- 内部システムにはPrivate DNSを使用する
- 同じ名前を内部・外部で使い分ける場合は Split Horizon DNSを検討する
- ハイブリッド環境ではDNS Resolverと DNSフォワーディングを設計する
- DNSだけでなくVPN・専用線・ルーティング・Firewallまで確認する
- 名前空間ごとに管理主体を明確にしてDNSループを防ぐ
- 移行時はTTLとDNSキャッシュを考慮する
- DNS変更権限、ログ、監視も設計対象に含める
- 複数VPC・VNet・アカウントではDNSの共通化も検討する
「DNSレコードを登録できる」だけでは設計とは言えません。 名前空間、利用者、問い合わせ経路、ネットワーク経路、 可用性、運用まで説明できる状態を目指しましょう。
コメント