DNS-Flooding

Was ist ein DNS-Flood-Angriff?

Ein DNS-Flood ist ein Distributed-Denial-of-Service-Angriff (DDoS), bei dem die DNS-Infrastruktur durch eine große Zahl von DNS-Abfragen an DNS-Server (autoritative Nameserver oder rekursive Resolver) überlastet wird. Ziel ist es, die Serverressourcen zu erschöpfen, den DNS-Dienst nicht verfügbar zu machen und legitime Nutzer daran zu hindern, Domainnamen aufzulösen.

Auswirkungen von DNS-Flood-Angriffen

Bei überlasteten DNS-Servern:

Normal operation:
User → DNS query → DNS server → Response → Website loads

During DNS flood:
User → DNS query → DNS server (overwhelmed, no response)
→ Website doesn't load (even though web server is fine)

• Websites sind nicht erreichbar, selbst wenn die Webserver funktionieren
• E-Mails können nicht zugestellt werden, weil MX-Einträge nicht aufgelöst werden
• APIs und Dienste, die auf DNS angewiesen sind, werden nicht verfügbar
• Geteilte DNS-Infrastruktur kann zusätzlich beeinträchtigt werden

Arten von DNS-Flood-Angriffen

Direkte DNS-Abfrageflut

Der Angreifer sendet in hoher Zahl legitime DNS-Abfragen:

Botnet → Millions of DNS queries → Target DNS server

Query examples:
example.com A
www.example.com A
random1.example.com A
random2.example.com A
...millions more...

• Gültige DNS-Abfragen, die schwer zu filtern sind
• Häufig zufällige Subdomains, um Caching zu umgehen
• Botnetze für den verteilten Angriff

DNS-Amplifikationsangriff

Dabei werden rekursive Resolver missbraucht, um den Angriffsverkehr zu verstärken:

1. Attacker sends small query to open resolver
2. Spoofs source IP as victim's IP
3. Resolver sends large response to victim
4. Attacker amplifies bandwidth 28-54x

Attacker sends: 60-byte query for TXT record (ANY query)
Resolver sends: 3000-byte response to victim
Amplification: 50x

NXDOMAIN-Flut

Abfragen für nicht vorhandene Domains umgehen den Cache:

Query: random-12345.example.com (doesn't exist)
Server must check authoritative zone every time
Cannot be cached (NXDOMAIN responses often have low TTL)
Consumes more server resources than cached responses

Phantom-Domain-Angriff

Es werden legitime Domains abgefragt, die nicht antworten:

Attacker: Queries resolver for slow/non-responsive domains
Resolver: Waits for timeout, consumes resources
Result: Resolver resource exhaustion

Angriff auf zufällige Subdomains

Zufällige Subdomains vermeiden Cache-Treffer:

Query: abc123random.example.com
Query: xyz789random.example.com
Query: def456random.example.com

Each is unique → cache miss → authoritative query
Overwhelms authoritative nameservers

Angriffsvektoren und Techniken

Botnet-gesteuerte Angriffe

Compromised devices:
IoT devices (cameras, routers)
Infected computers
Hacked servers

Distributed attack:
10,000 bots × 100 queries/sec = 1 million queries/sec

Reflexionsangriffe

Attacker spoofs victim's IP
Sends queries to many open resolvers
Resolvers respond to victim with large answers
Victim receives amplified traffic

Floods auf Anwendungsebene

Legitimate-looking queries
Difficult to distinguish from real traffic
May target specific resource-intensive query types

DNS-Flood-Angriffe erkennen

Ungewöhnliches Abfragevolumen

Normal baseline: 10,000 queries/second
During attack: 500,000+ queries/second

# Check query rate (BIND)
rndc status | grep "queries resulted"

# Analyze query logs
tail -f /var/log/named/queries.log | wc -l

Hohe NXDOMAIN-Rate

Normal: 5-10% NXDOMAIN responses
Attack: 50-90% NXDOMAIN responses (random subdomain flood)

Verteilung der Quell-IP-Adressen

Legitimate: Diverse source IPs, geographic spread
Attack: Concentrated sources, unusual geographic patterns

Abfragemuster

Legitimate: Repetitive queries (common domains cached)
Attack: Unique queries (random strings, no cache benefit)

Verschlechterung der Antwortzeit

Normal: < 50ms response time
Under attack: > 1000ms or timeouts

DNS-Flood-Angriffe eindämmen

Schutzmaßnahmen auf Infrastrukturebene

#### Anycast-DNS

Verteilen Sie den Datenverkehr über mehrere geografische Standorte:

Single IP address (e.g., 1.2.3.4) announced from multiple locations
Attack traffic automatically routed to nearest server
Load distributed across global network
Harder to overwhelm all locations simultaneously

• Automatische Lastverteilung
• Geografische Ausfallsicherheit
• Aufnahme und Verteilung des Angriffsverkehrs

#### Überdimensionierte DNS-Infrastruktur

Capacity: 10x normal peak traffic
Reserves: Handle sudden spikes
Auto-scaling: Add capacity during attacks

#### Ratenbegrenzung

# BIND rate limiting (response-rate limiting)
rate-limit {
    responses-per-second 10;
    window 5;
    slip 2;
};

Begrenzen Sie Antworten derselben Quelle, um Amplifikationsangriffe zu verhindern.

#### Abfragefilterung

# Block ANY queries (common in amplification)
# Block excessively long queries
# Block known-malicious patterns

# Block ANY queries
match-query {
    type ANY;
    action drop;
};

Schutzmaßnahmen auf DNS-Provider-Ebene

#### DNSSEC

DNSSEC verhindert Floods zwar nicht unmittelbar, aber:

• verhindert Cache-Poisoning während eines Angriffs
• bewahrt die Integrität auch unter Angriffsbedingungen

#### Konfiguration eines Hidden Masters

Master server (hidden):    10.0.0.1 (not publicly known)
Slave servers (public):    ns1.example.com, ns2.example.com

Attackers target slaves
Master remains operational
Can quickly update slaves if needed

#### DNS-Firewall und IDS

Analyze queries in real-time
Block suspicious patterns
Whitelist known-good clients
Blacklist attack sources

Schutzmaßnahmen auf Anwendungsebene

#### Response-Rate-Limiting (RRL)

Limit identical responses to same client
Prevents amplification attacks
Slip mode: Occasionally allow queries through (to not break legitimate recursive resolvers)

options {
    rate-limit {
        responses-per-second 5;
        referrals-per-second 5;
        nodata-per-second 5;
        nxdomains-per-second 5;
        errors-per-second 5;
        window 5;
    };
};

#### Cache-Optimierung

Increase cache size to absorb repeated queries
Longer TTLs where appropriate (trade-off with agility)
Prefetch popular records

#### Abfragefilterung

# Drop queries for non-existent zones
# Block queries from known-bad sources
# Rate-limit per-source queries

Schutzmaßnahmen auf Netzwerkebene

#### BGP-Blackholing

Route attack traffic to null0
Sacrifice availability to preserve infrastructure
Last resort when attack overwhelms capacity

#### Filterung durch den Upstream-Provider

Coordinate with ISP to filter attack traffic
Source IP validation (prevent spoofing)
Traffic scrubbing centers

#### DDoS-Abwehrdienste

Cloudflare, Akamai, AWS Shield
Absorb attack traffic before reaching your servers
Global capacity to withstand large attacks

Bewährte Vorgehensweisen für DNS-Resilienz

Mehrere DNS-Anbieter verwenden

Primary provider: Cloudflare
Secondary provider: AWS Route 53

If one is attacked/down, other continues serving
Different infrastructure reduces single point of failure

DNSSEC implementieren

Protects against DNS spoofing/cache poisoning
Maintains integrity during attacks
Build trust even under attack conditions

DNS-Leistung überwachen

Real-time query rates
Response times
NXDOMAIN percentages
Geographic distribution of queries
Error rates

Regelmäßige Kapazitätstests

Load testing: Can infrastructure handle 10x traffic?
Failover testing: Do secondary providers activate correctly?
Attack simulation: Test mitigation strategies

Rekursion auf autoritativen Servern deaktivieren

# BIND
recursion no;

Autoritative Nameserver sollten nicht als rekursive Resolver arbeiten.

Zonentransfers einschränken

# BIND
allow-transfer { 10.0.0.2; 10.0.0.3; };  # Only specific slaves

Verhindern Sie, dass Angreifer die gesamte Zone auslesen.

Software aktuell halten

Regularly update DNS server software
Patch known vulnerabilities
Subscribe to security advisories

Auf einen aktiven DNS-Flood-Angriff reagieren

Sofortmaßnahmen

1. Prüfen, ob ein Angriff stattfindet

# Check query rate

   rndc status

   # Check load
   top

2. Ratenbegrenzung aktivieren

# BIND: Enable RRL if not already active

   rndc addzone rate-limit

3. DDoS-Abwehranbieter kontaktieren

- Scrubbing-Dienste aktivieren

- Datenverkehr über das Abwehrnetz umleiten

4. Angriffsmuster analysieren

# Top query types

   grep "query" /var/log/named/queries.log | awk '{print $6}' | sort | uniq -c | sort -rn | head -20

   # Top queried domains
   grep "query" /var/log/named/queries.log | awk '{print $7}' | sort | uniq -c | sort -rn | head -20

5. Offensichtliche Angriffsquellen blockieren

# Identify top source IPs

   grep "query" /var/log/named/queries.log | awk '{print $5}' | cut -d# -f1 | sort | uniq -c | sort -rn | head -50

   # Block at firewall
   iptables -A INPUT -s ATTACKER_IP -j DROP

Mittelfristige Maßnahmen

1. Infrastruktur skalieren

- Zusätzliche Nameserver-Kapazität bereitstellen

- Den Datenverkehr per Anycast verteilen, sofern noch nicht geschehen

2. Zusätzliche Filter einrichten

- Abfragemuster blockieren, die für den Angriff charakteristisch sind

- Bekannte legitime Quellen auf eine Whitelist setzen

3. Mit den Anbietern koordinieren

- ISP/Hosting-Anbieter

- DNS-Anbieter

- DDoS-Abwehrdienst

4. Angriff dokumentieren

- Paketmitschnitte

- Protokolle

- Verkehrsgrafiken

- Für die Analyse nach dem Vorfall und rechtliche Zwecke

Analyse nach dem Angriff

1. Wirksamkeit der Abwehrmaßnahmen prüfen

2. Schwachstellen der Infrastruktur identifizieren

3. Verfahren zur Reaktion auf Vorfälle aktualisieren

4. Langfristige Verbesserungen prüfen (Multi-Provider-DNS, größere Kapazität)

Rechtliches und Meldung

Behörden informieren

• FBI IC3 (U.S.): ic3.gov
• Lokale Cybercrime-Einheiten
• Abuse-Abteilungen von ISPs

Beweise sichern

# Packet captures
tcpdump -i eth0 -w dns-attack.pcap port 53

# Full query logs
tar -czf attack-logs-$(date +%Y%m%d).tar.gz /var/log/named/

# Traffic graphs/screenshots
# System resource usage

DNS-Floods sind eine ernsthafte Bedrohung für Onlinedienste. Mit geeigneter Infrastruktur, Überwachung und Abwehrstrategien lassen sich ihre Auswirkungen jedoch begrenzen.