Custom DNS resolver in private synthetic locations: no DNS-over-TLS enforcement

Direct Answers

1. Enforcing encrypted DNS: As of the current SaaS release, there is no native mechanism to enforce DNS-over-TLS (DoT) or DNS-over-HTTPS (DoH) for a private synthetic location's custom resolver. The platform accepts only a plain IP address for UDP/TCP port 53 resolution.

2. Supported configuration field: No DoT/DoH field exists in the UI or the JSON export. The location configuration schema exposes a single resolver IP property; encrypted DNS protocols are not represented.

3. Permission boundary for DNS-only edits: No granular permission exists. DNS resolver changes are gated by the broader "Edit Synthetic Locations" privilege (typically bundled with Environment Admin or Synthetic Admin roles).

Why This Gap Exists

Private synthetic locations run on customer-managed ActiveGates. The resolver setting is passed to the ActiveGate process, which performs standard recursive queries on port 53. The platform does not currently embed a DoT/DoH client (such as stubby or cloudflared) inside the ActiveGate container, nor does it expose a protocol selector in the location configuration API.

Practical Mitigations (Ordered by Operational Overhead)

1. Network-level encryption: Deploy a local DoT/DoH forwarder (e.g., stubby, dnscrypt-proxy, or cloudflared proxy-dns) on the ActiveGate host or a dedicated VM in the same network segment. Point the private location's custom resolver to 127.0.0.1#53 (or the forwarder's IP) so cleartext never leaves the host.
2. Split-horizon DNS with internal resolver: If compliance permits, run an internal recursive resolver that itself forwards over DoT to upstream providers. The synthetic location then talks to the internal resolver over standard port 53 within a trusted VPC.
3. Egress firewall rule: Block outbound UDP/TCP 53 from the ActiveGate host except to the approved forwarder. This prevents accidental cleartext leakage if the forwarder misconfiguration occurs.

Verification Steps

1. Open the Dynatrace UI → Settings → Web & Mobile Monitoring → Private Synthetic Locations → select location → Custom DNS resolver. Confirm only an IP input is present.
2. Export the location via API (GET /api/config/v1/synthetic/locations/{id}) and inspect JSON for any dnsOverTls, dnsOverHttps, or resolverProtocol fields. None should appear.
3. On the ActiveGate host, run tcpdump -ni any port 53 while a synthetic monitor executes. Verify queries leave the host only toward the configured forwarder, not directly to external resolvers.

Assumptions & Uncertainty

This analysis assumes a standard Dynatrace SaaS tenant on a recent release (2024–2025). On-premise/Managed clusters may have different feature parity. Dynatrace does not publish a public changelog entry confirming DoT/DoH support for private locations; the absence is inferred from UI, API schema, and community reports.

One diagnostic detail that would change the recommendation: Does your ActiveGate host already run a local DNS forwarder (e.g., systemd-resolved with DoT configured) listening on 127.0.0.1:53? If yes, simply point the private location to 127.0.0.1 and validate with the tcpdump step above.