Cloudflare / networking

Ending the "silent drop": how Dynamic Path MTU Discovery makes the Cloudflare One Client more resilient (새 탭에서 열림)

Cloudflare는 Cloudflare One Client에 '동적 경로 MTU 발견(Dynamic Path MTU Discovery, PMTUD)' 기술을 도입하여, 네트워크 경로상에서 패킷 크기 제한으로 인해 연결이 끊기는 'PMTUD 블랙홀' 문제를 해결했습니다. 기존의 수동적인 방식 대신 MASQUE 프로토콜을 활용한 능동적 탐색 방식을 채택함으로써, 사용자는 LTE/5G나 위성 네트워크와 같은 제한적인 환경에서도 패킷 손실 없이 안정적인 연결을 유지할 수 있습니다. 이 기술은 현대적인 보안 암호화로 인해 커진 패킷을 네트워크 환경에 맞춰 실시간으로 최적화하여 하이브리드 작업자와 긴급 구조대원 등의 연결성을 획기적으로 개선합니다. **현대적 보안과 레거시 인프라의 충돌** - 표준 이더넷의 최대 전송 단위(MTU)는 보통 1500바이트이지만, 현대적인 보안 요구사항(FIPS 140-2 준수 등)으로 인해 패킷 내 암호화 및 메타데이터 오버헤드가 증가하고 있습니다. - LTE/5G, 위성 링크, 공공 안전 네트워크 등 일부 환경은 MTU 제한이 1500바이트 미만인 경우가 많아, 보안 패킷이 해당 라우터를 통과하지 못하는 상황이 발생합니다. - 원래는 라우터가 ICMP 메시지를 통해 패킷이 너무 크다는 사실을 알려야 하지만, 방화벽이나 중간 장비(middlebox)가 이 메시지를 차단하면 보낸 쪽에서 이유도 모른 채 데이터가 사라지는 '블랙홀' 현상이 발생하여 연결이 끊어집니다. **능동적 프로빙을 통한 PMTUD 구현** - Cloudflare는 RFC 8899 표준을 기반으로 한 능동적 경로 MTU 발견 방식을 구현하여 레거시 ICMP 피드백에 대한 의존도를 없앴습니다. - Cloudflare의 오픈 소스 QUIC 라이브러리로 구축된 MASQUE 프로토콜을 활용해, 클라이언트가 Cloudflare 에지 서버로 다양한 크기의 암호화된 프로브(Probe) 패킷을 직접 보냅니다. - 지원되는 MTU 범위의 상한선부터 중간값까지 테스트하며 에지 서버의 응답 여부를 확인하고, 해당 경로에 정확히 맞는 MTU 크기를 찾아냅니다. - 사용자가 Wi-Fi(MTU 1500)에서 셀룰러(MTU 1300) 환경으로 이동하더라도, 클라이언트가 실시간으로 가상 인터페이스의 MTU를 조정하여 세션 중단 없이 연결을 유지합니다. **실제 환경에서의 연결 안정성 강화** - 차량용 라우터를 사용하는 긴급 구조대원의 경우, 복잡한 NAT 트래버스나 우선순위 라우팅 층을 거치며 MTU가 급격히 줄어들 때 발생하던 CAD(컴퓨터 지원 파견) 시스템의 연결 끊김 현상을 방지합니다. - 해외 호텔이나 공공 네트워크를 사용하는 하이브리드 작업자는 이중 NAT나 노후화된 중간 장비가 있는 환경에서도 화상 회의나 파일 전송이 끊기지 않는 최적화된 경로를 수 초 내에 확보할 수 있습니다. - 이 기술은 애플리케이션 계층에서 하위 네트워크의 불안정성을 느끼지 못하도록 '스티키(Sticky)'한 연결 상태를 제공합니다. 현재 Windows, macOS, Linux 환경에서 MASQUE 프로토콜을 사용하는 Cloudflare One Client 사용자라면 누구나 이 기능을 무료로 이용할 수 있습니다. 네트워크 변동성이 큰 환경에서 업무를 수행하는 팀이라면 MASQUE 프로토콜 활성화를 통해 패킷 드롭 없는 안정적인 연결을 경험해 보기를 권장합니다.

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 광고 상태를 직접 제어함으로써 복구 시간을 단축할 수 있는 운영 매뉴얼을 숙지해 두는 것이 권장됩니다.

Route leak incident on January 22, 2026 (새 탭에서 열림)

2026년 1월 22일, Cloudflare 마이애미 데이터 센터에서 자동화된 라우팅 정책 설정 오류로 인해 약 25분간 IPv6 BGP 경로 유출(Route Leak) 사고가 발생했습니다. 특정 접두사 목록(Prefix-list)을 제거하는 과정에서 정책 필터가 의도치 않게 모든 내부 경로를 허용하게 되었고, 이로 인해 전 세계 IPv6 트래픽이 마이애미로 잘못 유도되어 네트워크 혼잡과 서비스 지연이 초래되었습니다. 이 사고는 자동화 코드가 생성한 구성 파일의 논리적 허점으로 인해 발생했으며, 운영진의 수동 복구와 자동화 일시 중지를 통해 해결되었습니다. ### BGP 경로 유출의 메커니즘과 영향 * **경로 유출의 정의**: 네트워크(Autonomous System, AS)가 원래 전달해서는 안 될 트래픽을 자신에게 보내도록 인터넷 경로 정보를 잘못 광고하는 현상을 의미합니다. * **위반 사항**: 이번 사고는 RFC 7908에 정의된 유형 3 및 유형 4 유출의 혼합 형태로, 피어(Peer)나 상위 제공자(Provider)로부터 받은 경로를 다시 다른 피어나 제공자에게 재분배함으로써 '계곡 없는 라우팅(Valley-free routing)' 원칙을 위반했습니다. * **네트워크 충격**: 마이애미 데이터 센터의 백본 인프라에 트래픽이 집중되면서 혼잡이 발생했고, Cloudflare 서비스뿐만 아니라 외부 네트워크의 트래픽도 마이애미로 유입되었다가 방화벽 필터에 의해 차단되거나 높은 지연 시간을 겪었습니다. ### 설정 오류의 기술적 원인: 과도하게 허용된 정책 * **변경 목적**: 보고타(Bogotá) 데이터 센터로 향하던 IPv6 트래픽을 마이애미를 거치지 않게 하기 위해, 정책 자동화 플랫폼을 통해 기존의 특정 접두사 목록(`6-BOG04-SITE-LOCAL`)을 제거하려고 했습니다. * **JunOS 동작 특성**: JunOS 및 JunOS EVO 운영체제에서 `from route-type internal` 조건은 모든 내부 BGP(iBGP) 경로와 일치합니다. * **논리적 결함**: 특정 접두사 필터가 삭제되자, 해당 정책 구문은 "모든 내부 경로를 수락하고 외부로 광고하라"는 광범위한 규칙으로 변질되었습니다. 이로 인해 마이애미 라우터는 수천 개의 내부 경로를 Telia, Cogent, GTT와 같은 외부 피어와 제공자에게 대량으로 전송하게 되었습니다. ### 사고 대응 타임라인 * **20:25 UTC**: 마이애미 에지 라우터에서 자동화 도구가 실행되어 잘못된 설정이 적용되었고, 즉시 경로 유출과 서비스 영향이 시작되었습니다. * **20:40 UTC**: 네트워크 팀이 의도치 않은 경로 광고를 감지하고 조사를 시작했으며, 4분 뒤 공식적인 장애 대응 프로세스가 가동되었습니다. * **20:50 UTC**: 네트워크 운영자가 문제가 된 설정을 수동으로 되돌리고 해당 라우터의 자동화를 일시 중지함으로써 경로 유출 상황이 종료되었습니다. * **22:40 UTC**: 자동화 코드 저장소의 버그를 수정한 후, 마이애미 라우터의 자동화 기능을 다시 활성화하여 정상 상태로 복구했습니다. ### 기술적 교훈 및 추천 사항 * **정책 검증 강화**: 라우팅 정책을 자동 생성할 때, 특정 필터(Prefix-list 등)가 제거된 결과가 '기본 허용(Default Accept)' 상태가 되지 않도록 방어적인 로직을 설계해야 합니다. * **운영체제 특성 이해**: JunOS의 `route-type internal`과 같이 벤더별로 상이하게 동작할 수 있는 매칭 조건을 사용할 때는 예상치 못한 경로 광고를 막기 위한 추가적인 안전장치(Safety-net)를 마련해야 합니다. * **단계적 배포**: 대규모 인프라 변경 시 자동화 도구가 전체 라우터에 동시에 적용되지 않도록 카나리(Canary) 배포나 단계적 적용을 통해 영향 범위를 최소화하는 것이 권장됩니다.

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)를 유지하는 것이 하위 호환성을 위해 필수적입니다. 시스템의 성능 최적화가 기존 생태계의 암묵적인 동작 원리를 깨뜨리지 않는지, 특히 표준 라이브러리 수준의 하위 호환성을 철저히 검증해야 함을 보여주는 사례입니다.