DNS Records
This page lists the DNS records to create for an on-premise DuoKey deployment. Records are split into external (resolvable by Microsoft 365 / Office clients and any remote users) and internal (resolvable inside your corporate network and the cluster).
The DKE key endpoint hostname must be identical in three places: the DNS record, the TLS certificate SAN, and the DKE endpoint URL configured on the Microsoft Purview sensitivity label. A mismatch is the most common cause of DKE failures — see DKE Troubleshooting.
Split-horizon resolution
Office clients must reach the DKE endpoint wherever protected content is opened — on the corporate network and, for remote users, from the internet. Use split-horizon DNS so the same hostname resolves to the right entry point from each network, while the hostname and TLS certificate stay consistent.
The same hostname resolves to a public ingress for remote users and to an internal LB VIP for on-network users; both paths reach the OpenShift Ingress Router and the DKE endpoint.
External DNS records
Create these in your public / external DNS zone (resolvable by Office clients and remote users). Point them at your public ingress VIP or reverse proxy.
| Hostname (example) | Type | Target | Purpose |
|---|---|---|---|
dke.example.com | A / CNAME | Public ingress VIP / reverse proxy | DKE key endpoint — Office clients fetch the key here (must match the Purview label URL) |
cockpit.example.com | A / CNAME | Public ingress VIP | Cockpit admin/user UI (only if accessed externally) |
cockpit-api.example.com | A / CNAME | Public ingress VIP | Cockpit API (only if accessed externally) |
If all users open DKE-protected content only from inside the corporate network, the DKE endpoint can be internal-only (no public record). Confirm your remote-access scenario before deciding.
Internal DNS records
Create these in your internal DNS zone (corporate network / cluster).
| Hostname (example) | Type | Target | Purpose |
|---|---|---|---|
*.apps.<cluster>.example.local | A / wildcard | Ingress Router VIP | OpenShift application routes (Cockpit, DKE/KMS/KMIP, etc.) |
api.<cluster>.example.local | A | Control-plane LB VIP | OpenShift API server |
dke.example.com | A / CNAME | Internal LB VIP | DKE endpoint (internal view of the split-horizon name), served by the Cockpit API |
cockpit.example.local | A / CNAME | Ingress Router VIP | Cockpit UI (internal access) |
cockpit-api.example.local | A / CNAME | Ingress Router VIP | Cockpit API — DKE / KMS / KMIP endpoints (internal access) |
openbao.example.local | A | OpenBao VIP / VMs | Secret engine |
postgres.example.local | A | PostgreSQL VIP / primary | Database |
gitlab.example.local | A / CNAME | GitLab VM | Source & registry (GitOps) |
argocd.example.local | A / CNAME | Ingress Router VIP | GitOps console (ArgoCD) |
harbor.example.local | A / CNAME | Internal 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 query endpoint (optional, internal) |
vlogs.example.local | A / CNAME | Ingress Router VIP | VictoriaLogs query endpoint (optional, internal) |
Components that talk to each other inside the cluster (Redis, vmagent/vmstorage/vminsert, Vector, internal service-to-service calls) use Kubernetes service discovery — no external/internal DNS record is required. Only create records for endpoints that humans or external systems reach by name.
Recommendations
- TTL: use a moderate TTL (e.g. 300–3600s). Lower it temporarily before a planned VIP/endpoint change to speed propagation.
- Health-checked VIP: point records at a load-balancer VIP that health-checks the backends, not at a single node.
- Certificates: ensure every externally-reachable hostname is a SAN on its TLS certificate (see Network Security → TLS).
- Keep names stable: changing the DKE endpoint hostname later requires updating the Purview label, the certificate, and re-validating clients.
Validation
# 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>
If resolution or the key endpoint test fails, see DKE Troubleshooting → Step 1.