DNS-Einträge
Diese Seite listet die DNS-Einträge auf, die für eine On-Premise-DuoKey-Bereitstellung zu erstellen sind. Die Einträge sind unterteilt in externe (auflösbar durch Microsoft 365 / Office-Clients und beliebige Remote-Benutzer) und interne (auflösbar innerhalb Ihres Unternehmensnetzwerks und des Clusters).
Der Hostname des DKE-Schlüsselendpunkts muss an drei Stellen identisch sein: im DNS-Eintrag, im SAN des TLS-Zertifikats und in der auf der Microsoft Purview Vertraulichkeitsbezeichnung konfigurierten DKE-Endpunkt-URL. Ein Mismatch ist die häufigste Ursache für DKE-Fehler — siehe DKE-Fehlerbehebung.
Split-Horizon-Auflösung
Office-Clients müssen den DKE-Endpunkt überall dort erreichen, wo geschützte Inhalte geöffnet werden — im Unternehmensnetzwerk und, für Remote-Benutzer, aus dem Internet. Verwenden Sie Split-Horizon-DNS, damit derselbe Hostname aus jedem Netzwerk auf den richtigen Einstiegspunkt aufgelöst wird, während Hostname und TLS-Zertifikat konsistent bleiben.
Externe DNS-Einträge
Erstellen Sie diese in Ihrer öffentlichen / externen DNS-Zone (auflösbar durch Office-Clients und Remote-Benutzer). Richten Sie sie auf Ihren öffentlichen Ingress-VIP oder Reverse-Proxy aus.
| Hostname (Beispiel) | Typ | Ziel | Zweck |
|---|---|---|---|
dke.example.com | A / CNAME | Öffentlicher Ingress-VIP / Reverse-Proxy | DKE-Schlüsselendpunkt — Office-Clients beziehen den Schlüssel hier (muss mit der Purview-Bezeichnungs-URL übereinstimmen) |
cockpit.example.com | A / CNAME | Öffentlicher Ingress-VIP | Cockpit-Admin-/Benutzer-UI (nur bei externem Zugriff) |
cockpit-api.example.com | A / CNAME | Öffentlicher Ingress-VIP | Cockpit-API (nur bei externem Zugriff) |
Wenn alle Benutzer DKE-geschützte Inhalte nur aus dem Unternehmensnetzwerk öffnen, kann der DKE-Endpunkt nur intern sein (kein öffentlicher Eintrag). Bestätigen Sie Ihr Remote-Access-Szenario, bevor Sie entscheiden.
Interne DNS-Einträge
Erstellen Sie diese in Ihrer internen DNS-Zone (Unternehmensnetzwerk / Cluster).
| Hostname (Beispiel) | Typ | Ziel | Zweck |
|---|---|---|---|
*.apps.<cluster>.example.local | A / Wildcard | Ingress-Router-VIP | OpenShift-Anwendungsrouten (Cockpit, KMS usw.) |
api.<cluster>.example.local | A | Control-Plane-LB-VIP | OpenShift-API-Server |
dke.example.com | A / CNAME | Interner LB-VIP | DKE-Endpunkt (interne Sicht des Split-Horizon-Namens) |
cockpit.example.local | A / CNAME | Ingress-Router-VIP | Cockpit-UI (interner Zugriff) |
cockpit-api.example.local | A / CNAME | Ingress-Router-VIP | Cockpit-API (interner Zugriff) |
dke-kms-api.example.local | A / CNAME | Interner LB-VIP | DKE/KMS-API (interner Zugriff) |
openbao.example.local | A | OpenBao-VIP / VMs | Secret-Engine |
postgres.example.local | A | PostgreSQL-VIP / Primary | Datenbank |
gitlab.example.local | A / CNAME | GitLab-VM | Quellcode & Registry (GitOps) |
argocd.example.local | A / CNAME | Ingress-Router-VIP | GitOps-Konsole (ArgoCD) |
harbor.example.local | A / CNAME | Internes Harbor (Mirror) | Air-gapped Image-Registry |
grafana.example.local | A / CNAME | Ingress-Router-VIP | Observability-Dashboards |
vmselect.example.local | A / CNAME | Ingress-Router-VIP | VictoriaMetrics-Abfrageendpunkt (optional, intern) |
vlogs.example.local | A / CNAME | Ingress-Router-VIP | VictoriaLogs-Abfrageendpunkt (optional, intern) |
Komponenten, die innerhalb des Clusters miteinander kommunizieren (Redis, der Message Broker, vmagent/vmstorage/vminsert, Vector, interne Service-zu-Service-Aufrufe), verwenden Kubernetes Service Discovery — es ist kein externer/interner DNS-Eintrag erforderlich. Erstellen Sie nur Einträge für Endpunkte, die Menschen oder externe Systeme namentlich erreichen.
Empfehlungen
- TTL: verwenden Sie eine moderate TTL (z. B. 300–3600 s). Senken Sie sie vorüberge- hend vor einer geplanten VIP-/Endpunktänderung, um die Propagation zu beschleunigen.
- Health-checked VIP: richten Sie Einträge auf einen Load-Balancer-VIP aus, der die Backends per Health-Check überprüft, nicht auf einen einzelnen Knoten.
- Zertifikate: stellen Sie sicher, dass jeder extern erreichbare Hostname ein SAN auf seinem TLS-Zertifikat ist (siehe Netzwerksicherheit → TLS).
- Namen stabil halten: eine spätere Änderung des DKE-Endpunkt-Hostnamens erfordert die Aktualisierung der Purview-Bezeichnung, des Zertifikats und die erneute Validierung der Clients.
Validierung
# 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>
Wenn die Auflösung oder der Schlüsselendpunkt-Test fehlschlägt, siehe DKE-Fehlerbehebung → Schritt 1.