【DNS入門 第10回】クラウド・社内環境のDNS ― Route 53、ハイブリッド名前解決、AD統合DNS、Kubernetes

DNS サーバー
スポンサーリンク
スポンサーリンク

「EC2からオンプレのサーバーの名前が引けません」
「Kubernetesに載せたら、外部APIの呼び出しが遅くなりました」

クラウドやコンテナの環境では、DNSの部品が見えにくいところに組み込まれています。仕組みを知らないと、どこで名前が解決されているのかさえ分からず、切り分けに時間がかかります。

でも、安心してください。部品の名前が変わっても、中身は第3回までに見た「キャッシュDNS・権威DNS・条件付きフォワーディング」そのものです。第10回では、Route 53を中心としたAWSのDNS、オンプレとのハイブリッド名前解決、Azureとの対応、そしてAD統合DNS、Kubernetes、vSphereでのDNSを見ていきます。

Route 53の全体像とホストゾーン

Route 53はAWSのDNSサービスで、3つの役割を持ちます。

Route 53が、インターネットに公開するパブリックホストゾーン、VPCに関連付けるプライベートホストゾーン、ドメイン登録（レジストラー）、VPC Resolverという役割の違う機能を持つことを示す図
  1. ホストゾーン：権威DNSサーバー
  2. ドメイン名の登録：レジストラー
  3. VPC Resolver：VPCの中で使うフルサービスリゾルバー

ホストゾーンには2種類あります。

  • パブリックホストゾーン：インターネットに公開するゾーン。作成すると4台のネームサーバー（awsdnsのcom・net・org・co.uk）が割り当てられる。レジストラーでこの4台をNSとして登録して、初めて委任が完成する（第2回）
  • プライベートホストゾーン：関連付けたVPCの中からだけ引けるゾーン

同じ名前のパブリックとプライベートを作ると、VPCの内と外で違う答えを返すスプリットホライズン（第7回）になります。1つのサービスに、役割の違う3つのDNSの機能が入っている、と整理しておくと混乱しません。

エイリアス・ルーティングポリシー・ヘルスチェック

機能DNSとしての動き注意点
エイリアスレコードRoute 53の中で参照先を解決し、A/AAAAとして答えるゾーン頂点でも使える。Route 53独自の機能で、ゾーン転送や他社DNSでは再現できない
エイリアスのTTL参照先のTTLが使われる（ELBを指す場合は60秒で固定）自分でTTLを決められない。AWSリソースへのエイリアスは問い合わせ料金がかからない
加重（Weighted）重みの比率で答えを変える答えはキャッシュされるため、実際の比率は目安にとどまる
レイテンシー・地理的位置・IPベース問い合わせ元（キャッシュDNSのIP、ECS対応ならクライアントのサブネット）で答えを変える社内のフォワーダー経由だと、その出口の場所で判定される
フェイルオーバー＋ヘルスチェック正常なら主系、異常なら待機系の答えを返す切り替わるのはTTLが切れてから。プライベートホストゾーンではチェッカーがVPCの外にいるため、CloudWatchアラームを使う型にする
複数値回答（Multivalue）正常なレコードを最大8件、ランダムに返すロードバランサーの代わりにはならない
エイリアスレコードでキャッシュDNSのA問い合わせにRoute 53がALBのアドレスを返すことと、フェイルオーバーではヘルスチェックで主系（東京）の異常を検知して待機系（大阪）の答えに変えるが、キャッシュDNSはTTLが切れるまで古い答えを使うことを示す図

ここで押さえたいのは、どれも「権威DNSが返す答えを変える」仕組みだという点です。すでに答えを持っているキャッシュDNSや端末には、TTLが切れるまで効きません（第3回）。答えを変えるのはRoute 53、古い答えを覚えているのはキャッシュDNSです。

また、レイテンシーや地理的位置のルーティングは「問い合わせ元」で判定するので、社内のフォワーダー経由だと、その出口の場所で判定される点にも注意しましょう。大阪の社員でも、東京のDMZから問い合わせていれば「東京」と判定されます。

VPCのDNS（Route 53 VPC Resolver）

VPCのEC2は、DHCPオプションセットのAmazonProvidedDNSにより、AWSのフルサービスリゾルバーRoute 53 VPC Resolver（2025年にRoute 53 Resolverから改称）を使います。宛先はCIDRの先頭＋2（10.0.0.0/16なら10.0.0.2）か169.254.169.253です。

VPC（10.0.0.0/16）のEC2がVPC Resolverに問い合わせ、転送ルールに一致すればアウトバウンドエンドポイントから転送、プライベートホストゾーンに一致すればゾーンから答え、どれにも一致しなければインターネットへ再帰問い合わせすることと、判定は最も具体的に一致したものを使うことを示す図
  • VPCの属性enableDnsSupportとenableDnsHostnamesの両方を有効にしないと、プライベートホストゾーンが使えない
  • 名前に最も具体的に一致する転送ルールかプライベートホストゾーンが使われ、同じ名前なら転送ルールが優先
  • 一致したゾーンに無い名前は、インターネットに聞かずNXDOMAINになる
  • ENIごとに毎秒1024パケットの上限がある

3つ目は、はまりやすいポイントです。たとえばexample.jpのプライベートホストゾーンを作ると、そこに登録していないwww.example.jpは、インターネットに公開されていてもNXDOMAINになります。

Resolverエンドポイントと転送ルール

オンプレとVPCの間で名前を引き合うための部品です。

部品向き役割設計の注意
インバウンドエンドポイントオンプレ → VPCオンプレのDNSが条件付きフォワーダーで転送する先。VPC Resolverと同じ答え（プライベートホストゾーンを含む）を返す2つ以上のAZにIPを置く。セキュリティグループでTCP/UDP 53を許可
アウトバウンドエンドポイントVPC → オンプレ転送ルールに一致した問い合わせを、オンプレのDNSへ送り出すオンプレ側で送信元（エンドポイントのIP）からの問い合わせを許可
転送ルール（FORWARD）VPC → オンプレcorp.example.jp などを指定のDNSへ転送する。VPCに関連付けて効く転送先はオンプレのDNSを2台以上登録
システムルール（SYSTEM）—転送ルールの例外として、特定の名前をVPC Resolverで解決させる例：. をすべてオンプレへ転送しつつ amazonaws.com は例外にする
委任ルール（DELEGATE）双方向条件付きフォワーダーの代わりに、NSレコードの委任でオンプレとつなぐ（2025年〜）条件付きフォワーダーを設定しにくいDNS製品向け
共有—AWS RAMでルールを他アカウントへ共有。Route 53 Profilesでゾーン・ルール・DNS Firewallをまとめて配るエンドポイントは中央のアカウントに集約できる
オンプレミスの社内DNSとVPN/DXでつながった中央アカウントのVPCに、インバウンド・アウトバウンドのエンドポイントをAZごとに置き、転送ルールとシステムルールをAWS RAMで他アカウントへ共有する構成を示す図

エンドポイントのIP 1つで、UDPの問い合わせを毎秒最大1万件ほど処理できます（応答の大きさや転送先の遅さで下がります）。料金はIPの数と問い合わせ数で決まります。

新しい部品に見えますが、転送ルールの考え方は、第3回の条件付きフォワーディングそのものです。

クエリーログ・DNS Firewall・Global Resolver

VPCのEC2からの問い合わせをDNS FirewallがALLOW・ALERT・BLOCKで判定し、クエリーログをCloudWatch Logs・S3・Firehoseへ送ることと、オンプレや在宅の端末からエニーキャストで使えるGlobal Resolverを示す図
  • クエリーログ：VPCからVPC Resolverへの問い合わせ、エンドポイントを通る問い合わせ、DNS Firewallの判定を記録する。送り先はCloudWatch Logs・S3・Firehose。「どのインスタンスが、いつ、何を引いたか」が、障害調査とセキュリティ調査の手がかりになる。ただし、端末やOSのキャッシュで答えた問い合わせと、1024ppsの上限で捨てられた問い合わせはログに残らない
  • DNS Firewall：VPCから出ていく問い合わせを、ドメインリストで許可（ALLOW）・遮断（BLOCK）・警告（ALERT）する。遮断したときはNODATA・NXDOMAIN・OVERRIDE（CNAMEで差し替え）のどれで答えるかを選べる。AWSが管理するドメインリスト（マルウェアなど）と、DNS Firewall Advanced（DNSトンネリングやDGAの検知）がある。第9回の保護的DNS・RPZのクラウド版
  • Route 53 Global Resolver（2026年3月に一般提供）：オンプレや在宅の端末から、エニーキャストでプライベートホストゾーンとインターネットの名前を引けるリゾルバー。フィルタリングとログも一か所にまとめられる

DNS Firewallは名前だけで判定します。IPアドレスを直接指定した通信や、DoHで外部へ出る通信は止められません。最初はALERTで影響を確かめてからBLOCKにしましょう。

オンプレとのハイブリッド名前解決

では、冒頭の「EC2からオンプレの名前が引けない」を、どう設計すればよいのでしょうか。オンプレとAWSの間では、両方向の条件付きフォワーダーで名前を引き合います。

オンプレの端末がapp.aws.corp.example.jpを引くと社内DNSがインバウンドエンドポイントへ転送してプライベートホストゾーンの答えが返り、EC2がdc01.corp.example.jpを引くと転送ルールでアウトバウンドエンドポイントからオンプレのDNSへ転送されることを示す図
  • オンプレ → AWS：オンプレの端末がapp.aws.corp.example.jpを引くと、社内のDNSはVPNやDirect Connect越しにインバウンドエンドポイントへ転送し、プライベートホストゾーンの答えが返る
  • AWS → オンプレ：EC2がdc01.corp.example.jpを引くと、転送ルールに従い、アウトバウンドエンドポイントからオンプレのDNSへ転送される

行きは②インバウンド、帰りは⑥アウトバウンドです。設計の要点は3つです。

  1. AWS側をaws.corp.example.jpのようなサブドメインに分け、転送の条件を単純にする
  2. 転送が同じVPCとオンプレを行き来するループを作らない
  3. AZ・DNSサーバー・回線を2つ以上にする

Azureとの対応

Azureでも、名前は違っても部品の役割は1対1で対応しています。

役割AWSAzure違い・注意
公開ゾーン（権威DNS）Route 53 パブリックホストゾーンAzure DNS（Public DNS）どちらもゾーン頂点で自社のリソースを指すエイリアスがある
内部ゾーンプライベートホストゾーン（VPC に関連付け）Private DNS ゾーン（仮想ネットワークリンク）Azure には VM の名前の自動登録がある
VPC／VNet 内のリゾルバーVPC Resolver（CIDR＋2、169.254.169.253）Azure 提供の DNS（168.63.129.16）どちらもオンプレから直接は届かない
オンプレ → クラウドインバウンドエンドポイントDNS Private Resolver のインバウンドエンドポイントオンプレで 168.63.129.16 を転送先にしても届かない
クラウド → オンプレアウトバウンドエンドポイント＋転送ルールアウトバウンドエンドポイント＋DNS 転送ルールセットルールセットは VNet にリンクして初めて効く
フィルタリングとログDNS Firewall、クエリーログDNS リゾルバーポリシー（許可・遮断・警告、脅威インテリジェンス）どちらも名前で判定する
DNS による振り分けルーティングポリシー＋ヘルスチェックTraffic ManagerAzure DNS のゾーン自体には振り分けの機能がない
AWSとAzureのDNSの部品（インバウンドエンドポイント、VPC/VNet内のリゾルバー、プライベートゾーン、アウトバウンドと転送ルール、パブリックゾーン、フィルタリング）が役割ごとに1対1で対応することを示す図

Azureで多い障害は、プライベートエンドポイント用のprivatelink.*ゾーンを、オンプレのDNSから条件付き転送し忘れ、公開IPが返ってしまうものです。AWSのVPCエンドポイントでも同じことが起きます。「クラウドのストレージに、社内からだけインターネット経由でつながってしまう」ときは、まずここを疑いましょう。

AD統合DNS

社内環境の代表、Active DirectoryのDNSです。

  • AD統合ゾーン：ゾーンのデータをADのデータベースに置き、ADのレプリケーションでDCに複製する。どのDCでも書き込めるマルチマスターで、第7回のプライマリ／セカンダリとゾーン転送とは仕組みが違う
  • SRVレコード：DCのNetlogonが_ldap._tcp.dc._msdcs.<ドメイン>などを自動で登録し、クライアントはSRVでDCを探す（第6回）
  • _msdcsゾーン：_msdcs.<フォレストルート>はフォレスト全体に複製される。子ドメインや別のDNSからDCを探すときにここが引けないと、ドメイン参加や認証が失敗する
  • 動的更新：端末が自分のA・PTRを登録する。「セキュリティで保護された動的更新のみ」にすると、登録したコンピューターだけが自分のレコードを書き換えられる
  • DCのDNS設定：DCの参照先は他のDCを先に、自分自身を後にする。社外の名前はフォワーダーでキャッシュDNSに集約する（第3回）
$ dig +short SRV _ldap._tcp.dc._msdcs.corp.example.jp
0 100 389 dc01.corp.example.jp.
0 100 389 dc02.corp.example.jp.

PS> Resolve-DnsName _ldap._tcp.dc._msdcs.corp.example.jp -Type SRV
PS> nltest /dsgetdc:corp.example.jp          # 実際に見つかる DC

スカベンジング

もう1つ、AD統合DNSで知っておきたいのがスカベンジング（古いレコードの自動削除）です。

レコード登録から7日間の更新禁止期間、次の7日間の更新期間を経て、14日間更新がないと古いと判定されて削除対象になるスカベンジングの既定値と、有効化と間隔の注意点を示す図

既定は更新禁止7日＋更新7日で、14日更新がないと古いと判定されます。ゾーンとサーバーの両方で有効にしないと動かず、間隔を24時間未満にすると、生きている端末のレコードまで消えます。撤去したサーバーやDCのレコードが残り続けていたら、スカベンジングの設定を確認しましょう。

KubernetesのDNS

冒頭の「Kubernetesに載せたら外部APIの呼び出しが遅くなった」の話です。

クラスターの中ではCoreDNSが、Serviceの名前に答える権威DNSと、外部の名前を引くキャッシュDNSを兼ねます。Serviceは<サービス名>.<名前空間>.svc.cluster.localで引けます。

Podの/etc/resolv.conf（既定のdnsPolicy: ClusterFirst、名前空間prodの例）は、次のようになっています。

nameserver 10.96.0.10
search prod.svc.cluster.local svc.cluster.local cluster.local
options ndots:5
api.example.comを引くとき、ドットが2個でndots:5未満なのでsearchのドメインを付けた3つの名前がA/AAAAでNXDOMAINになってから本来の名前を引き、最大8回の問い合わせになることと、末尾のドット・ndotsの変更・NodeLocal DNSCacheの対策を示す図

ndots:5の意味：ドットが5個未満の名前は、まずsearchのドメインを付けて試します。外部のapi.example.comを引くと、api.example.com.prod.svc.cluster.localなどの3つがNXDOMAINになってから本来の名前を引くため、AとAAAAで最大8回の問い合わせになります（ノードのsearchが加わるとさらに増えます）。

  • 影響：CoreDNSと上流のDNSへの問い合わせが増え、名前解決が遅くなる。AWSではENIあたり1024ppsの上限に当たることもある
  • 対策：外部の名前は末尾にドットを付けたFQDNで書く、PodのdnsConfigでndotsを下げる（例：2）、NodeLocal DNSCacheで各ノードにキャッシュを置く、CoreDNSのレプリカ数とキャッシュを調整する

第2回・第3回で見た「末尾のドット」と「searchドメイン」の話が、ここで効いてくるわけです。

vSphereなどの製品でDNSが重要な理由

最後に、インフラ製品とDNSの関係です。多くの製品にとって、DNSは構築の前提条件です。

vCenter Serverの正引き（A）と逆引き（PTR）の一致が構築の前提で、名前が証明書・シングルサインオン・ESXiホストの登録・メール通知・NFS 4.1のKerberosに組み込まれることを示す図

代表例のvSphereでは、vCenter ServerをFQDNで構築するとき、正引き（A）と逆引き（PTR）の両方が登録され、一致していることが要件で、満たさないとデプロイや初回起動が失敗します。vCenterの名前は証明書やシングルサインオンに組み込まれるため、後から変えるのは大きな作業です。

ほかにも、次のような例があります。

  • 送信元や宛先のドメインをDNSで解決できないと、vCenterのメール通知が送られない事象（Broadcom KB 321441）
  • ESXiでNFS 4.1のKerberos認証を使うときに、KDCをSRVで引けるDNSが必要

Kerberosは名前で相手を確かめ、証明書も名前に対して発行されるため、同じことは多くの製品にいえます。名前は製品の中に焼き込まれるので、後で直すより、構築前に製品のDNS要件を確認し、AとPTRを先に登録しておきましょう。

考えてみよう

  1. あなたのAWS（またはAzure）のVPCでは、EC2はどのDNSサーバーを参照していますか。オンプレの名前は、どの経路で引いていますか。
  2. ADのDNSで、スカベンジングは有効になっていますか。撤去したサーバーやDCのレコードが残っていないか、確かめる方法を考えてください。
  3. KubernetesのPodで、外部のAPIを毎秒100回呼ぶアプリがあります。ndotsとsearchによって、DNSの問い合わせは毎秒何件になりそうですか。

ヒント：1問目はDHCPオプションセットと転送ルール、2問目はタイムスタンプとnetlogon.dns、3問目はsearchの数とA/AAAAから考えてみてください。

まとめ

  • Route 53は権威DNS・レジストラー・VPCのリゾルバーの3役。パブリックはNS 4台を親に登録して委任完成
  • ルーティングポリシーは権威の答えを変えるだけ。キャッシュにはTTLが切れるまで効かない
  • VPC Resolverは一致したゾーンに無い名前をNXDOMAINにする
  • ハイブリッドは両方向の条件付きフォワーダー。AWS側はサブドメインに分ける
  • AD統合DNSはマルチマスター。SRVと_msdcs、スカベンジングを押さえる
  • Kubernetesはndots:5で外部の名前の問い合わせが増える。vSphereは正引きと逆引きの一致が前提

次回は、ここまでの知識を使って、DNSの障害を切り分ける手順をまとめます。

連載「DNS入門」全12回

  1. DNSとは？名前解決の全体像と3つの登場人物
  2. ドメイン名の階層と委任
  3. 名前解決の流れ
  4. DNSメッセージとトランスポート
  5. リソースレコード 前編
  6. リソースレコード 後編
  7. 権威DNSサーバーの運用
  8. コマンドで調べる
  9. DNSのセキュリティ
  10. クラウド・社内環境のDNS（この記事）
  11. DNSトラブルシュート
  12. DNS設計演習

コメント

タイトルとURLをコピーしました