cloudflare2026년 7월 28일

자연재해와 정부 개입: 2026년 2분기 주요 인터넷 장애 사건 분석 (새 탭에서 열림)

인터넷 장애는 자연재해·정전 같은 물리적 사건부터 정부의 의도적 차단, 클라우드 인프라 손상, DNSSEC 설정 오류까지 다양한 원인으로 발생하며, 서로 다른 원인도 사용자에게는 비슷한 “연결 불가”로 나타난다. Cloudflare Radar의 Q2 2026 분석은 이란의 88일 인터넷 차단 종료, 괌 태풍, 수단·이라크의 시험 기간 차단, 독일 `.de` 도메인 장애 등을 통해 인터넷의 취약성과 동시에 높은 복원력을 보여준다. 다만 이 글은 모든 이상 현상이 아니라 확인된 주요 장애 사례를 다룬다. ### 자연재해와 정전이 네트워크에 미친 영향 - **괌의 슈퍼태풍 신라쿠** - 4월 중순 태풍이 괌 북쪽을 지나가며 열대폭풍급 강풍과 광범위한 정전을 일으켰다. - 전력과 수도 시스템이 영향을 받으면서 4월 13~14일 인터넷 트래픽이 예상치보다 최대 80% 감소했다. - 섬이 태풍의 직접적인 타격을 피했음에도 디지털 연결성이 크게 흔들렸다. - **베네수엘라 지진** - 6월 24일 북부 베네수엘라에서 규모 7.5 지진과 추가 지진이 연이어 발생했다. - 지진 발생 시점에 HTTP 전송 바이트가 급격히 감소했으며, Fibex Telecom, CANTV, VNET 등 주요 ISP에서 동일한 현상이 관측됐다. - 특히 약 160만 명의 사용자를 보유한 것으로 추정되는 Fibex Telecom에서 감소가 뚜렷했다. - **탄자니아 정전** - 6월 27일 발생한 정전으로 인터넷 트래픽이 최소 5시간 동안 급락했다. - 원인은 정부의 의도적 차단이 아니라 전력 인프라 장애였지만, 사용자에게 나타난 결과는 통신과 뉴스 접근이 불가능해지는 등 과거의 국가적 차단과 유사했다. - 서로 다른 사건도 데이터상으로는 “트래픽의 급격한 소실”이라는 비슷한 패턴을 남긴다. - 이러한 사례는 전력 공급, 라우팅 경로, 물리적 회선의 중복성을 확보해야 인터넷이 외부 충격을 견딜 수 있음을 보여준다. ### 정부 정책과 지정학적 갈등에 따른 접속 제한 - **이란의 인터넷 복구** - 2월 28일부터 이어진 약 88일간의 전국적 인터넷 차단이 5월 26일부터 점진적으로 해제되기 시작했다. - 5월 27일 트래픽은 차단 전의 약 40%까지 회복됐고, 이후 최대 90%까지 상승한 뒤 약 59% 수준으로 안정됐다. - 완전한 정상화라기보다 최근 차단 이전 수준에 가까운 부분적 복구로 평가된다. - 2026년 월드컵 분석에서도 이란의 트래픽은 경기 일정이 아니라 차단과 복구의 극적인 대비에 의해 좌우됐다. - **중동 분쟁과 AWS 인프라 손상** - UAE의 AWS `me-central-1` 리전 트래픽은 계속 낮은 수준을 유지했다. - 드론 공격으로 UAE와 바레인의 데이터센터 시설이 물리적 피해를 입었고, AWS는 UAE 리전이 고객 애플리케이션을 안정적으로 지원하지 못한다고 밝혔다. - 이는 네트워크 자체의 장애가 아니라 데이터센터 손상이 해당 리전에 호스팅된 웹사이트와 애플리케이션에 영향을 준 사례다. - **시험 기간의 국가 인터넷 차단** - 이라크에서는 6월 2일, 11일, 28일 세 차례 차단이 발생했으며 각각 약 90분간 지속됐다. - 수단에서는 4월 13~23일 사이 열 차례 차단이 시행됐고, 매번 약 3.5시간 동안 이어졌다. - 두 국가 모두 국가시험 부정행위를 막기 위해 시험 시간에 맞춰 접속을 차단했다. - 정부는 국가 인터넷을 완전히 끄거나, 속도를 낮추거나, 일부 사용자에게만 재개하는 등 정책적으로 연결성을 통제할 수 있다. ### DNSSEC 오류로 발생한 독일 `.de` 도메인 장애 - 5월 5일 독일 국가 코드 도메인 `.de`를 관리하는 DENIC의 DNSSEC 키 교체 과정에서 잘못된 서명이 생성됐다. - DNSSEC 검증 리졸버는 서명이 현재 공개된 키와 일치하지 않으면 DNS 응답을 위조나 변조로 간주한다. - 그 결과 전 세계 검증 리졸버가 `.de` 도메인 요청을 거부하고 `SERVFAIL` 오류를 반환했다. - 장애는 5월 6일 23:15 UTC에 정상화됐다. - 장애 중 `.de` 질의량이 오히려 증가했는데, 실패한 응답은 캐시에 저장되지 않아 사용자의 재시도와 반복 조회가 늘어났기 때문이다. - 사용자는 암호화 서명 문제를 직접 인식하기보다 독일 도메인의 웹사이트와 서비스가 갑자기 열리지 않는 현상으로 경험했다. ### 해저 케이블과 지역 인프라의 취약성 - 세인트루시아에서는 해저 케이블 절단이 지역 인터넷 연결을 약화시켰다. - 이 사건은 특정 국가나 지역의 국제 연결이 제한된 수의 물리적 케이블에 의존할 경우, 단일 절단만으로도 사용자 접속이 크게 영향을 받을 수 있음을 보여준다. - DNSSEC 장애와 케이블 절단은 원인은 다르지만, 인터넷 서비스가 정상적으로 보이기 위해서는 암호화 검증 체계와 물리적 전송 경로가 모두 안정적으로 운영되어야 한다는 점을 공통적으로 드러낸다. 인터넷 회복력을 높이려면 전력·라우팅·해저 케이블·데이터센터의 중복성을 확보하고, DNSSEC 키 교체 같은 정기 유지보수에는 철저한 검증 절차를 적용해야 한다. 또한 정부와 사업자가 연결성을 정책적으로 차단할 수 있는 만큼, 장애 원인이 기술적 고장인지 의도적 차단인지 구분해 모니터링하는 것도 중요하다.

dnssecawscloudflare-radarinternet-infrastructure+3

cloudflare2026년 7월 14일

잘못된 DNSSEC 롤오버로 .AL이 다운됐다. 이제 1.1.1.1이 검증 우회 시점을 알려준다 (새 탭에서 열림)

2026년 7월 3일, 알바니아의 .AL 운영자가 DNSSEC 키 롤오버를 잘못 수행해 루트 영역의 DS 레코드와 실제 DNSKEY가 불일치했고, 검증하는 DNS 리졸버에서 .AL 전체가 장애를 겪었다. Cloudflare는 임시로 Negative Trust Anchor(NTA)를 적용해 접속을 복구했지만 DNSSEC 검증을 우회해야 했다. 이번에는 응답에 Extended DNS Error(EDE) 코드 33을 함께 반환해, 클라이언트가 해당 응답이 NTA 때문에 검증되지 않았음을 알 수 있도록 했다. ### .AL DNSSEC 장애의 발생 과정 - DNSSEC는 루트 영역의 DS 레코드에서 TLD의 DNSKEY로 이어지는 신뢰 체인을 구성한다. - 14:15 UTC경 .AL 운영자가 새 DNSKEY를 게시하고 기존 키를 제거했다. - 루트 영역의 DS 레코드는 여전히 기존 키 `id=26319`를 가리키고 있었다. - 리졸버는 일치하는 DNSKEY를 찾지 못해 검증에 실패했다. - 17:00 UTC경 새 DNSKEY까지 제거되면서 .AL 영역에 DNSKEY가 전혀 남지 않았다. - 19:15 UTC경 루트 영역에서 .AL의 DS 레코드를 제거하자 검증 대상이 사라져 DNS 조회가 복구됐다. - 게시 시점에도 .AL은 서명되지 않은 상태였으며, 모든 .AL 도메인은 DNSSEC 보호를 사용할 수 없었다. ### 장애가 .AL 전체로 확산된 이유 - .AL TLD 자체의 DNSSEC 신뢰 체인이 끊어지면 그 하위의 모든 도메인도 검증할 수 없다. - 도메인이 어디에 호스팅되어 있거나 어떤 권위 DNS 서버를 사용하든, 검증 리졸버는 DNSSEC 실패를 감지하면 응답 대신 `SERVFAIL`을 반환한다. - 캐시된 레코드가 만료될수록 재검증 요청이 늘어나 `SERVFAIL` 비율이 상승했다. - Cloudflare 1.1.1.1은 17:15 UTC에 NTA를 배포한 뒤 정상 응답을 제공하면서 장애가 급격히 완화됐다. ### Negative Trust Anchor를 통한 복구 - RFC 7646의 NTA는 특정 영역을 서명되지 않은 영역처럼 취급해 DNSSEC 검증을 일시적으로 우회한다. - Cloudflare는 .AL 운영자와 직접 연락하려 했지만, 연락처 역시 .AL 도메인에 있어 장애 중 접근할 수 없었다. - 약 3시간 후 .AL에 NTA를 적용해 1.1.1.1 사용자에게 정상적인 DNS 응답을 제공했다. - NTA의 대가로 해당 기간 동안 .AL 응답은 DNSSEC로 암호학적 진위를 보장받지 못했다. - 장애가 공개적으로 확인됐고 모든 검증 리졸버에 영향을 주고 있었기 때문에, 도메인 접근성을 유지하는 편이 낫다고 판단했다. - 루트 영역에서 DS 레코드가 제거된 다음 날 NTA를 삭제했다. ### NTA의 보안상 문제 - NTA가 적용된 응답은 일반적인 성공 응답과 겉보기에는 동일하다. - 사용자는 응답만 보고 DNSSEC 검증이 수행됐는지, 위조 가능성이 남아 있는지 알 수 없었다. - RFC 7646은 운영자가 NTA 적용 현황을 공개하도록 권고하지만, 상태 페이지나 공지는 사용자가 직접 확인해야 한다. - 애플리케이션, 모니터링 도구, 일반 DNS 클라이언트가 응답 자체만으로 검증 우회를 감지할 방법이 부족했다. ### EDE를 이용한 투명성 확보 - RFC 8914의 Extended DNS Error는 정상 응답이나 오류 응답에 추가 설명을 포함할 수 있다. - Quad9의 Babak Farrokhi가 NTA 적용 사실을 DNS 응답에 표시하는 새 EDE 코드를 제안했고, Cloudflare가 공동 저자로 참여했다. - 1.1.1.1은 .AL 장애 중 다음 정보를 함께 반환했다. - `EDE: 9 (DNSKEY Missing)`: DS와 일치하는 DNSKEY를 찾지 못했다는 원래 검증 오류 - `EDE: 33 (Negative Trust Anchor)`: 해당 조회에 NTA가 적용되어 DNSSEC 검증이 우회됐다는 사실 - 따라서 클라이언트는 `NOERROR`와 실제 IP 주소를 받더라도, 그 응답이 검증된 결과가 아님을 구분할 수 있다. ### 실용적인 결론 DNSSEC 장애 시 NTA는 대규모 접속 장애를 완화하는 유용한 비상 수단이지만, 보안 검증을 포기하는 조치이므로 제한적으로 사용해야 한다. DNS 리졸버와 모니터링 도구는 EDE, 특히 NTA를 나타내는 코드 33을 확인해 검증 우회 상태를 사용자와 시스템에 명확히 알려야 하며, TLD 운영자는 키 롤오버 전에 DS·DNSKEY 전환 절차를 철저히 검증해야 한다.

dnsseccloudflarednsnegative-trust-anchor+2

cloudflare2026년 5월 6일

DNSSEC가 잘못되었을 때: .de TLD 장애에 대응한 방법 (새 탭에서 열림)

2026년 5월 5일, .de TLD 운영자인 DENIC이 잘못된 DNSSEC 서명을 배포하면서 .de 하위 도메인에 대한 DNS 조회가 대규모로 실패했다. Cloudflare의 1.1.1.1은 DNSSEC 규격에 따라 검증에 실패한 응답을 `SERVFAIL`로 처리했지만, 캐시된 레코드를 TTL 이후에도 제공하는 “serve stale”과 DNSSEC 검증 우회 설정으로 영향을 완화했다. 이 대응은 가용성을 높이는 대신 사고 기간 동안 .de 도메인의 위조·변조 위험을 일부 감수하는 선택이었다. ## DNSSEC와 신뢰 체인 - DNSSEC은 DNS 응답의 암호화가 아니라 **무결성과 진위 검증**을 제공한다. - 각 DNS 레코드에는 `RRSIG` 전자서명이 붙으며, 리졸버는 이를 검증해 응답이 변조되지 않았는지 확인한다. - 검증은 루트 영역에서 시작하는 신뢰 체인을 따른다. - 루트 영역이 `.de`를 신뢰한다. - `.de`는 `DS` 레코드를 통해 `example.de` 같은 하위 영역을 신뢰한다. - 체인의 어느 한 지점이라도 깨지면 해당 영역 아래의 모든 도메인이 검증 실패와 `SERVFAIL`을 겪는다. - 일반적으로 다음 두 키를 사용한다. - **ZSK**: 영역 내 DNS 레코드 서명 - **KSK**: ZSK를 서명하며, 부모 영역의 `DS` 레코드가 KSK를 가리킴 - 키 교체 중 새 키가 완전히 배포되지 않았거나, 서명에 사용된 키를 `DNSKEY`에서 확인할 수 없으면 리졸버는 응답을 거부한다. ## .de TLD 장애와 영향 - 2026년 5월 5일 약 19:30 UTC부터 DENIC이 잘못된 DNSSEC 서명을 게시했다. - DNSSEC 검증을 수행하는 리졸버는 해당 서명을 거부하고 `SERVFAIL`을 반환해야 했다. - 1.1.1.1에서도 초기 `SERVFAIL`이 급증했고, 캐시된 레코드가 만료되면서 약 3시간 동안 실패율이 계속 상승했다. - 사용자가 실패한 DNS 조회를 반복하면서 전체 쿼리량도 크게 증가했다. - 실제 사용자 수보다 `SERVFAIL` 요청 수가 더 크게 보일 수 있는데, 동일한 사용자의 재시도가 여러 요청으로 집계되기 때문이다. - `.de`는 세계적으로 많이 조회되는 TLD이므로 장애가 수백만 개 도메인의 접근성에 영향을 줄 가능성이 있었다. ## 캐시된 응답을 계속 제공하는 “serve stale” - 리졸버는 권위 있는 네임서버의 응답을 레코드별 TTL 동안 캐시한다. - 장애가 발생하면 새로 가져온 레코드는 DNSSEC 검증 실패로 `SERVFAIL`이 되지만, 장애 전부터 캐시에 있던 레코드는 여전히 유효한 내용을 담고 있을 수 있다. - 1.1.1.1은 RFC 8767에 정의된 **serve stale** 동작을 사용해, 상위 네임서버 조회가 실패해도 만료된 캐시 레코드를 일정 기간 제공했다. - 이 기능 덕분에 일부 사용자는 장애 중에도 정상적인 `NOERROR` 응답을 받았다. - 캐시된 데이터가 사라질수록 stale 응답이 줄고, 정상 응답률도 점차 낮아졌다. - 즉, 캐시는 장애를 해결하지는 않지만 운영자가 복구할 시간을 벌어 주며 즉각적인 사용자 피해를 줄인다. ## DNSSEC 검증을 우회하는 Negative Trust Anchor - RFC 7646의 **Negative Trust Anchor(NTA)** 는 특정 영역을 일시적으로 DNSSEC 미서명 영역처럼 취급하는 예외 설정이다. - 신뢰 체인이 깨진 경우 해당 영역 아래 응답의 DNSSEC 검증을 생략해 `SERVFAIL`을 피할 수 있다. - TLD 운영자의 설정 오류처럼 하위 도메인 자체에는 문제가 없는 상황이 NTA의 대표적인 사용 사례다. - 이 경우 계속 `SERVFAIL`을 반환하는 것은 실질적인 보안 이득보다 가용성 손실이 더 클 수 있다. ## Cloudflare의 실제 완화 조치 - Cloudflare의 1.1.1.1과 관련 서비스는 `Big Pineapple`이라는 자체 리졸버를 사용한다. - 당시 Cloudflare는 RFC 방식의 네이티브 NTA 기능을 구현하지 않은 상태였다. - 대신 기존 오버라이드 규칙을 활용해 `.de`를 **insecure zone**으로 지정했다. - 결과적으로 `.de` 질의는 DNSSEC이 활성화되지 않은 영역처럼 처리되어 검증 실패에 따른 `SERVFAIL`을 피할 수 있었다. - 이는 형식상 NTA는 아니지만 기능적으로는 동일한 효과를 냈다. - 다만 DNSSEC을 우회하는 동안에는 실제 공격자가 DNS 응답을 변조하더라도 검증으로 차단할 수 없으므로, 가용성과 보안 사이의 의도적인 절충이었다. 장기적으로는 DNSSEC 장애 대응을 위해 serve stale을 활성화하고, 통제된 조건에서 사용할 수 있는 NTA 또는 동등한 예외 메커니즘을 마련하는 것이 권장된다. 단, 검증 우회는 장애 범위와 원인이 명확할 때만 일시적으로 적용하고, 복구 즉시 해제해야 한다.

dnssecdnsdomain-name-systemcloudflare-1.1.1.1+4