How DNS Works and How Attackers Use It Against You

Part 1: How DNS Works (No Technical Background Required)

Every website has an address. Not the name you type into the browser, but a numerical address that computers use to find each other on the internet. The domain name system, DNS, is what connects the name you know to the address the computer needs.

Think of it like a phone book. You look up a person's name and get their phone number. DNS does the same thing: you type yourbank.com, and DNS looks up the number (called an IP address) that tells your browser where to go.

This lookup happens every single time you visit a website. Your browser asks a DNS server, "Where is yourbank.com?" and the server responds with something like "It's at 198.51.100.42." Your browser then connects to that address and loads the page.

You never see this process. It happens in milliseconds, behind the scenes, before anything appears on your screen. But every website visit starts with a DNS lookup. And that is where the problem begins.

What makes DNS vulnerable

The DNS system was built in the 1980s. It was designed for a small, trusted network of researchers. Security was not a consideration. The fundamental assumption was that if a DNS server gives you an answer, that answer is correct. There is no built-in way to verify that the answer came from a legitimate source or that it has not been tampered with.

This means that if someone can interfere with the DNS lookup process, they can send your browser to a completely different destination without your knowledge. You type yourbank.com, your browser asks for the address, but the answer it receives points to an attacker's server instead of the real one. The page that loads looks identical to your bank's login page. You enter your credentials. The attacker captures them.

You never left your browser. You typed the correct address. The padlock icon might even be showing. But you were never on your bank's website.

How phishing exploits DNS

Attackers do not need to hack DNS servers to exploit this system. The most common approach is simpler: they register a domain name that looks like yours.

If your business is acmecorp.com, an attacker registers acmecorp-login.com or acrnecorp.com (with an 'r' and 'n' that look like 'm' in many fonts). They set up DNS records pointing to their server, deploy a cloned version of your login page, and start sending phishing emails with links to the fake domain.

From the victim's perspective, they clicked a link, saw a familiar-looking page, and entered their password. The DNS system did exactly what it was supposed to do. It resolved the domain name to an IP address. The problem is that the domain name itself was a forgery, and DNS has no way to know or care about that.

This is the core of DNS-based phishing: the system works as designed, but it makes no judgment about whether a domain name is legitimate or deceptive.

Part 2: The Technical Details

DNS resolution process

When you enter a URL, your operating system checks its local DNS cache first. If the domain was recently resolved, the cached answer is used without any network request. If not, the query goes to a recursive resolver, typically operated by your ISP or a public service like Cloudflare (1.1.1.1) or Google (8.8.8.8).

The recursive resolver checks its own cache. On a miss, it begins the resolution process from the root of the DNS hierarchy:

1. The resolver queries a root nameserver (there are 13 root server clusters worldwide). The root server responds with the address of the TLD (top-level domain) nameserver for .com.
2. The resolver queries the .com TLD nameserver, which responds with the authoritative nameservers for the specific domain (for example, ns1.example.com).
3. The resolver queries the authoritative nameserver, which returns the final IP address (the A record).

The resolver caches this answer for the duration specified by the TTL (Time to Live) value in the DNS record, then returns it to your browser. Total time: typically 20 to 100 milliseconds for an uncached lookup.

DNS record types relevant to phishing

A records map a domain to an IPv4 address. This is the most basic record type and is what your browser needs to connect to a web server. An attacker who registers a lookalike domain creates A records pointing to their own infrastructure.

MX records specify which servers handle email for a domain. When an attacker configures MX records on a lookalike domain, that domain can receive email. This enables business email compromise (BEC) attacks where the attacker sends invoices or wire transfer requests from an address like cfo@acrnecorp.com. It also allows the attacker to intercept replies sent to the fake domain by confused recipients.

TXT records are used for SPF (Sender Policy Framework), which specifies which servers are authorized to send email on behalf of a domain. Attackers who control a lookalike domain can set SPF records that authorize their own mail servers, making their phishing emails pass SPF validation.

NS records delegate authority for a domain to specific nameservers. Attackers often use commodity DNS hosting (Cloudflare, AWS Route53) or bulletproof hosting providers. Examining the NS records of a suspicious domain can reveal shared infrastructure across multiple phishing campaigns.

DNS-based attack techniques

Typosquatting registers misspelled variants of a target domain. Character substitution, omission, insertion, and adjacent-key errors are generated algorithmically. For an 8-character domain, over 10,000 permutations are possible. PhishFence generates these variants automatically for every domain you monitor, checks which ones are registered, and alerts you when new ones appear.

Homoglyph attacks use characters from non-Latin scripts that are visually identical to ASCII letters. The Cyrillic letter 'a' (U+0430) is indistinguishable from the Latin 'a' (U+0061) in most fonts, but they are different Unicode code points. A domain name composed entirely of Cyrillic characters that look Latin will resolve to a completely different destination. Internationalized Domain Names (IDN) encode these as Punycode (e.g., xn-- prefix), but many browsers display the Unicode version in the address bar, making detection difficult for users. PhishFence specifically scans for Cyrillic, Greek, and other Unicode substitutions of your domain name, converting each variant to its Punycode-encoded form and checking whether it has been registered.

DNS cache poisoning is a more sophisticated attack where the attacker injects false records into a resolver's cache. If successful, every user who queries that resolver for the target domain will receive the attacker's IP address instead of the legitimate one. DNSSEC (DNS Security Extensions) was designed to prevent this by adding cryptographic signatures to DNS responses, but adoption remains incomplete. As of 2026, many domains still do not sign their zones, and many resolvers do not validate signatures.

DNS rebinding exploits the gap between DNS resolution and HTTP requests. The attacker's domain initially resolves to a public IP. After the browser has established a connection and the DNS TTL expires, the domain resolves to an internal IP address (e.g., 192.168.1.1). The browser, still believing it is communicating with the original domain, sends requests to the internal network. This allows the attacker to bypass firewalls and access internal services.

Detection signals in DNS

Monitoring DNS data provides several indicators that a domain may be part of a phishing operation:

Registration age. Domains registered within the last 30 days that are already serving HTTP content with login forms are highly suspicious. Legitimate businesses rarely deploy credential-collecting pages on newly registered domains.

Nameserver patterns. If a suspicious domain uses the same nameservers as your legitimate domain, it may have been registered by the same organization (a defensive registration) rather than an attacker. PhishFence automatically detects this and skips domains that share your nameservers.

MX record presence. A lookalike domain with MX records configured is more dangerous than one without. MX records indicate that the attacker intends to send or receive email using the fake domain, which enables email-based phishing and BEC attacks.

Certificate issuance. When an attacker requests an SSL certificate for a lookalike domain, that issuance is recorded in Certificate Transparency logs. Monitoring these logs for your brand name provides early warning, often before the phishing page is deployed.

Protecting your domain

DMARC, SPF, and DKIM prevent attackers from sending email that impersonates your exact domain. They do not prevent attackers from sending email from a lookalike domain, but they ensure that email claiming to come directly from your domain is authenticated.

DNSSEC signs your DNS zone so that resolvers can verify the authenticity of responses. This prevents cache poisoning attacks against your domain but does not protect against lookalike registrations.

Continuous domain monitoring detects when lookalike domains are registered, when they begin resolving to IP addresses, when they obtain SSL certificates, and when they start serving content. This is the layer that catches the attack before it reaches your customers, and it is the problem PhishFence is built to solve.