DNS洪水攻撃とは?
DNS の洪水は、DNS サーバー(権限のあるネームサーバまたは再帰的な解決者)に大量の DNS クエリを送信することにより、DNS インフラストラクチャを圧倒する分散型サービス(DDoS)攻撃の一種です。 目的は、サーバーリソースを排出し、DNSサービスを利用できなくなり、ドメイン名を解決する正当なユーザーを防ぐことです。
DNS洪水攻撃の影響
DNS サーバーが圧倒的な場合:
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)
効果:
- ウェブサイトが到達できない(ウェブサーバが運用されている場合も)
- メール配信失敗(MXレコード検索失敗)
- DNSに依存するAPIやサービスが利用できなくなった
- 共有DNSインフラの担保被害
DNS 洪水攻撃の種類
直接DNSクエリフラッド
攻撃者は、高いボリュームで正当なDNSクエリを送信します。
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...
特徴:
- 有効なDNSの問い合わせ(フィルタリングにハード)
- ランダムサブドメインの多くの場合(バイパスキャッシュ)
- 分散攻撃のためにボットネットを使用する
DNS増幅攻撃
攻撃トラフィックを増幅するために再帰的なリゾルバーを爆発させる:
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の洪水
キャッシュをバイパスする非既存のドメインのクエリ:
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
ファントムドメイン攻撃
応答しないドメインの正規化:
Attacker: Queries resolver for slow/non-responsive domains
Resolver: Waits for timeout, consumes resources
Result: Resolver resource exhaustion
ランダムサブドメイン攻撃
キャッシュのヒットを避けるために、ランダムサブドメインをキューリー:
Query: abc123random.example.com
Query: xyz789random.example.com
Query: def456random.example.com
Each is unique → cache miss → authoritative query
Overwhelms authoritative nameservers
ベクトルとテクニックを攻撃する
Botnet-Driven 攻撃
Compromised devices:
- IoT devices (cameras, routers)
- Infected computers
- Hacked servers
Distributed attack:
10,000 bots × 100 queries/sec = 1 million queries/sec
##反射攻撃
Attacker spoofs victim's IP
Sends queries to many open resolvers
Resolvers respond to victim with large answers
Victim receives amplified traffic
アプリケーション層の洪水
Legitimate-looking queries
Difficult to distinguish from real traffic
May target specific resource-intensive query types
DNS 洪水攻撃の検出
初期クエリボリューム
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
高い NXDOMAIN 率
Normal: 5-10% NXDOMAIN responses
Attack: 50-90% NXDOMAIN responses (random subdomain flood)
ソースIP配布
Legitimate: Diverse source IPs, geographic spread
Attack: Concentrated sources, unusual geographic patterns
クエリパターン
Legitimate: Repetitive queries (common domains cached)
Attack: Unique queries (random strings, no cache benefit)
##応答時間劣化
Normal: < 50ms response time
Under attack: > 1000ms or timeouts
DNS 洪水攻撃の緩和
インフラレベルの防衛
####AnycastのDNS
複数の地理的な場所を横断するトラフィック:
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
特典:
- 自動負荷配分
- 地理的レジリエンス
- 攻撃トラフィックの吸収
#### 特大 DNS インフラ
Capacity: 10x normal peak traffic
Reserves: Handle sudden spikes
Auto-scaling: Add capacity during attacks
#### レート制限
# BIND rate limiting (response-rate limiting)
rate-limit {
responses-per-second 10;
window 5;
slip 2;
};
増幅攻撃を防ぐため、同じソースからの応答を制限します。
#### クエリフィルタリング
# Block ANY queries (common in amplification)
# Block excessively long queries
# Block known-malicious patterns
インドの例:
# Block ANY queries
match-query {
type ANY;
action drop;
};
DNSプロバイダレベルの防衛
####DNSSEC ## ## ## ## # ## # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # #
洪水を直接防止するわけではありませんが、DNSSEC:
- 攻撃中のキャッシュ中毒を防ぎます
- 攻撃条件下での完全性を維持
####隠しマスター構成
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ファイアウォール/IDS
Analyze queries in real-time
Block suspicious patterns
Whitelist known-good clients
Blacklist attack sources
アプリケーションレベルの保護
####応答速度制限(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;
};
};
##### キャッシュ最適化
Increase cache size to absorb repeated queries
Longer TTLs where appropriate (trade-off with agility)
Prefetch popular records
#### クエリフィルタリング
# Drop queries for non-existent zones
# Block queries from known-bad sources
# Rate-limit per-source queries
ネットワークレベルの防衛
####BGPブラックホリング
Route attack traffic to null0
Sacrifice availability to preserve infrastructure
Last resort when attack overwhelms capacity
####アップストリームISPフィルタリング
Coordinate with ISP to filter attack traffic
Source IP validation (prevent spoofing)
Traffic scrubbing centers
###DDoSマイティグレーションサービス
Cloudflare, Akamai, AWS Shield
Absorb attack traffic before reaching your servers
Global capacity to withstand large attacks
DNSレジリエンスのベストプラクティス
複数の DNS プロバイダーを使用する
Primary provider: Cloudflare
Secondary provider: AWS Route 53
If one is attacked/down, other continues serving
Different infrastructure reduces single point of failure
##DNSSECの実装
Protects against DNS spoofing/cache poisoning
Maintains integrity during attacks
Build trust even under attack conditions
モニター DNS パフォーマンス
Real-time query rates
Response times
NXDOMAIN percentages
Geographic distribution of queries
Error rates
ツール: Grafana + Prometheus, Datadog, AWS CloudWatch
##正規能力試験
Load testing: Can infrastructure handle 10x traffic?
Failover testing: Do secondary providers activate correctly?
Attack simulation: Test mitigation strategies
##Authoritative Server の無効な再帰
# BIND
recursion no;
正規ネームサーバは、再帰的なリゾルバーとして動作しない。
ゾーン転送の制限
# BIND
allow-transfer { 10.0.0.2; 10.0.0.3; }; # Only specific slaves
攻撃者がゾーン全体をダンプすることを防ぎます。
ソフトウェアの更新を維持する
Regularly update DNS server software
Patch known vulnerabilities
Subscribe to security advisories
アクティブDNS洪水攻撃への対応
即時アクション
1. 攻撃を検証する
# Check query rate
rndc status
# Check load
top
2. 有効レート制限
# BIND: Enable RRL if not already active
rndc addzone rate-limit
3. DDoSの緩和の提供者
- スクラブサービスの活性化
- 緩和ネットワークによるリダイレクトトラフィック
4. 攻撃パターンを分析
# 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. ブロック明白な攻撃源
# 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
中期経営計画
1. スケールインフラ
- より多くのネームサーバ容量を追加
- 既にない場合、キャストを介して配布
2. 増幅追加フィルタリング
- 攻撃固有のクエリパターンをブロックする
- ホワイトリストの既知のソース
3. プロバイダとのコーディネート
- ISP/ホストプロバイダ
- DNSプロバイダー
- DDoS緩和サービス
4. ドキュメント攻撃
- パケットキャプチャ
- ログイン
- トラフィックグラフ
- 法令に基づく場合
ポストアタック解析
1. 緩和の見直しの有効性
2. インフラの弱点を特定
3. インシデント対応手順のアップデート
4. コンサイダーの長期的改善(マルチプロペラDNS、大容量)
法的および報告
認証レポート
- FBI IC3 (米国): ic3.gov
- ローカルサイバー犯罪ユニット
- ISPの乱用部門
###証拠コレクション
# 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の洪水攻撃は、オンラインサービスに深刻な脅威ですが、適切なインフラ、監視、および緩和戦略により、その影響を最小限に抑えることができます。