🚨
DNS 장애 사고 사례 모음
인터넷을 멈춘 대형 DNS 장애들과 교훈
DNS는 인터넷의 전화번호부이지만, 그만큼 장애 시 영향 범위가 막대합니다. 2016년 Dyn DDoS 공격부터 2021년 Facebook BGP 사고까지, 실제 대규모 DNS 장애 사례를 통해 왜 DNS 이중화와 모니터링이 필수인지 알아봅니다.
구조 다이어그램
주요 DNS/인프라 장애 타임라인 (2016-2023)
!
2016.10
Dyn DDoS (Mirai Botnet)
심각도: 최고
원인: Mirai 봇넷이 IoT 기기 10만대+를 동원하여 1.2 Tbps DDoS 공격
영향 서비스: Twitter, GitHub, Netflix, Reddit, Spotify, PayPal
지속시간: 약 6시간 (3차에 걸친 공격)
!
2019.06
Cloudflare BGP Route Leak
심각도: 높음
원인: Verizon의 소규모 ISP(DQE)가 BGP 경로를 잘못 전파하여 Cloudflare 트래픽 흡수
영향 서비스: Cloudflare, Amazon, Linode, Discord
지속시간: 약 2시간
!
2021.06
Fastly Config Error
심각도: 중간
원인: 고객 설정 변경이 소프트웨어 버그를 촉발하여 전 세계 CDN 노드의 85%가 다운
영향 서비스: Amazon, Reddit, Twitch, The New York Times, UK Gov
지속시간: 49분
!
2021.10
Facebook BGP Incident
심각도: 최고
원인: 자동화된 설정 변경이 BGP 경로를 삭제 → DNS 서버가 인터넷에서 사라짐
영향 서비스: Facebook, Instagram, WhatsApp, Messenger, Oculus
지속시간: 약 6시간
!
2022.06
Cloudflare BGP (19 DC)
심각도: 높음
원인: 네트워크 변경 작업 중 실수로 19개 데이터센터에서 BGP 세션 종료
영향 서비스: Cloudflare, Discord, Shopify, Fitbit
지속시간: 약 90분
!
2023.03
.au DNSSEC Expiry
심각도: 높음
원인: .au TLD의 DNSSEC 서명 키(KSK)가 만료되어 검증 실패 → .au 전체 도메인 접속 불가
영향 서비스: 호주 전체 .au 도메인
지속시간: 수 시간
DNS 장애 예방 체크리스트
1
다중 DNS 제공자 사용
Route 53 + Cloudflare DNS 등 2개 이상의 DNS 제공자를 설정하여 단일 장애점 제거
2
DNSSEC 키 자동 갱신 설정
KSK/ZSK 만료 알림 및 자동 로테이션 설정. .au 사태의 교훈.
3
BGP 경로 모니터링
BGP 경로 이상 감지 서비스 사용 (예: Cloudflare Radar, BGPStream). Route Leak/Hijack 방어.
4
TTL 전략 수립
평상 시 TTL 3600s, 변경 전 300s로 낮추기. 장애 시 빠른 전환 가능.
5
설정 변경 안전장치
Canary Deployment, Rollback 자동화, 변경 전 Dry-Run 검증. Facebook/Fastly 사태의 교훈.
6
DDoS 방어 계획
Anycast DNS 사용, Rate Limiting, Scrubbing Center 연동. Dyn 사태 이후 업계 표준.
핵심 포인트
•
DNS 장애의 대부분은 "사람의 설정 실수" 또는 "자동화 스크립트 오류"가 원인 — 기술적 결함보다 운영 프로세스가 핵심
•
BGP는 인터넷의 핵심 라우팅 프로토콜이지만, 인증 메커니즘이 취약 — RPKI 도입이 진행 중
•
단일 제공자에 의존하면 해당 제공자의 장애가 곧 나의 장애 — 다중화(Redundancy)는 선택이 아닌 필수
동작 흐름
1
외부 공격(DDoS) 또는 내부 설정 오류로 DNS/BGP 장애 발생
2
DNS 조회 실패 → 도메인 이름을 IP로 변환 불가
3
영향 범위 확산: 해당 DNS/CDN을 사용하는 모든 서비스가 동시 접속 불가
4
장애 원인 특정 및 복구 작업 (BGP 경로 복원, DDoS 완화, 설정 롤백 등)
5
DNS 전파 완료까지 대기 (TTL에 따라 수분~수시간 소요)
장점
- ✓ 사례 학습: 실제 장애에서 배운 교훈으로 사전 대비 가능
- ✓ 이중화 설계: 단일 장애점(SPOF) 제거로 가용성 향상
- ✓ 모니터링 강화: 장애 조기 감지로 MTTR(평균복구시간) 단축
- ✓ TTL 전략: 장애 시 빠른 DNS 전환을 위한 사전 TTL 조정
단점
- ✗ 비용 증가: 다중 DNS/CDN 제공자 사용 시 운영 비용 상승
- ✗ 복잡성 증가: 다중 제공자 간 레코드 동기화 및 장애 전환 설정 복잡
- ✗ 완전한 방어 불가: Mirai급 대규모 DDoS는 단일 서비스로 완전 방어 어려움
- ✗ BGP 의존성: DNS 자체가 정상이어도 BGP 경로 문제로 도달 불가 상황 발생
사용 사례
다중 DNS 제공자 전략 수립 (Route 53 + Cloudflare 병행)
DNS 장애 모니터링 시스템 구축 (Pingdom, UptimeRobot)
DDoS 방어 계획 수립 (Anycast, Rate Limiting, WAF)
장애 대응 플레이북 작성 (OOB 접근, 비상 연락망)