DNS-Sicherheit - Definition & Explanation

DNS is the Internet’s phone book—and at the same time one of the most frequently exploited protocols for attacks. DNS tunneling for command and control, DNS hijacking for phishing, DNS amplification for DDoS: whoever controls DNS controls network traffic. Whoever monitors DNS can detect almost any attack.

Why DNS Is a Security Problem

DNS was designed in 1983 without any security mechanisms. The protocol supports neither encryption (everything is transmitted in plain text) nor authentication (anyone can provide responses) nor integrity protection (responses can be manipulated).

The practical consequences of these design decisions are significant:

DNS responses can be forged (cache poisoning)
DNS traffic is monitored by ISPs, government agencies, and attackers
DNS is abused for command-and-control communication by malware
DNS can be used as a DDoS amplifier

DNS is ubiquitous: Almost all network communication begins with a DNS lookup—including malware that resolves its C2 server via DNS, as well as phishing domains. This makes DNS logs a goldmine for threat detection.

DNSSEC - DNS Authentication

DNSSEC (DNS Security Extensions) adds cryptographic signatures to DNS records. The zone owner signs DNS records with a private key; the resolver verifies the signature with the public key; and the chain of signatures extends from the root zone through the TLD (.de) to the domain and its subdomains. If the signature is invalid, the response is discarded.

What DNSSEC protects—and what it doesn’t

DNSSEC protects...	DNSSEC does NOT protect...
Cache poisoning: forged DNS responses are detected	Privacy: Requests remain in plain text
Man-in-the-middle: Manipulation of DNS responses is detectable	DDoS: DNSSEC responses are larger → Amplification
DNS hijacking (partially): Zone records authenticated	The DNS resolver itself

Check DNSSEC status

# Check DNSSEC response:
dig +dnssec a7.de
# → RRSIG record present → DNSSEC active
# → AD flag in response → Resolver has validated

# Test whether DNSSEC validation is active:
dig sigfail.verteiltesysteme.net +dnssec
# → SERVFAIL = DNSSEC validation works correctly

> Important: Approximately 83% of German domains do not have DNSSEC (as of 2024). DNSSEC should be activated at the registrar as soon as possible.

DNS over HTTPS (DoH) and DNS over TLS (DoT)

The Problem with Classic DNS

UDP port 53 transmits DNS traffic unencrypted. ISPs can see all DNS requests. In public Wi-Fi networks, DNS manipulation by an attacker on the network is trivial. Encrypted DNS protocols close this gap.

DNS over TLS (DoT)

DoT uses port 853 (TCP) with TLS encryption for DNS traffic. It is well-suited for communication between clients and the internal resolver and is supported by Android 9+, Windows 11, and Linux. The downside: A dedicated port makes DoT easy for firewalls to filter.

DNS over HTTPS (DoH)

DoH uses port 443 (HTTPS) and sends DNS requests via HTTP/2 or HTTP/3. Since the traffic cannot be distinguished from normal HTTPS traffic, it is virtually impossible to block. However, this is also the downside: companies have difficulty controlling DoH in the browser. DoH is supported by Firefox, Chrome, Windows, and Android.

For Businesses: Blocking DoH in Browsers

DoH in browsers bypasses the company’s internal DNS resolver and thus all DNS-based security measures. The countermeasures:

Disable the Firefox DoH policy via GPO or MDM
Control the Chrome DoH policy via GPO
Operate your own DoH/DoT resolver that all clients point to

You can set up your own DoH resolver using tools like Unbound and nginx: Unbound serves as a recursive resolver, while nginx provides an HTTPS proxy with a /dns-query endpoint. All queries run through the controlled resolver—filtering, logging, and security remain fully possible.

DNS over QUIC (DoQ)

The latest DNS protocol (RFC 9250, 2022) uses QUIC instead of TCP/UDP, making it faster and more modern. Adoption is still low.

DNS Security Solutions for Enterprises

1. Protective DNS / DNS Filtering

The basic principle: Block malicious domains before a connection is established. Known C2 server domains, reported phishing sites, malvertising, and botnet C2 are added to blocklists and blocked at the DNS level.

Commercial Solutions:

Provider	Features
Cisco Umbrella	Cloud-based, global threat intelligence
Palo Alto DNS Security	Integration with NGFW
Cloudflare Gateway	Free basic version (1.1.1.2)
NextDNS	Consumer + Business, highly configurable

Open Source / Cost-Effective Options:

Pi-hole with blocklists (for small networks)
BIND RPZ (Response Policy Zones): custom blocklists on BIND servers
Unbound with blocklists

> The BSI recommends DNS filtering as one of the most cost-effective security measures—it blocks 70–80% of all malware connections.

2. DNS Monitoring and Threat Detection

DNS traffic should be monitored for the following anomalies:

Domains queried shortly after registration (DGA indication)
Very long subdomains (DNS tunneling: aGVsbG8gd29ybGQ.evil.com)
Unusual DNS record types (TXT, NULL)
Known DGA patterns (Conficker, GameOver Zeus)
NXDOMAIN floods: many non-existent domains from a single host

SIEM rules for DNS anomalies:

# Suspicious: Subdomain longer than 50 characters
DNS_QUERY | WHERE length(subdomain) &gt; 50
         | WHERE NOT whitelist_domain(fqdn)
         → Alert: &quot;Possible DNS tunneling&quot;

# Suspicious: Many NXDOMAIN responses
DNS_RESPONSE | WHERE response_code = &quot;NXDOMAIN&quot;
             | stats count by src_ip
             | WHERE count &gt; 100 IN last 10min
             → Alert: &quot;Possible malware activity (DGA)&quot;

DNS Tunneling - Attacker's Perspective

DNS tunneling uses DNS for covert communication. DNS traffic is rarely blocked (it works even behind restrictive firewalls), rarely monitored, and UDP/TCP port 53 is open almost everywhere.

How DNS Tunneling Works

The attacker controls the DNS server for boese-domain.com
A DNS tunneling tool (iodine, dnscat2) is running on the compromised host
Data is Base64-encoded and hidden as a subdomain in DNS queries: aGVsbG8gd29ybGQ.boese-domain.com
The malicious DNS server decodes the requests and responds via DNS response
All C2 traffic runs over DNS—invisible to standard network monitoring tools

Indicators of DNS tunneling

Very long subdomains (more than 50 characters)
Many different subdomains of the same domain
Unusual DNS record types (TXT, NULL, CNAME chains)
High DNS query rate from a single host
Unusually high data volume via DNS (normally under 1 KB/s, significantly higher for tunnels)

Known tools (also for penetration testing):

iodine: IPv4-over-DNS
dnscat2: C2 over DNS
DNSExfiltrator: Data exfiltration via DNS TXT records

DNS Configuration Checklist

Resolver Configuration

No open resolver (only internal clients should be allowed to query)
Allow recursion only for internal networks
Configure rate limiting against amplification attacks
Enable DNSSEC validation (on the internal resolver)
Enable logging of all queries and forward to SIEM

Public DNS Records

SPF record present (prevent email spoofing)
DMARC record with "reject" policy
DKIM record for all email services in use
MX record only if email is actively used
DNSSEC enabled for own domain at the registrar
CAA record: only specific CAs are allowed to issue certificates
TLSA record (DANE): anchor certificate via DNS

Monitoring

Forward DNS logs to SIEM (all queries)
Alerting for long subdomains (more than 50 characters)
Alerting for numerous NXDOMAIN responses
Anomaly detection on DNS traffic
Use an external DNS monitor (BSI DNS Check, dnsviz.net)