
新しい内部 DNS リゾルバに移行したところ、特定のレコードを検索する機能に影響する制限が見つかりました。
弊社の内部(プライベート)権威ドメインは ですexample.net.
。 のCNAMEレコードはservice.example.net.
次のように解決されます。name-1234567890.region.elb.amazonaws.com.
name-1234567890.region.elb.amazonaws.com.
さまざまな A レコードに解決され、その値は AWS によって管理されます。パブリック amazonaws.com ゾーンやこのゾーン内のレコードは AWS によって管理されません。
以前の DNS リゾルバは CNAME レコードを「追跡」していたため、検索するとservice.example.net.
次のような結果が返される可能性があります。
$ dig service.example.net
...
;; ANSWER SECTION:
service.example.net. 300 IN CNAME name-1234567890.region.elb.amazonaws.com.
name-1234567890.region.elb.amazonaws.com. 26 IN A 10.1.2.3
name-1234567890.region.elb.amazonaws.com. 26 IN A 10.1.2.4
回答には、CNAME が指す A レコードの IP が含まれています。すべて正常です。
新しい DNS リゾルバは CNAME レコードを「追跡」しません。新しいリゾルバを使用した同じ検索は次のようになります。
$ dig service.example.net
...
;; ANSWER SECTION:
service.example.net. 300 IN CNAME name-1234567890.region.elb.amazonaws.com.
... A レコードが欠落していることに注意してください。ping、curl、python リクエストなどを介して接続しようとするとservice.example.net
、すべて「不明なホスト」エラーになります。
新しい DNS リゾルバの動作を変更することはできません。古い DNS リゾルバがサーバー側で行っていたのと同じように、クライアントから CNAME レコードを「追跡」するためのオプションが Linux カーネルまたはローカル DNS リゾルバにあるのでしょうか?
文脈上、私たちの新しいDNSリゾルバはGCPのcloud-dnsであり、文書この動作。
追加のコンテキスト/コメントの回答:
- example.net は、当社が所有するクラウド DNS 内のプライベートな内部管理ゾーンです。
- amazonaws.com は AWS によって管理されるパブリックゾーンです。
- 記憶が正しければ、追加のネームサーバーを含む送信サーバーポリシーは、全てそれらのネームサーバーにクエリを送信し、クラウドDNSを上書きする
- 記憶が正しければ、ALIAS レコードはパブリック ゾーンでのみ使用可能であり、プライベート ゾーンでは使用不可です。
- service.exmaple.net は、プライベートの管理されたクラウド DNS ゾーン example.net 内の CNAME レコードです。
- AWS に拠点がないため、route53 を使用できません。
答え1
ロードバランサーの内部IPを直接指定するのではなく、ロードバランサーのパブリックDNS名を指定する必要があります。
name-1234567890.region.elb.amazonaws.com
したがって、aレコードを削除し、cname値をロードバランサーのパブリックDNS名に変更します。
答え2
この質問に関する最新情報を提供したいと思います。この問題が発見されて以来、GCP はパブリック CNAME レコードを追跡する cloud-dns の実験的な機能の展開を開始しました。執筆時点 (2024 年 4 月) では、この機能は GCP サポートに明示的にリクエストする必要があります。いつ GA になるかはわかりません。
この機能が利用できるようになる前は、たとえば、パブリックamazonaws.com
DNS リゾルバー (8.8.8.8、1.1.1.1 などを使用) に転送するプライベート転送ゾーンをクラウド DNS 内に作成することで問題を回避していました。これは、プライベート ゾーン間のクラウド DNS で CNAME 追跡が有効になっているため機能します。amazonaws.com
クラウド DNS によってプライベート ゾーンと見なされるようになったため、CNAME 追跡要求は正常に解決されるようになりました。
答え3
awsレコードを解決するには、awsからroute53を調べることをお勧めします。内部DNSサーバーをroute53に転送することができます。たとえば、unboundはそれを実行できるDNSリボルバーです。
Amazon Route 53 は、Amazon Web Services (AWS) が提供する、スケーラブルで可用性の高いドメイン ネーム システム (DNS) Web サービスです。example.com などのユーザー フレンドリなドメイン名を、インターネット上でコンピューターが互いを識別するために使用する IP アドレスに効果的に変換します。Route 53 の主な機能と概念の概要は次のとおりです。
- ドメイン登録: Route 53 を使用すると、ドメイン名を登録および管理できます。新しいドメインを購入したり、既存のドメインを Route 53 に移管したりできます。
- DNS サービス: Route 53 は DNS サービス プロバイダーとして機能し、ドメインの DNS レコードを管理できるようにします。DNS レコードには、A レコード (ドメイン名を IP アドレスにマッピング)、CNAME レコード (ドメイン名を他のドメイン名にマッピング)、MX レコード (メール サーバーを指定する) などがあります。ヘルス チェックとフェイルオーバー: Route 53 は、Web サーバーなどのエンドポイントでヘルス チェックを実行し、トラフィックを正常でないエンドポイントから正常なエンドポイントに自動的にルーティングできます。この機能は、フェイルオーバーおよび災害復旧ソリューションの実装によく使用されます。
- トラフィック管理: Route 53 はトラフィック管理機能を提供しており、レイテンシー、地理位置情報、加重ルーティングなどのさまざまな要素に基づいて DNS クエリのルーティング方法を制御できます。これにより、アプリケーションのパフォーマンスと可用性を最適化できます。AWS サービスとの統合: Route 53 は、Amazon S3、Elastic Load Balancing (ELB)、Amazon CloudFront などの他の AWS サービスとシームレスに統合されます。たとえば、Route 53 を使用してトラフィックを ELB ロードバランサーまたは CloudFront ディストリビューションにルーティングできます。
- DNSSEC: Route 53 は DNS セキュリティ拡張機能 (DNSSEC) をサポートしています。DNSSEC は、DNS レコードにデジタル署名することで、DNS インフラストラクチャにセキュリティの層を追加します。全体として、Route 53 は、インターネット上のアプリケーションやサービスへのトラフィックをルーティングするための基盤を提供する、多用途で信頼性の高い DNS サービスです。DNS の管理、パフォーマンスの向上、高可用性の確保のための高度な機能を提供します。