dnswatchdog.iodocs
Brand Protection

Discovery

Where copycat candidates come from, how they are narrowed to live pages, and how often known findings are re-checked.

Discovery is the first stage of every daily run: it produces candidate domains, drops the ones that are yours or already dismissed, and narrows the rest to pages that can actually be assessed.

Your brands are the seed

Everything starts from the brands on the Brands page under Inventory: the brands you created there, plus the brands DNS Watchdog inferred for your zones (shown in the Brand column of the Zones table). A brand with no zone of its own is searched all the same, so a product line or a retired name can be watched without owning a domain for it.

Brand names are matched loosely on purpose. A candidate counts when its registrable domain contains the brand after confusable normalisation: accents are folded, digits that stand in for letters are treated as those letters, so b0urjois-shop.com matches Bourjois. Multi-word brands are matched as a whole, not word by word, so Wild Garden does not sweep in every domain containing garden.

Sources

Each brand name is searched with the Brave Search API. Every result whose domain contains the brand and is not in your portfolio becomes a candidate. The search pages through results until it has found its target number of matching domains or has read its maximum number of pages, whichever comes first, and a brand is searched again only after its search interval has passed — weekly by default — rather than on every run. So search spend is a handful of queries per brand per week, and it does not grow with the size of your estate.

Domains already known count towards the target, which keeps the search cheap: a brand whose copycats are all on file stops paging early, and those findings are re-checked on their own schedule instead.

Certificate transparency

Newly issued certificates whose names contain a brand token are matched against your brands and fed in as candidates, attributed to the zone whose brand matched. Certificate-log monitoring is switched on per environment and is off by default.

Added by hand

Domains you add yourself on the Brand Protection page (see Adding domains by hand) join the next run as candidates, attributed to the brand you chose or the one their name matches. They go through the same funnel as everything else and are re-checked on the same schedule afterwards; the one difference is that they are never hidden — whatever they score, and even before the model has assessed them.

Scheduled re-checks

Known findings are re-checked without being re-discovered:

FindingRe-checked
Any active findingEvery 7 days
A finding you are watchingEvery day
A finding that resolved but could not be assessedOn the next run
An ignored findingNever

A re-check runs the domain through the same funnel below, so a parked domain that goes live next month is caught, and a page that changes is re-assessed (see Risk assessment).

What is never a candidate

  • Domains you own: your zones, delegated subdomains and web-forward hostnames
  • Domains you have ignored
  • Domains already on file that are not yet due a re-check

The liveness funnel

Candidates pass through a funnel that spends more only on the domains that deserve it:

  1. DNS resolution. Every candidate is resolved. A domain that does not resolve is recorded as unresolved and costs nothing further; one that resolves but serves nothing is dormant.
  2. Page fetch. Only serving domains are fetched — HTTPS first, then HTTP, following redirects — with a browser-like user agent and no credentials. The fetch is bounded (bytes read, redirect hops, a timeout) and turns the home page into a structured snapshot: HTTP status, title, description, visible text, outbound links and the redirect chain. A bounded excerpt of the text is kept on the finding; the fuller text goes to the assessment.
  3. Content fingerprint. The snapshot is fingerprinted, so a later re-check can tell an unchanged page from a changed one without another model call.
  4. Screenshot. Serving findings that are visible (assessed, above the risk floor) are screenshotted, and each screenshot is compared visually against your own sites; the resulting visual distance is one of the signals on the finding page.

Each stage's counts appear under Run statistics — candidates by source, probed, resolved, serving, enriched — so you can see how wide the net was cast and how much survived. See Runs and limits.

Liveness states

StateMeaning
ServingResolves and answers HTTP — the page was fetched
DormantResolves but serves nothing usable
UnresolvedDoes not resolve
OfflineServed before, but did not on the last check

The Page column on the list (hidden by default) shows this state until the page has been assessed, after which it shows what the assessment made of the page instead (Active page, Parked page, Redirects elsewhere, Inactive).

On this page