Cloudflare / dns

Cloudflare outage on February 20, 2026 (새 탭에서 열림)

2026년 2월 20일, Cloudflare는 사용자 지정 IP(BYOIP) 서비스 관리 방식의 변경 과정에서 발생한 소프트웨어 오류로 인해 약 6시간 동안 서비스 장애를 겪었습니다. 이번 장애는 내부 자동화 시스템이 유효한 IP 접두사(Prefix)들을 실수로 인터넷 경로(BGP)에서 철회하면서 발생했으며, 이로 인해 일부 고객 서비스와 Cloudflare의 1.1.1.1 웹사이트 접속이 불가능해졌습니다. Cloudflare는 즉각적인 롤백과 수동 복구 작업을 통해 문제를 해결했으며, 향후 자동화 배포의 안전성을 강화하기 위한 체계적인 개선을 약속했습니다. ### Addressing API와 자동화 프로세스의 결함 * **Addressing API의 역할**: Cloudflare 네트워크에 존재하는 주소 데이터의 단일 진실 공급원(Source of Truth)으로, 여기서 발생한 변경 사항은 즉시 전 세계 에지(Edge) 네트워크로 전파됩니다. * **위험한 수동 작업의 자동화**: 기존에 수동으로 이루어지던 BYOIP 접두사 삭제 작업을 자동화하기 위해 '정기 정리 하위 태스크'를 도입했습니다. 이는 배포 규모를 작게 유지하고 안전성을 높이려는 'Code Orange: Fail Small' 프로젝트의 일환이었습니다. * **API 쿼리 버그**: 정리 태스크가 API를 호출할 때 `pending_delete` 매개변수를 처리하는 로직에 버그가 있었습니다. 삭제 대기 중인 객체만 불러와야 했으나, 코드상에서 매개변수의 존재 여부만 체크하는 오류로 인해 정상적인 접두사들까지 삭제 대상에 포함되는 결과를 초래했습니다. ### 고객 서비스 영향 및 BGP 경로 탐색 현상 * **IP 접두사 철회**: 전체 BYOIP 접두사 중 약 25%에 해당하는 1,100개의 접두사가 인터넷 광고에서 제외되었습니다. 이로 인해 해당 IP를 사용하는 서비스는 외부에서 접근할 수 없는 상태가 되었습니다. * **BGP 경로 탐색(Path Hunting)**: 접두사가 철회되자 사용자 연결은 목적지를 찾기 위해 여러 네트워크를 헤매는 '경로 탐색' 현상을 겪었으며, 결국 연결 타임아웃과 실패로 이어졌습니다. * **특정 서비스 오류**: Cloudflare의 재귀 DNS 리졸버 웹사이트(1.1.1.1) 접속 시 403 오류("Edge IP Restricted")가 발생했습니다. 다만, 실제 DNS 질의 서비스와 DoH(DNS over HTTPS)는 이번 장애의 영향을 받지 않았습니다. ### 복구 과정에서의 기술적 난관 * **단계적 복구**: 엔지니어들이 변경 사항을 감지하고 롤백을 시작하면서 약 800개의 접두사가 먼저 복구되었습니다. 일부 고객은 대시보드를 통해 직접 IP를 재광고함으로써 자가 복구를 수행하기도 했습니다. * **소프트웨어 버그로 인한 지연**: 나머지 300여 개의 접두사는 단순한 경로 철회를 넘어 에지 서버에서 서비스 구성 정보 자체가 삭제되는 추가적인 소프트웨어 버그가 발생했습니다. 이로 인해 대시보드 설정만으로는 복구가 불가능했습니다. * **수동 상태 전파**: 엔지니어들은 삭제된 설정 상태를 에지 서버에 다시 강제로 전파하는 수동 작업을 수행해야 했으며, 장애 발생 6시간 7분 만인 23:03 UTC에 모든 서비스가 정상화되었습니다. Cloudflare는 이번 사고를 계기로 모든 주소 관리 워크플로우에서 수동 개입을 완전히 배제하고, 자동화된 헬스 체크 기능을 강화할 계획입니다. BYOIP를 사용하는 기업 고객은 유사한 장애 발생 시 Cloudflare 대시보드를 통해 IP 광고 상태를 직접 제어함으로써 복구 시간을 단축할 수 있는 운영 매뉴얼을 숙지해 두는 것이 권장됩니다.

Cable cuts, storms, and DNS: a look at Internet disruptions in Q4 2025 (새 탭에서 열림)

2025년 4분기 전 세계 인터넷 환경은 정부 주도의 차단부터 해저 케이블 절단, 기상 이변에 이르기까지 180건 이상의 다양한 장애로 인해 큰 변동성을 보였습니다. 특히 탄자니아의 선거 관련 차단과 같은 정치적 요인 외에도, 해저 케이블 사고와 전력망 불안정이 국가 단위의 연결성에 심각한 타격을 입히는 주요 원인으로 분석되었습니다. 이러한 사례들은 물리적 인프라의 취약성과 더불어 클라우드 플랫폼 및 DNS 서비스의 기술적 오류가 현대 인터넷 가용성에 미치는 복합적인 영향을 잘 보여줍니다. ## 정부 주도의 인터넷 차단: 탄자니아 사례 * **대선 관련 통제:** 10월 29일 탄자니아 대통령 선거 중 발생한 시위로 인해 약 26시간 동안 인터넷이 차단되었으며, 트래픽이 평소보다 90% 이상 급감했습니다. * **BGP 및 IP 공간 분석:** 트래픽은 거의 소멸했으나 IPv4 및 IPv6 주소 공간의 공고(Announcement)는 완전히 사라지지 않았습니다. 이는 국가가 인터넷에서 완전히 분리된 것이 아니라 트래픽 흐름만 인위적으로 차단했음을 시사합니다. * **간헐적 복구와 재차단:** 10월 30일 잠시 복구되었으나 2시간 만에 다시 차단되었으며, 11월 3일이 되어서야 정상적인 트래픽 수준을 회복했습니다. ## 해저 및 지상 케이블 절단 사고 * **아이티(Digicel Haiti):** 10월 16일과 11월 25일 두 차례에 걸쳐 국제 광섬유 인프라가 절단되는 사고가 발생하여 전국적인 트래픽 중단이 발생했습니다. * **파키스탄(PEACE 케이블):** 10월 20일 홍해 인근의 PEACE 해저 케이블 절단으로 인해 Cybernet/StormFiber의 트래픽이 50% 급감하고 발표된 IPv4 주소 공간의 1/3이 사라지는 타격을 입었습니다. * **카메룬 및 서아프리카(WACS 케이블):** 10월 23일 WACS(West Africa Cable System) 해저 케이블 장비 결함으로 카메룬, 중앙아프리카공화국, 콩고공화국 등에서 90~99%의 트래픽 손실이 관찰되었습니다. 타 케이블 시스템으로 트래픽을 우회하는 과정에서 매우 불안정한 패턴이 나타나기도 했습니다. * **도미니카 공화국(Claro):** 12월 9일 두 개의 광섬유 노선이 동시에 단선되면서 전국적으로 77%의 트래픽 감소가 발생했습니다. ## 전력망 붕괴 및 기상 이변에 의한 장애 * **국가 단위 정전:** 도미니카 공화국(11월 11일), 파나마(12월 23일), 케냐(12월 28일)에서 전력망 변전소 사고 및 시스템 장애로 인해 인터넷 트래픽이 40~70%까지 하락하는 현상이 발생했습니다. * **극단적 기후 현상:** * **브라질:** 10월 11일 상파울루를 강타한 폭풍과 강풍으로 트래픽이 40% 감소했습니다. * **필리핀:** 10월 22~26일 태풍 '트라미'의 영향으로 여러 지역에서 40~75%의 연결성 저하가 나타났습니다. * **스페인:** 10월 29일 발렌시아 지역의 돌발 홍수로 인해 인프라가 파손되며 40~50%의 트래픽 하락이 관찰되었습니다. ## 기술적 결함 및 클라우드 플랫폼 이슈 * **ISP 및 교환 노드 오류:** 10월 1일 미국 컴캐스트(Comcast)의 대규모 장애와 10월 17일 벨기에 Equinix IX의 피어링 인프라 문제가 발생하여 트래픽이 급락했습니다. * **DNS 및 하이퍼스케일러 사고:** 11월 15일 Cloudflare의 1.1.1.1 DNS 서비스 이슈를 비롯하여, 분기 동안 Azure, AWS, Google Cloud 플랫폼에서 발생한 간헐적인 기술적 사고들이 웹 애플리케이션의 가용성에 영향을 미쳤습니다. 글로벌 인터넷 환경은 갈수록 복잡해지고 있으며, 단일 케이블 절단이나 지역적 정전이 국가 전체의 연결성을 위협할 수 있습니다. 따라서 기업과 기관은 다중 경로 네트워크 구성(Redundancy)을 강화하고, Cloudflare Radar와 같은 실시간 모니터링 도구를 활용하여 인프라 이상 징후에 신속히 대응할 수 있는 복원력을 갖추어야 합니다.

What came first- the CNAME or the A record (새 탭에서 열림)

Cloudflare의 DNS 서비스인 1.1.1.1은 메모리 사용량을 최적화하기 위해 DNS 응답 내 레코드 순서를 변경했다가 전 세계적인 접속 장애를 일으켰습니다. 대다수 현대 소프트웨어는 DNS 레코드 순서를 무시하지만, glibc와 같은 특정 구현체는 CNAME 레코드가 A 레코드보다 먼저 등장할 것을 전제로 작동하기 때문입니다. 결국 Cloudflare는 이전의 순서로 로직을 롤백하여 문제를 해결했습니다. ### CNAME 체인과 부분 캐싱 메커니즘 * **DNS 별칭 추적:** `www.example.com`을 조회할 때 리졸버는 최종 IP 주소에 도달할 때까지 여러 개의 CNAME(별칭)을 따라가며, 이 과정에서 발생하는 모든 중간 레코드를 캐싱합니다. * **부분 만료 처리:** 체인 내 레코드들은 각기 다른 TTL(유효 기간)을 가집니다. 일부 CNAME은 유효하지만 최종 A 레코드가 만료된 경우, 리졸버는 전체 체인을 다시 조회하는 대신 만료된 부분만 갱신하여 기존 캐시와 병합합니다. * **병합 과정의 중요성:** 갱신된 레코드와 기존 캐시 레코드를 하나의 응답으로 합칠 때, 이들의 배열 순서가 클라이언트의 해석 방식에 영향을 미칩니다. ### 성능 최적화를 위한 로직 변경 * **기존 방식 (CNAME 우선):** 새로운 리스트를 생성하여 캐시된 CNAME들을 먼저 넣고, 그 뒤에 새로 조회된 A 레코드를 추가했습니다. 이는 메모리 할당과 복사 비용이 추가로 발생합니다. * **변경 방식 (A 레코드 우선):** 메모리 사용량을 줄이기 위해 기존의 응답 리스트 끝에 CNAME 레코드를 단순히 덧붙이는(append) 방식으로 변경했습니다. * **결과:** 이 사소한 변경으로 인해 DNS 응답 데이터에서 CNAME이 최종 결과값인 A 레코드보다 뒤에 위치하게 되었습니다. ### glibc 등 DNS 클라이언트의 처리 방식 문제 * **순차적 탐색:** 리눅스에서 널리 사용되는 `glibc`의 `getaddrinfo`와 같은 구현체는 DNS 응답을 순차적으로 읽으며 '찾아야 할 이름'을 업데이트합니다. * **인식 실패:** 클라이언트가 CNAME을 먼저 발견하면 "다음 타겟 이름"을 갱신하고 이후에 나오는 A 레코드를 수락합니다. 하지만 A 레코드가 먼저 나오면 아직 CNAME 정보를 모르기 때문에 해당 레코드를 무관한 데이터로 간주하고 무시합니다. * **결과적 오류:** 모든 데이터를 읽었음에도 불구하고 클라이언트는 매칭되는 IP를 찾지 못해 최종적으로 응답이 비어 있다는 결론을 내리게 됩니다. ### 시사점 및 결론 40년 된 DNS 프로토콜의 모호성으로 인해 레코드 순서에 대한 엄격한 정의가 부족할 수 있지만, 실제 환경에서는 전통적인 순서(CNAME -> Answer)를 유지하는 것이 하위 호환성을 위해 필수적입니다. 시스템의 성능 최적화가 기존 생태계의 암묵적인 동작 원리를 깨뜨리지 않는지, 특히 표준 라이브러리 수준의 하위 호환성을 철저히 검증해야 함을 보여주는 사례입니다.

What we know about Iran’s Internet shutdown (새 탭에서 열림)

2025년 말 이란 내 경제적 불만과 정권 교체 요구로 촉발된 대규모 시위에 대응하여 이란 정부가 전국적인 인터넷 차단 조치를 단행했습니다. Cloudflare Radar 데이터 분석 결과, 2026년 1월 8일부터 이란의 인터넷 트래픽은 사실상 전무한 상태로 떨어졌으며 이는 과거 2019년과 2022년의 사례와 유사한 국가 차원의 의도적인 차단으로 확인됩니다. 현재 이란은 전 세계 인터넷으로부터 거의 완전히 고립된 상태이며, 이러한 기술적 단절은 시위 확산을 막기 위한 정부의 강력한 통제 수단으로 활용되고 있습니다. **1월 8일 발생한 급격한 연결 단절** - 1월 8일 11:50(UTC)경, 이란 네트워크에서 공고되는 IPv6 주소 공간이 98.5% 급감하며 글로벌 인터넷에서 해당 주소로 접근할 수 있는 경로가 사라졌습니다. - 이로 인해 인간이 생성하는 트래픽 중 IPv6가 차지하는 비중이 12%에서 2%로 떨어졌으며, 100분 뒤에는 사실상 0%에 수렴했습니다. - 같은 날 16:30~17:00(UTC) 사이, MCCI(AS197207), IranCell(AS44244), TCI(AS58224) 등 이란 주요 통신사들의 트래픽이 90% 이상 빠지기 시작해 18:45(UTC)에는 국가 전체 트래픽이 0에 도달했습니다. **일시적인 연결 복구와 제한된 접근** - 차단 다음 날인 1월 9일, 테헤란 대학교(AS29068)와 샤리프 공과대학교(AS12660) 등 일부 주요 교육 기관의 네트워크 연결이 몇 시간 동안 일시적으로 복구되었다가 다시 중단되었습니다. - Cloudflare의 공용 DNS resolver(1.1.1.1)에 대한 요청 트래픽이 잠시 급증하는 현상이 관찰되었으나, 곧 이전 최고치의 0.01% 미만 수준으로 다시 떨어졌습니다. **전면 차단에 앞선 기술적 검열 징후** - 전면적인 인터넷 셧다운이 발생하기 수일 전인 12월 31일부터 주요 네트워크에서 HTTP/3 및 QUIC 프로토콜의 사용 비중이 40%에서 5% 미만으로 급격히 감소했습니다. - 이는 정부가 전면 차단을 시행하기 전, 고도화된 레이어 기반의 필터링과 화이트리스트 시스템을 적용하여 특정 통신 방식을 먼저 차단했음을 시사합니다. **지속되는 셧다운 상황** - 1월 10일 이후 현재까지 이란의 인터넷 트래픽은 회복될 기미를 보이지 않고 있으며, 전 세계와 연결된 통로가 대부분 막혀 있는 상태입니다. 이란 내부의 실시간 연결 상태와 네트워크별 지표는 Cloudflare Radar의 트래픽 및 라우팅 페이지를 통해 지속적으로 모니터링할 수 있습니다.