DNS Security: The Infrastructure Layer Most Websites Never Harden

The attack surface nobody looks at

DNS is the first layer of every web interaction. When a user types yourbusiness.com into a browser, the browser makes a DNS query to resolve the domain name to an IP address before the connection to the website server even begins. This DNS resolution layer is the infrastructure that everything else depends on, and it is almost never hardened.

The typical security investment for a business website focuses on the web server layer: SSL certificates, firewall configuration, application security patches. The DNS layer, which precedes all of these in the network stack, often receives zero security attention. The domain registrar account has a password and no multifactor authentication. The DNS records have never been audited. Subdomains created for deprecated projects remain in DNS pointing at services that no longer host the intended content.

Cloudflare’s documentation on DNS security describes DNS hijacking as one of the attack vectors with the highest impact-to-effort ratio: an attacker who compromises the domain registrar account can redirect all traffic from the business’s domain (website, email, API endpoints) within minutes. The original website becomes unreachable. All visitor traffic goes to the attacker’s infrastructure.

The registrar account: the highest-risk credential most businesses don’t protect

Domain registrar accounts are arguably the most powerful credentials a business holds, they control the domain, which controls DNS, which controls website and email. Despite this, a majority of registrar accounts are protected only with a password and no multifactor authentication.

IANA’s documentation on domain registration describes the registrant’s account as the root of trust for the domain’s entire DNS configuration. A compromised registrar account allows an attacker to:

• Change the nameservers to attacker-controlled infrastructure, taking over all DNS resolution
• Transfer the domain to another registrar, potentially losing it permanently
• Modify individual DNS records to redirect website or email traffic
• Issue SSL certificates for the domain (via DNS challenge validation) to enable HTTPS phishing sites

The mitigation: enable MFA on the registrar account, use a strong unique password stored in a password manager, set the domain to lock status (transfer-lock or domain lock) which prevents unauthorised transfers, and configure registrar alerts for any changes to nameserver or domain contact information.

The subdomain audit that most businesses have never done

Subdomain takeover is a class of vulnerability that exists in the gap between DNS configuration and service provisioning. The scenario: a developer creates a subdomain staging.yourbusiness.com pointing to a Heroku application. The project ends, the Heroku dyno is deleted, but the DNS CNAME record remains. Three months later, an attacker notices the subdomain returns a 404 from Heroku, a specific error indicating the CNAME target exists but the application doesn’t. The attacker creates their own Heroku application, configures it to respond to staging.yourbusiness.com, and can now serve arbitrary content from a trusted subdomain of the business’s domain.

OWASP’s documentation on subdomain takeover categorises this as a significant web application security risk because the business’s trusted domain name and SSL certificate can be used to conduct phishing attacks against its own customers. The subdomain staging.yourbusiness.com has the business’s name in the URL and may even have a valid SSL certificate, making it visually indistinguishable from the legitimate site to many users.

The prevention is DNS hygiene: a quarterly audit of all DNS records, removing CNAME records that point to decommissioned services, and implementing a process where removing a cloud service includes a corresponding DNS record removal.

The DNS records that affect email deliverability and searchability

Several DNS records directly affect business operations beyond website availability:

SPF, DKIM, DMARC, email authentication records. Misconfigured SPF records with syntax errors or conflicting directives cause email authentication failures. A domain with a valid SPF record can send email successfully; the same domain with a broken SPF record has its emails flagged as spam. Google’s documentation on email authentication requirements specifies that bulk senders must have these configured correctly to reach Gmail inboxes.

CAA (Certification Authority Authorization) (a DNS record that specifies which certificate authorities are permitted to issue SSL certificates for the domain. Without a CAA record, any of the dozens of public CAs can issue a certificate for the domain) including through social engineering or compromised validation processes. A CAA record restricting certificate issuance to one or two specific CAs (Let’s Encrypt, Sectigo, DigiCert) prevents attackers from obtaining fraudulent certificates that could be used for HTTPS phishing.

DNAME records, redirects entire DNS subtrees and can, if misconfigured, redirect legitimate subdomains to unintended destinations. Rarely used but worth auditing for unexpected entries.

The Webxtek Studio maintenance service includes quarterly DNS audits for all client domains, reviewing all active records, identifying orphaned CNAMEs, verifying email authentication configuration, and checking registrar account security settings. The managed hosting service includes DNS management on Cloudflare infrastructure, which provides the additional benefit of Cloudflare’s DDoS protection, DNSSEC support, and real-time DNS analytics.

For SaaS and technology businesses and B2B service businesses where the domain is both the identity and the delivery infrastructure, DNS security is not optional. The visibility and accessibility that web.dev performance standards enable become irrelevant if DNS hijacking routes your visitors to someone else’s server before they can load a single byte of your content.