はじめに
AWSでManaged Microsoft ADを利用している環境では、DNSの名前解決が少し複雑になります。
特に、以下のサービスや機能が組み合わさると、DNSの経路が分かりづらくなります。
- AWS Managed Microsoft AD
- DHCPオプションセット
- Route 53 VPC Resolver
- Route 53 Private Hosted Zone
- Conditional Forwarder
- Route 53 Resolver Rule
この記事では、これらの関係を整理しながら、
EC2やECSなどからDNS問い合わせをすると、どのような経路で名前解決されるのか？
を説明します。
また、DNS障害が発生した場合に、どこから確認すればよいのかについても整理します。
この記事の前提
この記事では、以下のようなAWS環境を想定します。
| 項目 | 内容 |
|---|---|
| DNS | AWS Managed Microsoft AD |
| VPC CIDR | 10.123.0.0/16 |
| AD DNS |
10.123.30.1 / 10.123.40.1
|
| DNS Resolver | Route 53 VPC Resolver |
| クライアント | EC2 / ECSなど |
| Private DNS | Route 53 Private Hosted Zone |
※IPアドレスは説明用のサンプルです。
1. まず全体像を理解する
まず、DNS問い合わせの全体像を確認します。
今回想定する構成では、概念的には以下のようになります。
VPC
|
DHCPオプションセット
|
| DNSサーバー情報
v
+-------------+
| EC2 / ECS |
+------+------+
|
| DNS Query
v
+-----------------------+
| Managed Microsoft AD |
| DNS / DC |
+-----------+-----------+
|
| DNS転送
v
+-----------------------+
| Route 53 VPC Resolver |
+-----------+-----------+
|
+----+----+
| |
v v
Private Hosted Public
Zone DNS
ただし、すべてのDNS問い合わせが必ずこの経路を通るわけではありません。
DNSサーバーの設定やDNS転送の設定によって、実際の経路は変わります。
そのため、まずは「クライアントがどのDNSサーバーを利用するのか？」から見ていきます。
1-1. DHCPオプションセットとは
AWS VPCには、DHCPオプションセットという仕組みがあります。
DHCPオプションセットでは、VPC内のリソースに対して、以下のようなネットワーク情報を提供できます。
- DNSサーバー
- ドメイン名
- NTPサーバー
- NetBIOS関連の設定
今回特に重要なのが、
domain-name-servers
です。
ここで、クライアントが利用するDNSサーバーを指定できます。
つまり、DHCPオプションセットは、
「DNS問い合わせを処理する仕組み」ではなく、「クライアントが利用するDNSサーバーを指定する仕組み」
と考えると分かりやすいです。
1-2. デフォルトのDNS設定
特にカスタムDHCPオプションセットを設定していないVPCでは、デフォルトのDHCPオプションセットが利用されます。
DNSサーバーには、
AmazonProvidedDNS
が指定されます。
AmazonProvidedDNSは、VPC内で提供されるDNSリゾルバーです。
IPv4では、以下のアドレスから利用できます。
169.254.169.253
また、VPC CIDRのネットワークアドレスに +2 したアドレスも利用できます。
例えば、
VPC CIDR
10.123.0.0/16
の場合、
10.123.0.2
が該当します。
このDNSリゾルバーが、現在AWSで「Route 53 VPC Resolver」と呼ばれているものです。
1-3. Managed Microsoft ADを利用する場合
AWS Managed Microsoft ADでは、AWSが管理するドメインコントローラーが用意されます。
ドメインコントローラーにはDNS機能も提供されています。
例えば説明用に、
DC1
10.123.30.1
DC2
10.123.40.1
という構成だったとします。
※IPアドレスは説明用です。
Managed Microsoft ADでは、複数のドメインコントローラーが異なるAZに配置される構成になっています。
そのため、クライアントからこれらのドメインコントローラーをDNSサーバーとして利用できます。
1-4. DHCPオプションセットでAD DNSを指定する
ここでDHCPオプションセットを使用します。
例えば、
domain-name-servers:
10.123.30.1
10.123.40.1
というDHCPオプションセットを作成し、VPCに関連付けます。
すると、VPC内のリソースがDHCPによってネットワーク設定を取得する際に、DNSサーバーの情報も取得します。
イメージとしては、
VPC
|
| DHCP
v
DHCPオプションセット
|
| DNS Server
v
10.123.30.1
10.123.40.1
です。
このため、クライアント側では、
DNSサーバー
↓
Managed Microsoft ADのDNS
という構成になります。
1-5. 実際のDNS問い合わせ
例えばEC2から、
nslookup example.com
を実行したとします。
OS側のDNS設定が、
nameserver 10.123.30.1
となっていた場合、
EC2
|
| DNS Query
v
10.123.30.1
|
v
Managed Microsoft AD DNS
という流れになります。
ここで重要なのは、
最初からRoute 53 VPC Resolverに問い合わせているわけではない
ということです。
今回の構成では、まずManaged Microsoft ADのDNSに問い合わせています。
1-6. Managed Microsoft ADのDNSは何をするのか
Managed Microsoft ADのDNSは、Active Directoryに関連する名前解決を行います。
例えば、
dc01.example.local
のようなADドメインに関連する名前を解決します。
また、DNSサーバーとして、必要に応じて他のDNSサーバーへ問い合わせを転送することもできます。
ここで登場するのが Conditional Forwarder です。
1-7. Conditional Forwarderとは
Conditional Forwarderは、
特定のドメインに対するDNS問い合わせを、指定したDNSサーバーへ転送する
ための仕組みです。
例えば、
internal.example.com
への問い合わせを、
10.123.0.2
へ転送するよう設定できます。
すると、
EC2
|
| DNS Query
v
Managed Microsoft AD DNS
|
| Conditional Forwarder
v
10.123.0.2
|
v
Route 53 VPC Resolver
という経路を構成できます。
ただし、重要なのは、
Managed Microsoft ADのDNSが、すべてのDNS問い合わせを自動的にRoute 53 VPC Resolverへ転送するわけではない
ということです。
どこへ転送するかは、DNSの設定によって決まります。
1-8. Route 53 VPC Resolverとは
Route 53 VPC Resolverは、VPC内で利用できるDNSリゾルバーです。
例えば、
10.123.0.2
にDNS問い合わせを送ると、VPC Resolverが問い合わせを処理します。
Route 53 VPC Resolverは、例えば以下の名前解決に関係します。
- VPC内のDNS名
- Route 53 Private Hosted Zone
- パブリックDNS名
1-9. Route 53 Private Hosted Zone
例えばRoute 53に、
internal.example.com
というPrivate Hosted Zoneがあるとします。
その中に、
api.internal.example.com
|
v
10.123.50.10
というレコードが登録されているとします。
VPC Resolverへ問い合わせることで、
api.internal.example.com
を、
10.123.50.10
へ名前解決できます。
イメージとしては、
DNS Query
|
v
Route 53 VPC Resolver
|
v
Private Hosted Zone
|
v
10.123.50.10
です。
1-10. DNS問い合わせの全体像
ここまでを組み合わせると、今回の構成では次のように考えられます。
VPC
|
|
DHCPオプションセット
|
| DNS Server
v
+---------------+
| EC2 / ECS |
+-------+-------+
|
| DNS Query
v
+-------------------+
| Managed Microsoft |
| AD DNS / DC |
+---------+---------+
|
| Conditional Forwarder
v
+-------------------+
| Route 53 VPC |
| Resolver |
+---------+---------+
|
+----+----+
| |
v v
Private Hosted Public
Zone DNS
ここで重要なのは、
DHCPオプションセット
↓
「クライアントが最初に利用するDNSサーバーを決める」
DNS転送
↓
「DNSサーバーが次にどこへ問い合わせるかを決める」
という違いです。
1-11. Resolver Ruleとは
AWSには、もう一つDNS転送の仕組みがあります。
それが Route 53 Resolver Rule です。
Resolver Ruleでは、Route 53 VPC Resolverが受け取ったDNS問い合わせを、指定したDNSサーバーへ転送できます。
例えば、
corp.example.com
への問い合わせを、
10.0.1.10
10.0.2.10
へ転送する、といった構成です。
概念的には、
EC2
|
v
Route 53 VPC Resolver
|
| Resolver Rule
v
指定DNSサーバー
となります。
1-12. Conditional ForwarderとResolver Ruleの違い
Conditional ForwarderとResolver Ruleは、どちらもDNS問い合わせを転送する仕組みです。
ただし、設定する場所と動作する場所が異なります。
| 項目 | Conditional Forwarder | Resolver Rule |
|---|---|---|
| 設定場所 | DNSサーバー側 | Route 53 VPC Resolver |
| 問い合わせを受ける側 | DNSサーバー | VPC Resolver |
| 主な用途 | AD DNSなどから別DNSへ転送 | VPC Resolverから指定DNSへ転送 |
つまり、
Managed Microsoft AD DNS
|
| Conditional Forwarder
v
指定DNS
と、
VPC内のリソース
|
v
Route 53 VPC Resolver
|
| Resolver Rule
v
指定DNS
は別の仕組みです。
2. DNS障害が発生した場合
ここからは、実際の障害対応について考えてみます。
例えば、
「突然、特定のドメインが名前解決できなくなった」
という障害が発生したとします。
この場合、いきなりRoute 53を確認するのではなく、問い合わせ元から順番に確認します。
2-1. まずクライアントのDNS設定を確認する
Linuxであれば、
cat /etc/resolv.conf
などでDNS設定を確認できます。
例えば、
nameserver 10.123.30.1
となっていた場合、
EC2
|
v
10.123.30.1
へDNS問い合わせを送っています。
このIPアドレスがManaged Microsoft ADのドメインコントローラーであれば、
EC2
|
v
Managed Microsoft AD DNS
という経路が最初に存在することになります。
2-2. DHCPオプションセットを確認する
次に、VPCに関連付けられているDHCPオプションセットを確認します。
確認するポイントは、
domain-name
domain-name-servers
です。
例えば、
domain-name-servers:
10.123.30.1
10.123.40.1
となっているかを確認します。
ここが想定と異なっている場合、クライアントが意図しないDNSサーバーを利用している可能性があります。
2-3. Managed Microsoft ADを確認する
次にManaged Microsoft ADを確認します。
確認するポイントは、
- ドメインコントローラーの状態
- DNS設定
- Conditional Forwarder
- DNS転送先
などです。
例えば、
EC2
|
v
DC1
|
X
名前解決失敗
となっていても、
EC2
|
v
DC2
|
v
名前解決成功
なら、DC単位の問題を疑うことができます。
2-4. Route 53 VPC Resolverを確認する
Managed Microsoft ADからRoute 53 VPC ResolverへDNS問い合わせを転送する構成であれば、次にResolver側を確認します。
例えば、
Managed Microsoft AD
|
| DNS Query
v
Route 53 VPC Resolver
の通信が正常に行われているかを確認します。
構成によっては、
- Resolverルール
- Resolverエンドポイント
- セキュリティグループ
- ネットワークACL
- ルートテーブル
- Network Firewall
なども確認対象になります。
2-5. 「Route 53は正常なのにDNSが失敗する」場合
DNS障害でありがちなのが、
「Route 53を確認したけど正常だった」
というケースです。
しかし、
Route 53が正常 = DNS経路全体が正常
とは限りません。
例えば、
EC2
|
X
Managed Microsoft AD
|
v
Route 53 VPC Resolver
のように、Route 53へ到達する前に問題が発生している可能性があります。
逆に、
EC2
|
v
Managed Microsoft AD
|
X
Route 53 VPC Resolver
であれば、AD DNSから先の通信に問題がある可能性があります。
だからこそ、
DNS問い合わせがどこから始まり、どこを経由して、どこで止まったのか
を見ることが重要です。
2-6. DNS障害の切り分け手順
DNS障害が発生した場合は、以下のような順番で確認すると整理しやすくなります。
① 名前解決できない
|
v
② クライアントのDNS設定を確認
|
v
③ DHCPオプションセットを確認
|
v
④ Managed Microsoft ADの状態を確認
|
v
⑤ AD DNSの転送設定を確認
|
v
⑥ Route 53 VPC Resolverを確認
|
v
⑦ Private Hosted Zone / Public DNSを確認
|
v
⑧ ネットワーク経路を確認
特に最初に、
「どのDNSサーバーに問い合わせているのか？」
を確認することが重要です。
3. まとめ
AWS Managed Microsoft ADを利用した環境でDNSを理解するには、以下の関係を押さえておくことが重要です。
DHCPオプションセット
|
v
クライアントが利用するDNSサーバー
|
v
Managed Microsoft AD DNS
|
v
DNS転送
|
v
Route 53 VPC Resolver
|
v
Private Hosted Zone / Public DNS
ただし、これはあくまで一例です。
環境によっては、
EC2
|
v
Route 53 VPC Resolver
|
| Resolver Rule
v
オンプレミスDNS
のような構成もあります。
重要なのは、AWSのDNSサービス名を覚えることではなく、
「このDNS問い合わせは、今どのDNSサーバーが受けていて、次にどこへ転送しているのか？」
という視点で考えることです。
DNS障害が発生した場合も、
クライアント
|
v
DNSサーバー
|
v
転送先
|
v
名前解決先
と経路を分解していけば、切り分けしやすくなります。
参考
- Amazon DNS concepts
- DHCP option sets
- AWS Managed Microsoft AD best practices
- What is Route 53 VPC Resolver?
- How DNS queries are forwarded