web-cp.net

"open source web hosting control panel"

← Back to Blog
: DNSSEC, Zone Hardening and DNS Hijacking Prevention in Web-CP-Managed Environments

: DNSSEC, Zone Hardening and DNS Hijacking Prevention in Web-CP-Managed Environments

2026-05-10 · Nathaniel Brooks Techno Blog

DNS is the infrastructure layer that every other service depends on. A web server can be hardened to a high standard; a mail stack can be fully authenticated; a database can be access-controlled and encrypted at rest. None of it matters if the DNS that maps domain names to those resources can be poisoned, hijacked, or manipulated. An attacker who controls DNS controls everything.

In a Web-CP-managed hosting environment, DNS is handled through BIND, configured via Web-CP's zone templates and domain control panel. The default configuration is functional but not hardened. This article covers the security controls that convert a functional DNS setup into a defensible one: DNSSEC signing, zone transfer restrictions, BIND configuration hardening, and the operational procedures that prevent social engineering attacks targeting domain registrars.

The DNS Threat Model for Hosted Domains

Understanding which attacks are realistic in a hosting context shapes the hardening priorities.

Cache poisoning. An attacker who can inject fraudulent records into a recursive resolver's cache can redirect traffic for any domain that resolver serves — without touching the authoritative nameserver. Cache poisoning was largely mitigated by source port randomization (RFC 5452) and 0x20 encoding, but the attack surface remains. DNSSEC eliminates it by making spoofed records cryptographically verifiable as invalid.

Zone transfer attacks. If BIND is configured to allow unrestricted zone transfers (AXFR), any client that connects to port 53 can retrieve the complete zone file for any domain hosted on the server. This exposes every hostname, IP address, MX record, and service endpoint in the zone — a complete map of the hosting environment's internal structure.

Registrar account compromise. The most common DNS attack against production domains is not technical — it is social engineering at the registrar level. An attacker who gains access to the registrar account for a domain can change the authoritative nameservers, redirecting all DNS resolution away from the legitimate hosting environment within 48 hours of TTL expiration. DNSSEC provides partial protection here through the DS record chain of trust, but registrar account security is the primary control.

Subdomain takeover. A DNS record that points to a cloud service that no longer exists (a decommissioned S3 bucket, an expired CDN configuration, a removed Heroku app) can be claimed by an attacker who provisions a new resource at the same location. The DNS record remains valid and now points to attacker-controlled infrastructure.

DNSSEC — Cryptographic Authentication for DNS Responses

DNSSEC adds cryptographic signatures to DNS responses, allowing resolvers to verify that the data they receive is authentic and unmodified. Implementation requires generating key pairs at the zone level and publishing the public keys in the zone itself and in the parent zone (via the registrar's DS record interface).

Key Types

DNSSEC uses two key types:

  • KSK (Key Signing Key) — signs the DNSKEY record set; a long-lived key whose public key is published as a DS record in the parent zone

  • ZSK (Zone Signing Key) — signs all other record sets in the zone; rotated more frequently (every 30–90 days) to limit exposure

Generating Keys and Signing a Zone

bash

# Generate KSK — algorithm 13 (ECDSAP256SHA256) is the current recommendation
dnssec-keygen -a ECDSAP256SHA256 -b 256 -n ZONE -f KSK yourdomain.com

# Generate ZSK
dnssec-keygen -a ECDSAP256SHA256 -b 256 -n ZONE yourdomain.com

# The above generates key files in the current directory:
# Kyourdomain.com.+013+NNNNN.key  (public key)
# Kyourdomain.com.+013+NNNNN.private  (private key)
# Two pairs: one KSK (with -f KSK flag) and one ZSK

# Include keys in zone file
cat Kyourdomain.com.+013+*.key >> /etc/bind/zones/yourdomain.com.zone

# Sign the zone
dnssec-signzone \
    -A \
    -3 $(head -c 1000 /dev/random | sha1sum | cut -b 1-16) \
    -N INCREMENT \
    -o yourdomain.com \
    -t \
    /etc/bind/zones/yourdomain.com.zone

# Output: yourdomain.com.zone.signed — use this as the active zone file

BIND configuration to serve the signed zone:

// /etc/bind/named.conf.local
zone "yourdomain.com" {
    type master;
    file "/etc/bind/zones/yourdomain.com.zone.signed";
    allow-transfer { none; };     // Zone transfer restriction — covered below
    auto-dnssec maintain;         // Automatic DNSSEC maintenance
    inline-signing yes;           // Automatic re-signing on zone changes
    key-directory "/etc/bind/keys/yourdomain.com";
};

With inline-signing yes and auto-dnssec maintain, BIND handles re-signing automatically when records are updated and when ZSK rotation is scheduled. This eliminates the operational burden of manual re-signing that made early DNSSEC deployments fragile.

Publishing the DS Record

After signing the zone, extract the DS record from the KSK public key file:

bash

# Generate DS record from KSK
dnssec-dsfromkey -a SHA-256 Kyourdomain.com.+013+NNNNN.key

# Output format:
# yourdomain.com. IN DS NNNNN 13 2 [hash]

Submit this DS record to the domain registrar through their DNSSEC management interface. The registrar publishes it in the parent zone (.com, .net, etc.), completing the chain of trust from the root to the domain.

Verification:

bash

# Verify DNSSEC chain of trust
dig yourdomain.com +dnssec +multi

# Check for the AD (Authentic Data) flag in the response — its presence
# indicates the resolver has validated the DNSSEC signature chain

# Validate DS record in parent zone
dig yourdomain.com DS +short

# Full chain validation
delv @8.8.8.8 yourdomain.com A +multiline +trust

Zone Transfer Restrictions

BIND's default configuration in many installations allows unrestricted zone transfers (AXFR). This should be the first thing changed after installation.

// /etc/bind/named.conf.options
options {
    directory "/var/cache/bind";

    // Disable recursive resolution — authoritative-only server
    recursion no;

    // Disable zone transfers globally
    allow-transfer { none; };

    // Disable DNS query logging of sensitive record types
    // (enabled selectively for debugging only)

    // Bind only to specific interfaces
    listen-on { 127.0.0.1; 203.0.113.42; };
    listen-on-v6 { ::1; };

    // Disable version string disclosure
    version "not available";

    // Limit response size to prevent amplification attacks
    max-udp-size 4096;
};

If zone transfers are required for secondary nameserver synchronization, restrict them to the specific secondary nameserver IP:

// Per-zone transfer restriction
zone "yourdomain.com" {
    type master;
    file "/etc/bind/zones/yourdomain.com.zone.signed";
    allow-transfer { 203.0.113.99; };    // Secondary nameserver IP only
    also-notify { 203.0.113.99; };
};

For environments with multiple secondary nameservers, define an ACL:

// Named ACL for secondary nameservers
acl secondary-nameservers {
    203.0.113.99;
    203.0.114.55;
};

zone "yourdomain.com" {
    allow-transfer { secondary-nameservers; };
    also-notify { secondary-nameservers; };
};

BIND Process Hardening

The BIND daemon (named) runs as the bind or named user on most Linux distributions. Additional process-level hardening reduces the impact of a BIND vulnerability:

bash

# Verify BIND runs as non-root
ps aux | grep named
# Should show: bind  or  named  (not root)

# Restrict BIND's filesystem access using chroot
# Most distributions support this via the bind9 package's chroot option
# Debian/Ubuntu:
mkdir -p /var/lib/named/{dev,etc,var/cache/bind,var/run/named}
mount --bind /etc/bind /var/lib/named/etc/bind
# Configure /etc/default/bind9: OPTIONS="-u bind -t /var/lib/named"

AppArmor profile for BIND (Ubuntu/Debian):

# /etc/apparmor.d/usr.sbin.named
/usr/sbin/named {
    # Allow reading zone files
    /etc/bind/** r,
    /var/cache/bind/** rw,

    # Deny writes outside designated directories
    deny /etc/** w,
    deny /usr/** w,

    # Network access
    network inet stream,
    network inet dgram,
    network inet6 stream,
    network inet6 dgram,
}

Subdomain Takeover Prevention

Subdomain takeover occurs when a DNS record points to an external service that has been decommissioned. The record remains in DNS; the external resource is now claimable by an attacker.

Audit CNAME and A records pointing to external services:

bash

# Extract all CNAME records from zone file
grep -i "CNAME" /etc/bind/zones/yourdomain.com.zone | awk '{print $1, $NF}'

# For each CNAME target, verify the target still resolves to the intended resource
while read cname target; do
    echo "Checking $cname -> $target"
    dig $target A +short
done < cname_list.txt

Records commonly involved in subdomain takeover:

Service typeRisk indicatorAWS S3CNAME to *.s3.amazonaws.com — bucket deletedGitHub PagesCNAME to *.github.io — repository deletedHerokuCNAME to *.herokuapp.com — app decommissionedAzureCNAME to *.azurewebsites.net — app service removedShopifyCNAME to shops.myshopify.com — store closed

A quarterly audit of CNAME records against active service deployments is the operational control. Automate it by maintaining a mapping of DNS records to service resources and verifying that each mapping remains valid.

Registrar-Level Controls — The Social Engineering Layer

The most reliable DNS attack against production domains does not touch the nameserver. It targets the registrar account. Controls at this level are administrative rather than technical:

  • Enable registrar lock (transfer lock): All major registrars offer a domain lock that prevents unauthorized transfers. Verify it is enabled for all production domains. Many registrars display lock status in the domain management interface.

  • Enable WHOIS privacy or redact contact information: Publicly visible registrar contact details are the starting point for social engineering attacks targeting account recovery processes.

  • Use a dedicated registrar account email address: The email account used for domain registrar login should not be used for other purposes, should have a strong unique password, and should have hardware-token MFA enabled.

  • Register critical domains with a registrar that supports DNSSEC DS record management and provides account-level security logging.

DNSSEC provides a partial defense at the nameserver level — an attacker who changes the authoritative nameserver via the registrar cannot serve DNSSEC-signed responses for the zone unless they also have the private keys. Resolvers that validate DNSSEC will refuse to resolve the domain. This protects DNSSEC-aware resolvers but not those that do not validate — which is still a significant proportion of global resolvers.

The correct control is preventing registrar account compromise in the first place, with DNSSEC as the second line of defense that limits the blast radius if it occurs.

Integration with Web-CP's Zone Management

Web-CP's DNS editor operates on zone files managed by the underlying BIND instance. The controls above — DNSSEC signing, transfer restrictions, BIND hardening — are applied at the server level and persist across zone edits made through the panel. This means hardening needs to be applied once, to the BIND configuration, and does not need to be re-applied when tenants make DNS changes through their domain control panels.

The practical integration points are:

  • Zone file location: Web-CP writes zone files to the directory specified in BIND's configuration. Ensure this directory is included in the DNSSEC key directory and re-signing automation.

  • Zone change hooks: When a tenant modifies DNS records through the domain control panel, the zone file is updated and BIND is reloaded. With inline-signing yes, BIND automatically re-signs the updated zone on reload.

  • Template management: Web-CP's zone template (configurable through the server control panel) defines the default records added to new domains. Include SOA settings that reflect appropriate TTLs for the security posture — lower TTLs reduce the window during which a poisoned or hijacked record remains in cache; higher TTLs reduce nameserver query load. 300–900 seconds for A and CNAME records is a reasonable default for hosted domains.

DNS security is infrastructure-level work. It is invisible when it functions correctly and catastrophic when it fails. The controls above are not optional features for risk-sensitive environments — they are the baseline that every managed hosting environment should operate from.