skip to content

Your resolver answers NXDOMAIN for use-application-dns.net to switch browsers off DoH — why doesn't that keep an implant in your filter?

level: middleimportance: should knowfreq 46%

answer

  1. who has to agree for it to work
  2. a request, not a control
  3. explicit policy outranks the signal
  4. hostile code never checks it

basics

~20 s

Because the canary is a request that only cooperating software honours. A browser checks that name and voluntarily falls back to the system resolver; an implant with a hard-coded DNS-over-HTTPS endpoint never asks, and never sees the signal.

solid answer

~50 s

The canary domain is an opt-out convention, not an enforcement point. One browser vendor's default rollout of DNS-over-HTTPS checks `use-application-dns.net` against the system resolver, and treats NXDOMAIN as the network saying "do not turn DoH on here". That works because the browser chooses to look, and only for that vendor's default — enterprise policy overrides it in either direction, and other applications ignore it entirely. Hostile software has no reason to participate: an implant carries a resolver endpoint and opens TLS to it on 443, which your filter never sees and your canary answer never touches. So the canary is worth serving — it is nearly free — but it belongs in the same category as DHCP: a default. What holds against an adversary is pinned resolver policy on managed endpoints, a destination block on known encrypted resolvers, and measurement of who still asks you.

code

text · 8 lines
text
; branch filtering resolver — query log
09:14:02  10.20.4.31  use-application-dns.net  A  -> NXDOMAIN   ; browser leaves DoH off
09:14:03  10.20.4.31  intranet.example.internal A -> 10.20.1.9
...
; branch router — flow records, same host (five-tuple, counts, timestamps; no payload)
09:31:40  10.20.4.31:51512 -> 203.0.113.10:443  TCP  6 pkts   812 B out  1340 B in
09:33:41  10.20.4.31:51689 -> 203.0.113.10:443  TCP  6 pkts   798 B out  1281 B in
; 203.0.113.10 is a public DoH endpoint. No query for those names ever reached the resolver.

go deeper

for a junior

Know that some software resolves names on its own over HTTPS instead of asking the operating system, and that a canary name is how a browser asks the network whether to do that.

for a middle

Explain the exchange — the browser queries the canary name through the system resolver and treats NXDOMAIN as an instruction to stay off DoH — and why an explicit policy setting and non-cooperating software both bypass it.

for a senior

Be ready to say what the canary covers and what it does not, and to lay out the controls that reach the rest: pinned resolver policy per application, a destination block on public providers, and a measurement that tells you the coverage you actually have.

for a principal

The argument to own is against a free control that feels complete. Decide what you will fund to reach the non-cooperating population, and state the coverage figure you are prepared to put in front of an auditor.

## The mechanism When a browser ships DNS-over-HTTPS on by default, it needs a way to notice networks where turning it on would break something — split-horizon internal names, a mandated filtering resolver, a school or workplace policy. The convention that emerged is a **canary domain**: before enabling DoH, the browser asks the system resolver for a specific name, `use-application-dns.net`. If the answer is NXDOMAIN, the browser reads it as the network signalling "do not use application-level DNS here" and stays on the system resolver. That is the whole mechanism. It is a name lookup and a voluntary decision made by one program. ## Why it is a courtesy, not a control Three properties follow directly, and each is worth stating in an interview: 1. **The software has to choose to look.** The check exists in a particular vendor's default-enablement logic. Nothing in DNS requires it, no operating system enforces it, and no server can compel it. 2. **It only governs a default.** If a browser has been explicitly configured — by the user, or by enterprise policy pointing it at a resolver you run — the explicit setting wins and the canary is not consulted. Serving NXDOMAIN does not un-configure anything. 3. **It is per-vendor and per-application.** Other browsers, updaters, vendor agents and runtimes that resolve on their own have never heard of that name. So the canary reaches exactly the population that was going to cooperate anyway. ## The adversary An implant's resolution path is chosen by its author. The straightforward version is a hard-coded public DoH endpoint, reached over TLS on 443 — the same port and the same shape as the browsing traffic already leaving the branch, so nothing about the session's destination port distinguishes it. The implant never queries `use-application-dns.net`, so your NXDOMAIN is never delivered to it; and it never queries your resolver for the names it actually cares about, so your block list is never consulted and your query log never records the names. This is the wrong answer the question is aimed at. "We return NXDOMAIN on the canary, so DoH is handled" is a sentence a competent engineer says, and it describes a control that is correct about browsers and irrelevant to malware. ## What the canary still buys you It is not worthless. Serving NXDOMAIN for that one name is close to free and it keeps unmanaged, personally-owned and guest browsers at the branch resolving through the filter you can see, which on a consumer-broadband site with no other control is a real fraction of the traffic. The danger is not the mechanism, it is the belief: the canary produces a comfortable feeling of coverage that no measurement supports. ## What actually holds, and what each costs | Control | Population it reaches | Price | | --- | --- | --- | | Canary NXDOMAIN | Cooperating browsers on default settings | Almost none, plus a false sense of coverage | | Pinned resolver policy on managed endpoints | Devices you manage, per application | Endpoint management effort, per browser and per OS | | Blocking known encrypted-resolver destinations | Anything reaching a public provider you have listed | A list somebody owns forever, and breakage on enforcement day | | Egress records plus an active check | Nobody — it measures rather than enforces | Collection cost, and it still cannot see a self-hosted endpoint | The honest summary is that the first row is a nudge, the second and third are enforcement over different populations, and the fourth is the only one that tells you how well the first three worked. ## The direction of the claims Be precise about what each observation supports. A canary NXDOMAIN in your query log proves a browser asked and you answered — it does not prove the browser then stayed on your resolver, only that it was told to. A TLS session from a branch host to a known DoH provider's address proves bytes went to that destination — a flow record carries the five-tuple, byte and packet counts and timestamps, and no payload at all, so it cannot show which names were resolved. And the absence of any such session proves nothing about a self-hosted endpoint you never listed.

  • A managed browser is set by enterprise policy to a DoH resolver you operate. Is the canary still relevant on that device?
    No. An explicit configuration is not a default, so the canary check is not what decides the behaviour there — and that is the better position to be in, because you have moved from asking the browser to configuring it. The price is that it only covers devices and applications your endpoint management actually reaches, which at a branch full of unmanaged and personally-owned machines may be a minority of what resolves.
  • What does serving the canary actually cost you?
    Mechanically, almost nothing: you answer NXDOMAIN for one name that does in fact exist publicly, and cooperating browsers stay on your resolver. The real cost is organisational — it is cheap enough that people count it as "DoH handled" and stop funding the controls that reach the non-cooperating population. If you serve it, say in the same breath what share of endpoints it covers and how you know.
  • Could you detect a host using a public DoH endpoint without decrypting anything?
    Partly. Egress records showing repeated small, regular TLS sessions to addresses on your list of known providers are suggestive, and the handshake's server name is visible to a passive observer even though the query names are not. That reaches listed providers only; an endpoint the adversary hosts on their own domain looks like any other HTTPS destination, so this is a way to find the sloppy case, not a coverage measurement.

saying these in an interview costs you the question

  • Calls the canary domain a way to block DoH
  • Assumes all software checks a canary before enabling DoH
  • Thinks NXDOMAIN on one name stops sessions on 443
  • Confuses a browser default with enforced endpoint policy
  • Claims DoH can be blocked by port like DoT

context

resolving links…