DNS レコード
このページでは、オンプレミス DuoKey デプロイメント向けに作成する DNS レコードを一覧します。 レコードは、外部（Microsoft 365 / Office クライアントおよび任意のリモートユーザーが解決可能）と 内部（社内ネットワークおよびクラスター内で解決可能）に分かれています。
DKE キーエンドポイントのホスト名は、3 つの場所で同一でなければなりません。 DNS レコード、TLS 証明書の SAN、および Microsoft Purview 秘密度ラベルで構成された DKE エンドポイント URL です。不一致は DKE 障害の最も一般的な原因です — DKE トラブルシューティング を参照してください。
スプリットホライズン解決
Office クライアントは、保護されたコンテンツが開かれる場所を問わず DKE エンドポイントに到達する必要が あります — 社内ネットワークからも、リモートユーザーの場合はインターネットからも。 スプリットホライズン DNS を使用して、同じホスト名が各ネットワークから適切なエントリポイントに解決される ようにしつつ、ホスト名と TLS 証明書は一貫させます。
外部 DNS レコード
これらをパブリック / 外部の DNS ゾーン（Office クライアントおよびリモートユーザーが 解決可能）に作成します。パブリックイングレス VIP またはリバースプロキシに向けます。
| ホスト名（例） | タイプ | ターゲット | 目的 |
|---|---|---|---|
dke.example.com | A / CNAME | パブリックイングレス VIP / リバースプロキシ | DKE キーエンドポイント — Office クライアントがここでキーを取得（Purview ラベル URL と一致する必要がある） |
cockpit.example.com | A / CNAME | パブリックイングレス VIP | Cockpit 管理者/ユーザー UI（外部からアクセスする場合のみ） |
cockpit-api.example.com | A / CNAME | パブリックイングレス VIP | Cockpit API（外部からアクセスする場合のみ） |
すべてのユーザーが社内ネットワーク内からのみ DKE で保護されたコンテンツを開く場合、 DKE エンドポイントは内部専用（パブリックレコードなし）にできます。決定する前に リモートアクセスのシナリオを確認してください。
内部 DNS レコード
これらを内部の DNS ゾーン（社内ネットワーク / クラスター）に作成します。
| ホスト名（例） | タイプ | ターゲット | 目的 |
|---|---|---|---|
*.apps.<cluster>.example.local | A / ワイルドカード | Ingress Router VIP | OpenShift アプリケーションルート（Cockpit、KMS など） |
api.<cluster>.example.local | A | コントロールプレーン LB VIP | OpenShift API サーバー |
dke.example.com | A / CNAME | 内部 LB VIP | DKE エンドポイント（スプリットホライズン名の内部ビュー） |
cockpit.example.local | A / CNAME | Ingress Router VIP | Cockpit UI（内部アクセス） |
cockpit-api.example.local | A / CNAME | Ingress Router VIP | Cockpit API（内部アクセス） |
dke-kms-api.example.local | A / CNAME | 内部 LB VIP | DKE/KMS API（内部アクセス） |
openbao.example.local | A | OpenBao VIP / VM | シークレットエンジン |
postgres.example.local | A | PostgreSQL VIP / プライマリ | データベース |
gitlab.example.local | A / CNAME | GitLab VM | ソースとレジストリ（GitOps） |
argocd.example.local | A / CNAME | Ingress Router VIP | GitOps コンソール（ArgoCD） |
harbor.example.local | A / CNAME | 内部 Harbor（ミラー） | エアギャップイメージレジストリ |
grafana.example.local | A / CNAME | Ingress Router VIP | オブザーバビリティダッシュボード |
vmselect.example.local | A / CNAME | Ingress Router VIP | VictoriaMetrics クエリエンドポイント（オプション、内部） |
vlogs.example.local | A / CNAME | Ingress Router VIP | VictoriaLogs クエリエンドポイント（オプション、内部） |
クラスター内で相互に通信するコンポーネント（Redis、message broker、vmagent/vmstorage/vminsert、Vector、内部のサービス間呼び出し）は、 Kubernetes サービスディスカバリを使用します — 外部/内部の DNS レコードは不要です。人間または外部システムが 名前で到達するエンドポイントに対してのみレコードを作成してください。
推奨事項
- TTL: 適度な TTL（例: 300〜3600 秒）を使用します。計画的な VIP/エンドポイントの変更前には、 伝播を早めるために一時的に下げてください。
- ヘルスチェック付き VIP: レコードを単一ノードではなく、バックエンドをヘルスチェックする ロードバランサー VIP に向けます。
- 証明書: 外部から到達可能なすべてのホスト名が、その TLS 証明書上の SAN であることを確認します（ネットワークセキュリティ → TLS を参照）。
- 名前を安定させる: 後で DKE エンドポイントのホスト名を変更するには、 Purview ラベル、証明書の更新、およびクライアントの再検証が必要になります。
検証
# Resolve from a client network
nslookup dke.example.com
dig +short dke.example.com
# Confirm the DKE endpoint answers over TLS with the public key (JSON)
curl -I https://dke.example.com/<keyname>
解決またはキーエンドポイントのテストが失敗する場合は、 DKE トラブルシューティング → ステップ 1 を参照してください。