Lookalike domains work because a person cannot tell gooogle.com from google.com, or a Cyrillic "а" from a Latin "a", at a glance, so the safest place to stop them is before the name resolves. MITRE D3FEND names the countermeasure Homoglyph Denylisting (D3-HDL) and defines it as "Blocking DNS queries that are deceptively similar to legitimate domain names." It sits under the Isolate tactic as a child of Forward Resolution Domain Denylisting (D3-FRDDL), which blocks Outbound Internet DNS Lookup Traffic. This card explains how to build and maintain a lookalike denylist for the domains you care about, the ATT&CK techniques D3FEND relates to it, how to test it and where it falls short. It is for DNS, email security and brand protection teams; detection of lookalikes in mail and URLs is covered separately in D3-HD Homoglyph Detection.
Key takeaways
- Denylisting is the enforcement half. Homoglyph Detection finds lookalikes; Homoglyph Denylisting stops your resolvers answering for them.
- Generate, then confirm. Permutation tools produce thousands of candidate lookalikes of your domains; only the registered ones need to go on a live denylist, and the full set needs watching for new registrations.
- Punycode is what the resolver sees. An internationalised lookalike arrives as an
xn--label, so the denylist must hold the ASCII form. - D3FEND relates it to two techniques. Application Layer Protocol: DNS (T1071.004) and Dynamic Resolution (T1568), inferred through DNS traffic; the practical value is mostly against phishing and impersonation infrastructure.
- Currency is the hard part. D3FEND warns that keeping the list current is a challenge, "especially with newly registered domain entries."
D3-HDL at a glance
| Attribute | Value |
|---|---|
| D3FEND ID | D3-HDL (d3f:HomoglyphDenylisting) |
| Tactic | Isolate |
| Parent technique | Forward Resolution Domain Denylisting (D3-FRDDL), under DNS Denylisting |
| Digital artefact | Outbound Internet DNS Lookup Traffic (relation inherited from the parent: blocks) |
| Synonym | Homoglyph Blacklisting |
| D3FEND reference | University of Twente thesis: Detection of Malicious IDN Homoglyph Domains Using Active DNS Measurements |
| Where it runs | Internal resolvers, protective DNS services, secure web gateways |
| Main limitation | Covers only lookalikes of names on your reference list, and only once they are known |
How it works
D3FEND describes a resolver that "considers the domain and subdomain structure of a lookup and compares the named components to blacklisted named components." The listed components are "crafted modifications of known good domains", and the list also accounts for fonts and Unicode characters that look alike, such as zero and capital O, or lower case l and the number one.
In practice there are two kinds of lookalike, and they reach the resolver differently.
| Lookalike family | Examples of the pattern | What the resolver sees | How to generate candidates |
|---|---|---|---|
| Same-script typos and swaps | Doubled or dropped letters, transposed letters, rn for m, 0 for o, an added hyphen, a different top-level domain | Plain ASCII names | Permutation tools with typo, omission, repetition, transposition, hyphenation and TLD-swap algorithms |
| Internationalised (IDN) homoglyphs | A Cyrillic or Greek letter replacing a Latin one, or a whole label written in confusable letters from another script | An ASCII label beginning xn-- (Punycode) | Homoglyph fuzzers built on Unicode confusables data; convert each result to its xn-- form before listing |
Browsers already defend the display side. Chromium shows a label as punycode instead of Unicode when it mixes Latin, Cyrillic and Greek, when every letter belongs to a confusable set that does not match the top-level domain, or when its skeleton matches a top domain, and it can show a lookalike warning interstitial. Those protections do not cover mail clients, chat links, scripts or non-browser software, which is why a resolver-level block still adds value.
ATT&CK techniques D3FEND relates to D3-HDL
D3FEND labels these relationships as inferred and experimental, derived from the DNS traffic artefact.
| Technique | Source of relationship | Practical value of D3-HDL |
|---|---|---|
| T1071.004 Application Layer Protocol: DNS | D3FEND (inferred) | Low on its own: command and control domains rarely imitate your brand, though some imitate well-known services to blend in |
| T1568 Dynamic Resolution | D3FEND (inferred) | Low to moderate: blocks known lookalike names, not algorithmically generated ones |
| T1583.001 Acquire Infrastructure: Domains | NHI Mgmt Group view, not a D3FEND mapping | The adversary registers lookalikes in advance; listing registered permutations removes their use against your users |
| T1566.002 Phishing: Spearphishing Link | NHI Mgmt Group view, not a D3FEND mapping | The highest practical value: a click on a lookalike link fails to resolve on managed devices |
See MITRE ATT&CK T1566 Phishing and T1583 Acquire Infrastructure for the attacker side.
Where it is implemented
- Internal resolvers: lookalike entries loaded as Response Policy Zone records or local zones, alongside other denylists. The mechanics are the same as in D3-HDDL Hierarchical Domain Denylisting; list each lookalike apex and its subdomains.
- Protective DNS services: many offer a custom block list and newly registered domain categories that catch fresh lookalikes. See the Protective DNS Guide.
- Secure web gateways and mail gateways: block the same list at URL and sender level so the control holds where DNS is not involved.
- Brand monitoring: permutation and registration monitoring feeds the list. Open source tools such as dnstwist generate permutations, check which are registered, and compare page content with fuzzy hashes and screenshots with perceptual hashes.
Implementation steps
- Build the reference list: your own registered domains, login and single sign-on domains, payment and supplier portals, and the external services your staff sign in to most.
- Generate candidates: run permutation and homoglyph generation for each reference domain, across the top-level domains that matter to you, and convert IDN results to their
xn--form. - Remove what you own: exclude defensive registrations held by your organisation, and note that Chromium recommends a single HTTP 301 or 302 redirect from defensive registrations to the canonical domain.
- Confirm registration: list registered lookalikes for blocking now; keep unregistered candidates on a watch list that is rechecked on a schedule.
- Pilot in log-only mode: watch for hits for a week. A legitimate partner or regional site may sit close to your name.
- Enforce: return NXDOMAIN or a block page, and send every hit with the client address to the SIEM.
- Act on hits: a hit is a likely phishing click or a misconfiguration; check the user's mailbox and browser history, and consider takedown. See the Brand Impersonation and Lookalike Domain Takedown Playbook.
- Rollback: keep a high-precedence exemption that can release a single name quickly, with a change record.
How to verify it works
- Fixed test set: keep a small set of known lookalikes, including at least one
xn--name, on the denylist and query them from each network segment and from roaming devices. - Subdomain test: query a random subdomain of a listed lookalike; it should be blocked too.
- Freshness test: track the time from a lookalike being registered (or reported) to the block being live.
- Bypass test: confirm that clients cannot reach an outside resolver directly or through unmanaged encrypted DNS.
Metrics (examples, not standards)
| Metric | Why it matters | Example target |
|---|---|---|
| Registered lookalikes of reference domains that are blocked | Coverage | 100 per cent of confirmed malicious or unknown-owner lookalikes |
| Hours from registration or report to block | Currency, which D3FEND flags as the challenge | Within one working day |
| Hits per month and share investigated | Detection value | Every hit triaged |
| False positive exemptions per month | List quality | Trending down |
| Watch list recheck interval | Catching new registrations | Daily or weekly, depending on exposure |
Limits, bypasses and failure patterns
- Lists that stop at your own domains: attackers imitate the services your staff log in to as often as your brand. Include major identity, collaboration and payment providers in the reference list.
- Storing Unicode instead of punycode: a resolver denylist keyed on Unicode text will never match the
xn--query on the wire. - Blocking only the apex: lookalike campaigns often use hostnames such as login. or secure. under the lookalike domain; block the subdomains too.
- Unrelated but convincing domains: a domain that uses your brand plus a word ("brand-support") or a new top-level domain may not appear in permutation output. Add dictionary-based generation and newly registered domain blocking.
- Off-network devices: laptops and phones outside the corporate resolver are unprotected unless the block follows them through an endpoint agent or protective DNS.
- Treating a hit as solved: the user who clicked may already have entered credentials on another channel. Investigate and, where needed, reset credentials and revoke sessions.
Where identity fits
Most lookalike domains exist to harvest credentials: sign-in pages for single sign-on, cloud consoles and developer platforms. Blocking resolution protects managed devices, but it does not protect a password typed on an unmanaged phone. Phishing-resistant authentication bound to the real origin removes the value of the stolen credential. See D3-MFA Multi-factor Authentication.
Framework mapping
| Framework | Reference | Fit |
|---|---|---|
| NIST SP 800-53 Rev. 5 | SC-7 Boundary Protection | Blocking communication with deceptive destinations |
| NIST SP 800-53 Rev. 5 | SC-21 Secure Name/Address Resolution Service (Recursive or Caching Resolver) | The resolver tier where the control lives |
| NIST SP 800-53 Rev. 5 | SI-4 System Monitoring | Hits as detections |
| NIST CSF 2.0 | PR.IR-01 Networks and environments are protected from unauthorized logical access and usage | Enforcement |
| NIST CSF 2.0 | ID.RA-03 Internal and external threats to the organization are identified and recorded | Lookalike monitoring |
| CIS Controls v8.1 | 9.2 Use DNS Filtering Services | Direct |
| ATT&CK mitigations | M1021 Restrict Web-Based Content | Closest mitigation |
This mapping is NHI Mgmt Group's view; D3FEND does not publish it.
Related countermeasures
- Homoglyph Detection (D3-HD): finds lookalikes in mail and URLs that feed this list. See D3-HD Homoglyph Detection.
- Hierarchical Domain Denylisting (D3-HDDL): the sibling technique that blocks every subdomain of a listed domain. See D3-HDDL Hierarchical Domain Denylisting.
- Domain Name Reputation Analysis (D3-DNRA): scores lookalikes that are not yet listed. See D3-DNRA Domain Name Reputation Analysis.
- Domain Registration Takedown (D3-DRT): removes the lookalike at the registrar. See D3-DRT Domain Registration Takedown.
Practitioner checklist
- Maintain a reference list of your domains and the services your staff sign in to.
- Generate same-script and IDN permutations for each reference domain.
- Store IDN entries in their
xn--form. - Block registered lookalikes and their subdomains; watch unregistered ones.
- Exclude your own defensive registrations and redirect them to the canonical domain.
- Pilot in log-only mode, then enforce with NXDOMAIN or a block page.
- Triage every hit as a possible phishing click.
- Extend the block to roaming devices and to mail and web gateways.
Standards and references
- MITRE D3FEND: Homoglyph Denylisting (D3-HDL)
- NIST: SP 800-53 Rev. 5 Security and Privacy Controls (SC-7, SC-21)
- NIST: SP 800-81 Rev. 3 Secure Domain Name System (DNS) Deployment Guide
- IETF: RFC 3492 Punycode
- Chromium: IDN display policy
- IETF Datatracker: draft-vixie-dnsop-dns-rpz-00 DNS Response Policy Zones
- dnstwist: domain name permutation engine (project documentation)
Related NHI Mgmt Group resources: Typosquatting and Lookalike Domains Guide · Unicode Security · Domain Portfolio and Lookalike Domain Management Guide · Protective DNS Guide