You block public DoH and DoT resolvers at a branch edge — what does that list cost to hold, and where does it fail?
answer
- one protocol has its own port
- the other is a list, not a rule
- who owns the entry when it breaks something
- self-hosted endpoints have no ceiling
basics
~20 sDoT is cheap to block: it has its own port, 853. DoH hides on 443, so you hold an address list that is never complete, breaks software quietly depending on a public resolver, and never reaches a self-hosted endpoint.
solid answer
~50 sI would separate the tiers by what they cost. Denying outbound TCP 853 is close to free and its blast radius is legible, because nothing else uses that port. Refusing to resolve the bootstrap names of public DoH providers at my own filter is also cheap, but it is defeated by any client with the address compiled in. Blocking the providers' published address ranges is the expensive tier: the ranges move, the addresses are often shared with the provider's other services, and enforcement day breaks whatever vendor agent or appliance was quietly resolving through them — so each entry needs an owner, a watch window and a named rollback. And the ceiling is structural: an adversary can stand up a DoH endpoint on any host they control, on 443, at a name nobody has listed. The list buys you the population that uses well-known providers, and no more.
go deeper
Know the difference that matters here: DNS-over-TLS uses its own port, 853, while DNS-over-HTTPS is carried on 443 alongside normal web traffic, which is why one is far easier to block than the other.
Explain the tiers — a port rule, refusing the provider's bootstrap name at your resolver, and blocking its addresses — and why a client holding a literal address defeats the middle tier.
Show the operational side: staleness, shared addresses, the software that breaks on enforcement day, an owner and rollback per entry, and the structural ceiling of a self-hosted endpoint on 443.
Be ready to price the list as a permanent commitment and to say what coverage it buys, so the organisation is not told that encrypted resolution is solved when only the well-known share of it is.
## Why the two protocols are not equally hard DNS-over-TLS runs on its own port, TCP 853. That single design decision makes it a network-visible protocol: a border rule denying outbound 853 stops it, and because effectively nothing else lives there, the collateral is small and easy to reason about. DNS-over-HTTPS is deliberately the opposite — it is an HTTPS request to a URL, on 443, sharing a port and a handshake shape with all the ordinary web traffic leaving the branch. There is no port to deny; there is only a set of destinations you have chosen to name. (DNS-over-QUIC adds a UDP-based variant of the same problem.) So the honest description of "we block public encrypted resolvers" is: one protocol is blocked, and the other is filtered by a list. ## The tiers, ordered by what they cost **Deny outbound TCP 853.** Cheap, narrow, self-explaining. The only surprise is usually an appliance or a mobile OS that prefers DoT to a public provider and now falls back — which is the behaviour you wanted, but somebody will file a ticket. **Refuse to resolve the providers' bootstrap names on your own filter.** Also cheap: a client that must first resolve the provider's hostname cannot reach it if you will not answer. It fails the moment the client holds the address literally, which is exactly what a hard-coded implant does and increasingly what shipped software does too. **Block the providers' addresses at the edge.** This is where the money goes. Address ranges change and the list goes stale silently; the same address frequently fronts other services from the same operator, so a block can take out something unrelated; and you learn what depended on public resolution only when it stops. This tier needs a per-entry owner, an observation window before enforcement, and a rollback decision that is made in advance and by name rather than by whoever is awake. ## Where it fails, structurally The list reaches known providers. It does not reach an endpoint the adversary runs: a DoH service on a host they control, at a name you have never seen, on 443. By destination alone that is indistinguishable from any other HTTPS session, so no amount of list maintenance closes the gap. Behavioural signals exist — small, regular, similarly-sized sessions to one destination, and a server name visible in the handshake — but they are leads, not enforcement, and they are the kind of thing you hunt with rather than block on. That means the list should be sold internally for what it is: a control that removes the easy, well-known bypass and raises the effort for everything else. Claiming it stops encrypted resolution is the overstatement that gets found out during the first incident where the implant used its own endpoint. ## The branch-specific costs Two more prices are peculiar to the estate this control usually protects. First, latency: resolution already crosses the public internet to reach the hosted filter, and every block you add pushes more clients onto that slower path rather than the ISP's nearby resolver — which is the very trade users try to undo. Second, failure posture: decide in advance what happens when the branch cannot reach the hosted filter at all. Fail closed means no resolution and no work in that office; fail open to the ISP resolver means the site keeps working and your control is gone for the duration. Whichever you pick, it is a business decision with an owner, not a default to be discovered during an outage. ## What good sounds like A strong answer separates cheap enforcement from expensive enforcement, names the collateral for each tier, states the structural ceiling instead of pretending the list can be completed, and closes with the operational plumbing — an owner per entry, a watch window, a rollback, and a stated failure posture for the branch. A weak answer treats DoH as a port you can deny, or promises that the provider list is maintained by the vendor and therefore fine.
- Enforcement day is Tuesday. In what order do you turn these blocks on?Cheapest and narrowest first, so each step's blast radius is attributable. Port 853 first, since nothing else uses it. Then bootstrap-name refusal on your own resolver, where you can see exactly which clients were relying on it before you enforce. Then provider addresses one operator at a time, each with a watch window and a named person who can roll it back without a meeting. Doing them together means an outage you cannot attribute to a change.
- Your managed browsers are pinned by policy to a resolver you run. Does the destination block still earn its place?Yes, because the two controls reach different populations. Policy covers devices and applications your endpoint management touches; the destination block covers everything else in the building — unmanaged laptops, a contractor's machine, an appliance, and software that resolves on its own. At a branch on consumer broadband that remainder is often the larger half, which is exactly why the list is worth its maintenance cost.
- The branch loses its path to the hosted filter. Do endpoints fail closed or fall back to the ISP resolver?That is a business decision, not a technical default. Fail closed means the office cannot work until the path returns, which is defensible for a segment handling regulated data and indefensible for a sales branch. Falling back keeps the site working and removes the control for the duration, so it needs to be a logged, time-boxed state that someone is told about — not a silent condition you discover afterwards.
saying these in an interview costs you the question
- Claims blocking port 853 also handles DoH
- Believes a public-provider list can be complete
- Blocks provider address ranges with no rollback owner
- Assumes DoH is distinguishable by destination port
- Never states a failure posture for the branch