Cloudflare 1.1.1.1 2025년 7월 14일 장애 사건

 (blog.cloudflare.com)
1P by GN⁺ | ★ favorite | 댓글 1개
  • Cloudflare가 2025년 7월 14일에 서비스 토폴로지 변경 중 1.1.1.1 공용 DNS Resolver에 62분간의 전면 장애 발생
  • 글로벌 사용자 대다수가 직접적인 영향을 받아 인터넷 사용 불가 현상 경험
  • 장애 원인은 내부 레거시 시스템의 잘못된 구성으로, 외부 공격이나 BGP 하이재킹과는 무관함
  • 장애는 잘못된 구성 변경의 누적과 네트워크 전역 재설정이 맞물리면서 촉발됨
  • 재발 방지 대책으로 점진적 배포 시스템 도입 및 레거시 구성 시스템의 폐기 계획 준비

개요

2025년 7월 14일, Cloudflare가 서비스 토폴로지 변경 중 1.1.1.1 공용 DNS Resolver에 글로벌 네트워크 장애를 유발함. 이 장애로 인해 1.1.1.1과 Gateway DNS 서비스를 이용하던 사용자들이 62분간 인터넷 서비스 불가 또는 심각한 서비스 저하를 경험함. 이는 내부 레거시 시스템의 구성 오류에 기인하며, 외부 공격이나 BGP 하이재킹으로 인한 것은 아님.

장애의 범위 및 영향

  • 21:52 UTC ~ 22:54 UTC 동안 1.1.1.1 Resolver가 전 세계적으로 사실상 동작 불가 상태였음
  • 대다수 글로벌 고객이 도메인 이름 해석을 못하여 인터넷 사용 자체가 불가능했음
  • 장애 발생 상황은 Cloudflare Radar에서 확인 가능
  • 장애 사유는 Cloudflare가 보유 IP 주소를 인터넷에 광고하는 인프라를 관리하는 레거시 시스템의 잘못된 설정 때문임
  • 1.1.1.1 채널을 통해 Cloudflare에 도달하던 트래픽 전체에 치명적 영향 발생

장애 발생 원인 및 배경

  • Cloudflare는 DNS Resolver 등 글로벌 서비스를 위해 Anycast 라우팅을 사용함
  • 다양한 지역에서 서비스를 제공하지만, 일부 데이터로컬라이제이션을 요구하는 서비스는 특정 지역에 한정됨
  • 6월 6일, 차후 DLS(데이터 로컬라이제이션) 서비스 준비를 위한 구성 변경 중, 1.1.1.1 Resolver IP 대역이 의도치 않게 신규 DLS에 포함됨
    • 이 오류는 즉시 반영되지 않고 실제로는 영향을 미치지 않아 경보가 발생하지 않음
  • 7월 14일, 테스트 목적의 오프라인 위치를 DLS 토폴로지에 추가하는 변화가 적용됨
    • 이 변경으로 글로벌 네트워크 구성이 강제 갱신되면서 기존 오류가 노출됨
    • 1.1.1.1 Prefixes가 전세계 데이터센터에서 철회되어 서비스 단절

장애 타임라인(요약)

  • 2025-06-06 17:38: DLS 서비스용 구성 변경에 1.1.1.1 Prefixes 포함(영향 없음, 오류 잠복)
  • 2025-07-14 21:48: 구성 변경으로 네트워크 전체 구성 새로 고침, 1.1.1.1 Prefixes가 글로벌하게 철회 시작
  • 2025-07-14 21:52: 글로벌 DNS 트래픽 급감
  • 2025-07-14 22:01: 내부 경보, 장애 선언
  • 2025-07-14 22:20: 이전 구성으로 롤백, 서비스 복구 절차 개시
  • 2025-07-14 22:54: 트래픽 정상화 및 경보 해제, 장애 종료

장애 영향 IP 및 프로토콜

  • 영향 범위: 1.1.1.0/24, 1.0.0.0/24, 2606:4700:4700::/48 등 IPv4, IPv6 광범위 Prefixes
  • UDP, TCP, DoT(DNS over TLS) 사용 쿼리에서 급격한 트래픽 감소 관측
  • DoH(DNS over HTTPS)는 cloudflare-dns.com 도메인 기반이 많아 영향을 거의 받지 않음

기술적 장애 설명

1.1.1.1 Resolver 서비스 장애

  • 6월 6일 DLS용 사전 구성 변경 과정에서 Prefixes 오류 삽입
  • 7월 14일, 테스트 목적으로 오프라인 위치가 추가되며, 네트워크 전역 설정이 갱신
  • 이 과정에서 1.1.1.1 Resolver Prefixes가 전세계적으로 단일 오프라인 위치로 한정되어 서비스 철회

기술적 원인 분석

  • Cloudflare는 현재 레거시 시스템과 신규 전략 시스템을 병행 운영하고 주소 공간별 라우팅 광고를 동기화함

  • 레거시 시스템은 수작업 업데이트, 배포의 점진성 부재 등 오류 확률 높음

    • Peer review 및 타 엔지니어 검토는 있었으나, 카나리아 배포 등 점진적 반영 보장 구조 부재

  • 신규 방식은 하드코딩 대신 토폴로지 중심, 점진적 변화 반영 및 모니터링 체계 도입

  • 22:01, DNS Resolver 경보 발생

  • 내부 BGP 라우팅 테이블에서 Resolver 라우트가 전부 소실된 사실 확인

  • Prefixes 철회 후 1.1.1.0/24 subnet은 Tata Communications India(AS4755)에서 BGP 광고 시도

    • 이는 일시적 Prefix Hijack과 유사하나, 사고와는 직접적으로 무관

복구 절차 및 후속 조치

  • 22:20 UTC, 이전 구성으로 롤백 및 Prefixes 재광고
    • 약 77% 트래픽 즉시 복구
    • 일부 에지 서버는 자동 재설정되어, 수동 변경 관리 시스템으로 재반영 필요
    • 네트워크 안전상 점진적 롤아웃을 하지만, 이번 사고에서는 검증 후 빠르게 적용
  • 22:54, 전체 위치 정상 복귀

향후 개선 방안

  • 점진적 배포 체계(Stage Deployment) 도입: 레거시 배포 방식 폐지, 헬스 기반 자동 롤백 구조 도입
  • 레거시 시스템 폐기 가속화: 위험한 수기 구성과 배포 방식 제거, 문서화와 테스트 커버리지 강화

결론

Cloudflare 1.1.1.1 DNS Resolver 장애는 내부 구성 오류로 인한 것이며, Cloudflare는 향후 안정성 개선과 재발 방지 대책 도입에 총력을 기울이고 있음. 고객에게 폐를 끼친 점을 사과하며, 미래에는 유사 사태를 최소화하기 위한 조치를 계속 강화 예정임.

함께 보면 좋은 글 β

GN⁺   [-]
Hacker News 의견

  • 많은 사용자들에게 1.1.1.1 리졸버(DNS)가 작동하지 않을 때, 거의 모든 인터넷 서비스에 접속할 수 없게 됨을 의미함. 그런데 보통 모든 기기에는 두 개의 DNS 서버를 설정하지 않음? 두 번째도 다운된 것인지, 그렇지 않으면 왜 해당 서버로 넘어가지 않았는지 궁금함

    • Cloudflare는 1.1.1.1과 1.0.0.1 두 개 모두를 DNS 서버로 설정할 것을 권장함. 그러나 이번 장애를 일으켰던 설정 실수 때문에 1.1.1.0/24와 1.0.0.0/24 프리픽스 모두에 대한 Cloudflare의 BGP 광고가 중단됐음
    • Android에서는 설정-네트워크 및 인터넷-Private DNS에서 "Private DNS provider hostname" 하나만 입력할 수 있음(내가 아는 바로는). 그리고 왜 IP(1.1.1.1)를 받지 않고 반드시 주소(one.one.one.one)를 요구하는지 이해가 가지 않음. DNS 서버를 지정할 때 IP로 설정하는 게 훨씬 합리적인 생각임
    • 두 개를 나열하는 게 없는 것보단 낫지만 완벽하지 않음. 한 쪽이 다운되면, 어떤 게 정상 동작하는지 추적하지 않기 때문에 대체로 긴 대기시간과 간헐적 이슈를 겪게 됨. 둘 이상의 업스트림을 가진 로컬 캐싱 DNS 프록시 같은 고급 설정을 쓰지 않는 한 마찬가지임
    • DNS에 대해 이야기할 수 있다고 생각한다면 스스로 서비스를 운영해야 한다고 조언함. 루트 도메인 "."는 수십 년 동안 잘 동작해왔는데, 1.1.1.1에서 문제가 생기는 주된 이유는 DNS 자체가 아니라 애니캐스트에 있음. Cloudflare(및 Google 등)는 "vanity" IP 주소를 고집함—이런 IP 사용을 가능하게 하려면 애니캐스트를 써야 하고, 진짜 문제는 DNS가 아니라 애니캐스트임. 한 명 이상의 공급자를 선택해 설정하길 추천함
    • Cloudflare가 권장하는 구성은 백업 서버인 1.0.0.1을 보조 DNS로 함께 두는 것이지만, 이번 사고 때는 그 서버도 영향을 받았음

  • 대략 20분 정도의 장애에서 1.1.1.1의 트래픽이 약 20% 줄어든 것이 흥미로움. Cloudflare가 이런 단순하고 오래된 문제로 계속하게 된다는 게 신기함(이번이 첫 번째도 아니고, 마지막도 아닐 것 같음). Google의 8.8.8.8 및 8.8.4.4는 거의 10년 가까이 전세계적으로 (1) 1초의 다운타임도 없었음. (1: 일부 지역적 문제는 있었지만, 그건 인터넷 탓이고 Google의 다양한 서비스가 심각한 장애를 겪을 때도 DNS 자체는 계속 정상 작동했음.)

    • 단순히 가용성만이 아니라, DNS에는 속도와 프라이버시도 중요함. 유럽 사용자라면, 유럽 대안 DNS 목록에서 미국 기업(CLOUD act 적용) 대신 사용할 수도 있음
    • Cloudflare처럼 규모와 복잡성이 엄청난 네트워크 환경에서 벌어지는 엔지니어링 문제를 어떻게 쉽게 해결 못하겠냐는 의견에, 현실적으로 업계 0.001%만 경험하는 문제임을 설명함
    • Cloudflare는 사고 대응 문화는 합리적이나, 사전 예방적 조치를 적극 장려하는 인센티브가 부족한 점이 있음
    • 언급한 20% 수치는, 일부 클라이언트/리졸버가 여러 번 응답 실패시 임시로 DNS 서버를 중단 처리해서 사용자 입장에서 매 요청마다 타임아웃을 500번씩 기다릴 필요 없게 함을 뜻함. 장기적으로는 트래픽 그래프상 볼륨이 정상으로 돌아옴
    • Google DNS를 쓰고 싶지 않은 사람이 많음에 동의함

  • 영향 감지에 5분 이상(메인 프로토콜 트래픽이 10%로 떨어지고 유지됨에도)이 걸렸다는 사실이 놀라움. 그렇게 대규모 시스템을 운영해 본 적은 없지만, 이 정도면 즉각 경고가 발생할 거라 기대했음. 전문가들도 이게 합리적인지 궁금함

    • 감지 속도와 오탐률 사이에는 지속된 긴장감이 있음. Nagios, Icinga 같은 모니터링 시스템은 보통 3회 연속 실패해야 이벤트를 발생시키는데, 일시적 오류가 흔하기 때문임. 알람이 너무 잦으면 담당자들이 무감각해지고 "잠깐 기다려 보자"라는 반응이 늘어남. Cloudflare처럼 글로벌 서비스를 직접 운용해보진 않았지만, 8분 만에 신뢰성 있는 감지가 된 건 놀랍지 않음
    • 예전 NOC(네트워크 운영센터)처럼, 이런 그래프가 벽에 걸려 있다면 누군가 한 번 쳐다보고 "이상하다"며 바로 달려들었을 것임
    • 영향이 시작됐을 때 서비스가 완전히 다운 상태가 아니었을 것이라고 생각함(특히 글로벌 롤아웃 시작점이라면 더욱 그렇고), 영향이 측정 가능해지는 데 시간이 걸렸을 것임
    • 1분 내 알람을 울리게 하면 오히려 알람 인프라 성능 테스트만 될 뿐임. 실제로 1분마다 데이터 수집·계산이 안정적으로 가능한가, 그게 문제임
    • 메트릭 집계 서비스가 크래시날 때, 시스템이 다시 배포될 때까지 지표가 지연돼 100% 드롭처럼 보일 수 있음. 1분 만에 알림을 보내면 불필요하게 밤 2시에 많은 사람이 깨게 되고, 반복되면 결국 알람이 점점 느슨해짐—그래서 5분 정도에 맞춰지는 현상이 일어남

  • 좋은 요약글임. DoH(HTTPS 기반 DNS)는 대부분 cloudflare-dns.com 도메인을 통해 접근하지만(수동 설정 또는 브라우저), IP 주소가 아니기 때문에 상대적으로 장애 영향이 적었다는 부분이 흥미로움. 나는 어제 영향받았는데, 라우터에 DoH를 활성화했음에도 아무 것도 조회되지 않아서 8.8.8.8로 바꾸니 문제 해결됨

    • DoH는 어떻게 동작하는지 궁금함. cloudflare-dns.com의 IP를 알아야 하는데, 라우터가 1.1.1.1을 썼을 수도 있음
    • 오늘 새 도메인을 설정하는데, 약 20분 동안 한 노트북의 Firefox에서만 접근이 됐음. Google DNS 툴은 도메인이 활성 상태라고 나왔고, AWS 서버에서는 SSH도 됐지만 내 로컬 네트워크에서는 DNS 조회가 안 됐음. 캐시 플러시도 했고 별짓 다 했지만, 그 Firefox 브라우저만 Cloudflare DoH를 쓰도록 따로 설정되어 있었음
    • 나는 동의하지 않음. 실제 근본 원인은 현학적인 용어로 애매하게 감춰져 있어서, 경험 많은 관리자들도 혼란스럽게 만듦. "legacy"란 용어는 명확하지 않고 오히려 추상적이고 불투명하게 느껴짐. "Legacy 컴포넌트는 점진적 배포 방식을 활용하지 않으며, Cloudflare는 점진적 배포와 롤백이 가능한 현대적 방식을 도입하겠다"라는 문장을 보면 무슨 뜻인지는 알겠지만, 굳이 이렇게 알아듣기 어렵게 쓸 필요는 없음
    • 내 Unifi 라우터는 자동 DoH로, Cloudflare와 Google을 동시에 쓰는 것으로 보임. 영향은 못 느꼈으니, Cloudflare DoH가 계속 동작했거나 Google로 바로 넘어간 듯함
    • 전체적으로 잘된 요약이지만, 글 맨 앞부분에 나온 타임라인 내용은 사실과 다름

  • dnsmasq를 사용하면 여러 DNS 서버를 동시에 설정하고, 가장 빨리 응답하는 서버를 사용하는 방식이 가능함. 한 서비스가 다운돼도 문제를 거의 못 느낌

    • strict-order 설정 없이 all-servers를 쓸 때 dnsmasq는 자동으로 모든 서버에 재시도 요청을 보냄. 하지만 systemd-resolved를 쓴다면 순서대로만 재시도하기 때문에, 다양한 공급자 서버를 번갈아 넣는 게 중요함. 예시에서처럼 IPv4와 IPv6까지 함께 조합하면 failover가 더 빨라짐. Quad9의 해당 IP 주소는 기본 필터링이 활성화돼있고, 나머지 두 개는 아니라서 서로 해석 결과가 다를 수 있음. 개인적으로 DNSSEC(도메인 보안 확장) 유효성검사를 중시한다면, 검증하는 리졸버와 안 하는 리졸버를 혼합하면 안됨(예시 내 DNS들은 모두 DNSSEC 지원함)
    • 빅테크 업체들(Cloudflare, Google 등)에게 내 DNS 기록이 모두 노출되는 게 싫고, DoH도 원하지 않을 때 더 사적인 설정이 가능한지 질문함. dnsmasq에 신뢰할만한 소규모 DNS 목록을 쓰면 좋을 것 같지만, 여러 DNS 제공자에 매번 요청을 보내는 게 비매너인지는 고민됨. 안정적인 프라이버시 지향 DNS 목록을 어디서 찾을지 모르겠음
    • 여러 DNS 공급자는 정책이나 중요도가 달라서, 나는 둘을 대체물로 생각하지 않음. 오히려 하나만 정하고 ISP(통신사)의 DNS를 백업으로 쓰겠음
    • systemd-resolved를 사용하면 기본적으로 DoT와 DNSSEC를 지원하니 비슷한 동작을할 수 있음. 중앙 집중식 DNS를 완전히 피하려면 Tor 데몬을 돌려서 네트워크에 DNS 리졸버를 노출할 수 있음. 여러 리졸버도 가능함
    • "all-servers" 설정 없이도 dnsmasq는 주기적으로 각 서버에 요청을 레이스(경쟁)함(기본 20초마다 재시도). 갑작스러운 장애라 해도 몇 초 이상 영향받지 않을 것임

  • 약 1시간짜리 장애라 해도 한 달 기준 0.13%, 1년 기준 0.0114%임. Cloudflare가 이 서비스에 적용하는 SLO(서비스 수준 목표)가 궁금함. 링크를 찾긴 했지만 유료 서비스 전용임. 이번 장애로 7월 가용성이 "< 99.9% but >= 99.0%" 구간에 들어가며, 이 경우 이용료의 10%를 환불받게 됨

    • 브랜드 평판을 유지하려면 연간 99.9%나 그 이상일 것이라 생각함

  • 사고 이후에도 트래픽이 완전히 정상으로 돌아오지 않은 점이 흥미로움. 최근 OpenWrt의 "luci-app-https-dns-proxy"를 써서 Cloudflare와 Google DNS에 동시에 요청하는데, DoH 영향이 거의 없었어서 장애를 못 느꼈음(DoH까지 망가졌다면 Google로 자동 전환됐을 것)

    • 사고 직후에도 즉시 트래픽이 복구되지 않은 이유를 본문 뒷부분에서 더 다룸. 일부 서버는 직접적인 개입이 필요했기 때문인 듯 함
    • 장애가 일어나면 인터넷이 안 돼서 아예 잠시 다른 행동을 하는 경우가 많음. 실제로 그 시간 동안 DNS 공급자를 바꾸는 사람은 거의 없을 것이라 추측함
    • 클라이언트들이 DNS 조회 결과를 일시적으로 캐시하기 때문에, 장애 이후 한동안은 과거 값을 쓰는 경우도 있음

  • 1.1.1.1과 1.0.0.1 모두가 같은 변경에 의해 영향을 받았다는 점이 놀라움. 이제 DNS 백업에는 완전히 다른 제공자를 써야 할 듯함(예: 8.8.8.8, 9.9.9.9)

    • 두 주소 모두 사실 같은 서비스에서 제공됨. 상호 독립적인 백업처럼 광고된 적이 없었음
    • 원래 DNS의 설계 목적은 가장 가까운 리졸버를 쓰는 것임. 여러 공급자, 백본, 지역을 다양하게(그리고 가능하면 Anycast 주소가 아닌 곳으로) 적절히 분산해 쓰는 게 좋음. 하지만 이 경우 DNS의 동작 특성 때문에 뜻밖의 문제도 만날 수 있음
    • 어차피 항상 그런 상황이었음
    • 난 이미 OpenDNS, Quad9, Cloudflare를 섞어 Pi-hole 두 대에 설정해서 사용 중임. 대부분의 내 기기들은 두 Pi-hole을 각각 DNS로 쓰고 있음
    • 사실 "DNS 백업"이란 개념 자체가 의미 없음. 대부분의 클라이언트는 단순히 한 주소를 임의로 선택해 사용하고, 한 쪽이 다운돼도 나머지에 자동으로 넘어가는 게 아님. 동작 방식을 기대대로 사용할 수 없는 상황임

  • Cloudflare의 내부 토폴로지는 "legacy"와 "strategic" 시스템이 동기화되는 형태로 발전되어감. 기술자와 비전문가 모두 이해할 수 있도록 현황을 명확하게 설명한 글임. 마이그레이션 과정을 오히려 흥미롭게 느껴지게 잘 써낸 것 같음. 사고로 인한 불편에 대해 사과하고, 앞으로 개선 및 재발 방지에 힘쓰겠다는 메시지가 인상적임. 이런 기업의 태도를 높게 평가함

    • "legacy"는 기술자들이 주로 쓰는 용어고, "strategic"은 마케팅이나 비기술 리더들이 주로 쓰는 용어라서 둘을 섞어 쓰면 오히려 양쪽 모두 혼란스럽고 짜증날 수 있음

  • 여러 엔지니어가 리브랜칭을 검토했다는데도 1.1.1.0/24가 리라우팅 목록에 추가된 실수를 아무도 못 봤다는 게 놀라움. 어떤 휴먼 에러, 혹은 악의로 이런 일이 벌어졌을지 궁금함. DLS(Domain List Service)에 1.1.1.1/32, 1.0.0.1/32에 대해 단일 위치로 지정하는 걸 막는 하드코딩 예외 처리가 필요해 보임

    • 아마도 "Jerry가 했으니 문제 없겠지"라는 신뢰가 원인일 수 있음
    • 나는 대체로 "사람 탓보다 도구 탓"하는 편임. 시스템 구조나 설정 파일 생성 방식에 따라, 이런 실수가 쉽게 넘어갈 수 있음(특히 diff가 자동생성이면 더욱 그렇고). 결국은 코드리뷰도 사람이 하니 이런 실패 유형은 절차상의 문제임. 현실적으로, 정말 큰 서비스 오프라인을 막으려면 여러 단계로 복수의 안전장치를 두는 방어 전략이 필요함
답변달기