A branch office's filtering DNS resolver blocks a malicious name — what has to be true for that block to apply?
answer
- a control the client opts into
- DHCP hands out a suggestion
- the query has to arrive first
- a block proves refusal, not absence
basics
~20 sThe endpoint has to send that query to your resolver. A filtering resolver is a control the client opts into: a host that asks a different resolver, or ships its own, is never offered the block.
solid answer
~40 sA filtering resolver only ever sees a name a client chose to send it. You hand its address out by DHCP and by resolver settings on managed endpoints, but that is a default the operating system, an application or an implant can override — a browser that turns on DNS-over-HTTPS, a user who fixes slow page loads by pointing the machine at the ISP's resolver, or malware that carries its own resolver address and talks to it on 443. So the block proves something narrow: a client at that source address asked you for the name and you refused. It proves nothing about names resolved by any other path. That is why the filter has to be paired with something that forces the path, blocks the alternatives, or at least counts who still asks.
go deeper
Be ready to say plainly that a filtering resolver only sees queries sent to it, and to name two ways a host stops sending them: an application that resolves on its own, and someone changing the configured resolver.
Explain how a resolver address actually reaches a host — DHCP and endpoint resolver policy — and why both are defaults rather than enforcement, including application-level resolvers that consult neither.
Show the pairing you would actually build: forcing clear-text queries to your resolver at the branch, blocking known encrypted-resolver destinations, and measuring which endpoints still appear in query logs — and state the latency you accepted to keep resolution hosted.
Own the trade: what share of resolution you can honestly claim to see, what raising that share costs per branch, and which parts of the estate you consciously accept as unmeasured rather than funding forever.
## What the control is A filtering resolver is a recursive DNS server that answers queries normally except for names on a policy list, which it refuses or answers with a sinkhole address. At a branch office on consumer broadband it is often the only security control in the building: there is one router, no local inspection stack, and the resolver sits somewhere on the public internet. It is popular because it is cheap to turn on and applies to everything on the LAN that uses it — laptops, phones, printers, a contractor's machine you do not manage. The whole of the interview question lives in the last three words: **that uses it**. ## How a host decides which resolver to ask There are four paths, and only two of them are yours: - **DHCP** at the branch router hands out a resolver address when the host joins the network. - **Operating-system resolver configuration** on a managed endpoint, set by whatever endpoint policy you run. - **An application's own resolver**, which consults neither of the above — a browser with DNS-over-HTTPS enabled resolves through its own configured endpoint on 443. - **A hard-coded address inside a program**, which asks nobody's opinion at all. The first two are defaults a host may override. The last two never look at them. A filtering resolver is therefore not an enforcement point; it is an offer. ## The price, and why the price causes the bypass Moving resolution to a hosted filter means every name a branch user needs that is not already cached costs a round trip across the internet before the first byte of the page is fetched. On consumer broadband, on a page that pulls resources from a dozen domains, users feel that. The local fix is always the same and always available: point the machine — or the router — at the ISP's resolver, which is nearer and faster. That matters for a reason beyond user experience. From your side, a host that was repointed by a helpful user and a host that was repointed by something hostile look identical: the queries simply stop arriving. You do not get an event when a client leaves; you get silence, and silence is also what an idle laptop produces. ## The adversary An implant is under no obligation to use the system resolver. It can carry the address of a public encrypted resolver and speak DNS-over-HTTPS to it on 443, where the session is indistinguishable by port from ordinary web traffic, or it can query an authoritative server directly. In neither case does your filter appear in the path, hold a record, or get a chance to refuse. "We have DNS filtering" is therefore never a complete answer to "how would you have seen this". ## What a block proves — and what it does not A block entry proves: a client at that source address asked your resolver for that name at that time, and you refused to answer. It does not prove that the host failed to reach the destination (it may already hold an address, or have another route to it), that anything malicious happened (block lists carry advertising, tracking and policy categories, so a hit is often a benign true positive), or that the host resolved nothing else elsewhere. Equally, the absence of blocked queries from a host proves nothing at all. It is consistent with a clean host, a host that was switched off, a host resolving through somebody else, and a host whose records never reached your logging. ## What you pair it with | Position | What it covers | What it never sees | | --- | --- | --- | | DHCP and endpoint resolver policy | Hosts that accept the default | Applications with their own resolver | | Redirecting plaintext port 53 at the branch router | Anyone asking anyone in the clear | Encrypted resolution on 853 or 443 | | Blocking known encrypted-resolver destinations | Public providers you have listed | An endpoint the adversary hosts themselves | | Comparing querying sources against the asset inventory | Who did ask you | Anyone who asked someone else | None of the four is free, and stacking all four is how the honest version of this control gets built. ## What to say in an interview Say that a filtering resolver is a visibility and policy control that depends on the client continuing to ask you; name the two everyday ways a client stops asking (an application resolving on its own, and someone repointing the machine because the hosted path is slower); and say what a block entry actually evidences. The candidate who claims the filter blocks the name "for the network" has missed the only thing this control is interesting for.
- Branch users repoint their machines at the ISP's resolver because the hosted filter feels slow. What do you do about it?Treat it as a real cost, not user misbehaviour: measure the added round trip, and put a caching forwarder at the branch if the estate justifies one. Then make repointing harder — lock the resolver setting on managed endpoints and redirect outbound plaintext port 53 at the router to your resolver — and accept that this catches only clear-text queries. Finally, monitor which endpoints have stopped appearing in the query logs, because that is the signal you actually get.
- What does a spike in blocked queries from one branch host actually tell you?That the host asked your resolver for names on your list, repeatedly, and you refused. It does not tell you the host is compromised. Advertising, tracking, newly-registered-domain and category rules generate large volumes of benign true positives, so the first job is to see which list entries matched and whether a normal application explains them. It also does not tell you the host got no answer from anywhere else.
- Why is 'we saw no blocked queries from that host' not evidence that it is clean?Because the statement has at least four explanations: the host was off, the host resolved through a different resolver, the names it used are not on your list, or its query records never reached your logging. Absence of an event from a control that only sees what it is asked is not evidence of absence of the behaviour. You need a second source — egress records, or an active check from the endpoint — to tell those four apart.
It is a doorman who only checks the guests who walk up to that door. Anyone using another entrance is never checked, and never appears in the log either.
saying these in an interview costs you the question
- Says the filter blocks that name for every host on the network
- Treats a DHCP-supplied resolver address as enforcement
- Reads zero blocked queries from a host as proof it is clean
- Assumes malware must use the system resolver
- Calls every blocked query evidence of compromise