Setting up DNS-over-HTTPS (DoH)
Bouncer secures DNS at the resolver, using DNS-over-HTTPS (DoH) with mutual-TLS client identity. This article covers what that means in practice and how to get a client pointed at it.
Why DoH, and why mutual TLS
Standard DNS is unauthenticated and unencrypted — any device on the path can see, and in some cases tamper with, a plaintext DNS query. DoH wraps DNS queries in HTTPS, closing that visibility gap. Bouncer goes a step further by requiring mutual TLS: the client doesn't just verify the resolver's certificate, the resolver also verifies the client's certificate. That client certificate is the same kind of certificate-based identity used elsewhere across the platform (see Understanding agent identities and scoped access for the equivalent concept on the Bursar side).
Policy follows the certificate, not the IP
This is the key architectural difference from most DNS security products: policy is bound to the certificate identity, not to a source IP address. IP-based policy breaks down constantly in modern environments — laptops roam between networks, cloud workloads get new addresses on every restart, NAT hides the real source behind a shared egress IP. Because Bouncer's policy is tied to the presenting certificate, a device's DNS resolution policy stays consistent no matter what network it's connected to, and a compromised or spoofed IP address can't be used to inherit someone else's DNS policy.
Getting a device connected
- Ensure the device has a valid certificate identity issued through your organization (the same certificate provisioning flow used elsewhere on the platform).
- Configure the device or endpoint's DNS resolver settings to use Bouncer's DoH endpoint instead of the network's default resolver.
- The client presents its certificate on connection; Bouncer validates it and begins applying that identity's policy to every subsequent DNS lookup from that device.
Where Bouncer fits alongside Broker and Bursar
Bouncer can attach to any existing Broker or Bursar deployment today — it doesn't require a from-scratch rollout. A standalone edition (for organizations that want DNS security without the full connectivity or agent-identity stack) is on the roadmap. Once DoH is configured, see Understanding block policies and threat categories for what actually gets blocked and why.