dns

15 개의 포스트

cloudflare

Cloudflare DDoS 위협 보고서 2026년 상반기: DNS 플러드와 지정학적 긴장으로 새로운 물결이 일며 1Tbps 공격 급증 (새 탭에서 열림)

Cloudflare의 2026년 상반기 DDoS 보고서는 공격 규모가 급격히 커지는 동시에, 공격 방식이 봇넷 기반 대량 트래픽에서 DNS·CLDAP 같은 반사·증폭 공격으로 이동하고 있다고 분석한다. 상반기에만 네트워크 계층 공격 2,320만 건과 HTTP DDoS 요청 29조 6,400억 건이 차단됐으며, 1Tbps 초과 공격은 935건에 달했다. 공격 대부분은 짧고 자동화되어 발생하므로 수동 대응이 아닌 상시 자동화 방어가 필수라는 것이 보고서의 결론이다. ## 2026년 상반기 DDoS 규모 - Cloudflare는 2026년 1~6월 동안 다음 공격을 완화했다. - 네트워크 계층 DDoS: 2,320만 건 - HTTP DDoS 요청: 29조 6,400억 건 - 시간당 약 5,343건, 하루 약 12만 8,000건의 네트워크 계층 공격이 발생했다. - 2026년 4월에는 공격량이 정점에 도달했다. - HTTP 요청 6조 4,600억 건 - 네트워크 트래픽 165PB - 이후 공격량이 감소한 것은 21개국이 참여한 Operation PowerOFF의 영향일 가능성이 있다. - DDoS 대행 서비스 이용자 7만 5,000명 이상 대상 - 도메인 53개 폐쇄 - 수색영장 25건 발부 - 4명 체포 ## 초대형 공격의 급증 - 1Tbps, 10억 패킷/초(Bpps), 100만 요청/초(Mrps)를 초과하는 공격을 초대형 DDoS로 분류한다. - 상반기 1Tbps 초과 네트워크 공격은 총 935건이었다. - 특히 2분기에는 805건이 발생해 전 분기보다 6배 이상 증가했다. - 1Tbps를 넘는 공격은 대규모 인터넷 인프라까지 압박할 수 있는 수준이다. ## 대부분은 작고 짧지만 충분히 치명적 - 네트워크 계층 공격의 96.62%는 500Mbps 미만이었다. - 90.60%는 10분 이내에 종료됐다. - 그러나 “작은 공격”도 일반적인 서비스에는 치명적일 수 있다. - 100Mbps: 서버나 웹사이트를 마비시킬 수 있는 수준 - 100Gbps: 보호되지 않은 대부분의 데이터센터를 오프라인으로 만들 수 있는 수준 - 1Tbps 이상: 주요 인터넷 인프라까지 위협하는 초대형 공격 - 공격자는 대역폭과 패킷 속도를 조합해 네트워크 장비 또는 회선 용량의 약점을 노린다. - 공격 시간이 수십 초에 불과한 경우도 있어, 보안 담당자가 경보를 확인한 뒤 수동으로 대응하는 방식은 현실적으로 늦다. - 짧은 공격도 라우팅 불안정, TCP 재전송, 애플리케이션 타임아웃, 하위 서비스 장애 같은 장기적인 후속 피해를 유발할 수 있다. ## 공격 산업: 미디어와 정부 부문 ### 미디어·출판 산업의 지속적인 표적화 - Media, Production & Publishing 부문은 1·2분기 모두 가장 많이 공격받은 산업이었다. - 전체 완화 HTTP DDoS 요청의 14.2%를 차지해 2위 산업보다 약 4배 많았다. - 이란과 우크라이나 전쟁 관련 보도, 월드컵 등 국제적 관심이 집중된 사건이 공격 증가에 영향을 준 것으로 분석된다. ### Operation Epic Fury 이후 정부 공격 증가 - 2026년 2월 28일 이스라엘과 미국이 이란 지도부 및 인프라를 대상으로 Operation Epic Fury를 시작했다. - 이후 72시간 동안 16개국 110개 조직을 대상으로 한 핵티비스트 DDoS 공격 주장이 149건 보고됐다. - 표적 조직의 약 47.8%가 정부 부문이었다. - 정부 부문은 공격 비중 순위가 1분기 29위에서 2분기 9위로 급상승했다. ## 공격받은 국가 및 지역 - 2분기 기준 가장 많이 공격받은 국가는 중국으로, 전 세계 HTTP DDoS 요청의 22.4%를 차지했다. - 미국은 18.8%로 2위를 유지했다. - 튀르키예는 공격 비중이 두 배 이상 증가하며 3위로 올라섰다. - 이 증가는 2026년 앙카라 NATO 정상회의를 앞두고 보안 당국이 대규모 단속을 진행한 시기와 겹쳤다. ## 공격 발생지 국가 - 브라질이 미국을 제치고 상반기 DDoS 트래픽의 최대 발생지로 나타났다. - 브라질: 14.9% - 미국: 13.4% - 브라질은 2분기에만 전체 완화 DDoS 요청의 21.4%를 차지했다. - 인도네시아는 두 분기 모두 3위를 기록하며 주요 DDoS 발생지로 남았다. ## 공격 벡터의 변화 ### DNS Flood와 DNS Amplification의 확대 - DNS 기반 공격은 상반기 네트워크 계층 공격의 34.3%를 차지했다. - DNS Flood는 봇넷이 피해자의 권한 있는 DNS 서버에 대량 질의를 보내 처리 용량을 고갈시킨다. - DNS가 마비되면 해당 도메인에 의존하는 웹사이트와 서비스가 함께 영향을 받는다. - DNS Amplification은 위조된 출발지 IP를 사용해 개방형 DNS 리졸버에 작은 질의를 보내고, 더 큰 응답이 피해자에게 전달되도록 만드는 반사·증폭 공격이다. - DNS Flood 비중은 1분기 25.7%에서 2분기 40.0%로 상승했다. ### CLDAP 증폭 공격의 폭증 - CLDAP Flood는 노출된 Active Directory LDAP-over-UDP 엔드포인트를 악용하는 반사·증폭 공격이다. - 2분기에 전 분기 대비 580% 증가했다. - 그 결과 CLDAP Flood는 2분기 네트워크 계층 공격 벡터 중 3위가 됐다. - 이는 공격 중심이 단순한 봇넷 트래픽 폭주에서, 개방형 서비스와 프로토콜의 증폭 특성을 악용하는 방식으로 이동하고 있음을 보여준다. ## 실용적인 대응 방향 - 공격이 짧고 빠르게 끝나므로 수동·온디맨드 대응만으로는 부족하다. - DNS 인프라, 네트워크 회선, 애플리케이션 계층을 모두 포함하는 상시 자동화 방어가 필요하다. - CLDAP·DNS 등 반사·증폭에 악용될 수 있는 인터넷 노출 서비스를 점검하고, 불필요한 UDP 서비스와 개방형 리졸버를 차단해야 한다. - 공격 직후에도 재전송, 타임아웃, 라우팅 불안정 등 후속 장애를 확인해야 한다.

cloudflare

2026년 월드컵이 인터넷 트래픽에 미친 영향 (새 탭에서 열림)

2026년 월드컵은 전 세계 사람들의 온라인 활동을 경기 시간과 관심도에 따라 크게 변화시켰다. Cloudflare는 전 세계 네트워크의 트래픽을 분석해, 심야 경기는 인터넷 사용량을 평소보다 두 배 이상 높인 반면 저녁 경기는 사람들이 기기를 내려놓으면서 트래픽을 감소시킬 수 있음을 보여줬다. 특히 아르헨티나 관련 경기가 세계 인터넷 활동에 가장 큰 영향을 미쳤고, 대회 기간 스포츠 베팅 사이트 트래픽도 뚜렷하게 증가했다. ## 월드컵 효과를 측정한 방법 - 국가별 인터넷 사용량은 규모 차이가 크기 때문에 단순한 요청량 대신, 각 국가의 최근 4주간 분당 트래픽 중앙값을 ‘평소’의 기준으로 삼았다. - 현재 트래픽과 기준 트래픽의 비율을 로그₂ 값으로 변환했다. - `0`: 평소와 동일 - `+1`: 평소의 2배 - `-1`: 평소의 절반 - 이 방식은 국가별 인터넷 규모가 달라도 증가와 감소를 대칭적으로 비교할 수 있게 한다. ## 경기 시작 시간이 온라인 활동에 미친 영향 - 자정부터 오전 8시 사이에 시작한 경기는 평소 인터넷 사용자가 적은 시간대에 열리므로 트래픽 증가폭이 가장 컸다. - 팬들이 늦게까지 깨어 있거나 일찍 일어나 경기를 시청하면서 일부 국가에서는 트래픽이 평소의 두 배를 넘었다. - 오전 9시부터 오후 중반까지의 경기는 사람들이 원래 온라인 상태인 시간대에 열려, 트래픽 변화가 크지 않았다. - 초저녁 경기는 평일에 작은 트래픽 증가를 유발했다. 평소 사용량이 줄어들기 시작하는 시간에 사람들이 계속 온라인에 머물렀기 때문이다. - 저녁 경기는 오히려 트래픽을 낮출 수도 있었다. 보스니아 헤르체고비나에서는 저녁 경기가 진행될 때 트래픽이 평소의 약 70%까지 떨어졌다. ## 같은 경기도 국가별로 정반대의 효과 - 브라질과 일본의 경기는 두 나라에서 12시간의 시차를 두고 시청됐다. - 일본에서는 경기가 한밤중에 열려 트래픽이 평소보다 약 두 배 높은 수준인 `+1` 부근까지 상승했다. - 브라질에서는 일상적인 활동 시간에 경기가 열려 트래픽이 평소보다 낮은 `-0.4` 정도를 기록했다. - 즉 경기가 인터넷 활동을 추가로 발생시키기도 하지만, 사람들이 평소 하던 웹 활동을 멈추고 경기에 집중하게 만들기도 했다. ## 세계 인터넷을 가장 크게 움직인 경기 - 각 경기 시작 후 2시간 동안 국가별 트래픽이 평소에서 얼마나 벗어났는지 계산했다. - 증가와 감소를 모두 ‘영향’으로 간주하기 위해 국가별 편차의 절댓값을 사용했다. - 동시 진행된 경기는 어느 경기가 트래픽 변화의 원인인지 구분하기 어려워 분석에서 제외했다. - 가장 큰 영향을 준 경기는 결승전이나 준결승전이 아닌 아르헨티나-스위스 8강전이었다. - 전 세계 트래픽 영향 계수: 약 `1.26` - 프랑스-스페인 준결승은 약 `1.21`로 뒤를 이었다. - 상위권에는 8강, 16강뿐 아니라 32강 경기까지 다양하게 포함됐다. ## 가장 큰 관심을 끈 팀 - 팀별로 해당 팀의 모든 경기가 각국 트래픽에 미친 영향을 집계했다. - 아르헨티나가 영향 계수 `1.17x`로 1위를 차지했다. - 아르헨티나 경기 때 일반적인 국가의 트래픽이 평소보다 약 17% 크게 움직였다는 의미다. - 디펜딩 챔피언이라는 지위와 리오넬 메시의 국가대표 마지막 무대 가능성이 관심을 높인 요인으로 해석됐다. - 프랑스, 브라질, 포르투갈, 모로코, 스페인, 노르웨이도 높은 순위를 기록했다. - 아이티와 이라크는 전체 트래픽 규모가 작아 주요 팀과의 경기에서 상대적으로 큰 변동률을 보인 특이 사례로 언급됐다. ## 스포츠 베팅 사이트 트래픽 증가 - 월드컵 개막 전 한 달과 비교했을 때 도박·스포츠 베팅 관련 웹사이트 요청량이 전반적으로 증가했다. - 대회 전에는 주중·주말에 따른 뚜렷한 주기성이 있었지만, 개막 이후에는 거의 매일 경기가 열리면서 트래픽 패턴이 일정하게 평탄화됐다. - 이는 월드컵이 경기 시청뿐 아니라 베팅과 같은 온라인 활동도 지속적으로 자극했음을 보여준다. ## 실용적인 시사점 - 글로벌 서비스는 이벤트 시간대를 현지 시간으로 변환해 트래픽 급증과 감소를 모두 대비해야 한다. - 심야 경기가 열리는 지역에서는 CDN, 서버 용량, 인증·결제 시스템의 과부하를 사전에 점검할 필요가 있다. - 반대로 사람들이 경기에 집중해 일반 웹사이트 이용을 줄이는 시간대에는 광고 노출이나 콘텐츠 게시 일정을 조정할 수 있다. - 국가별 시간대와 문화적 관심도를 함께 분석하면 단일한 글로벌 기준보다 훨씬 정확한 트래픽 예측이 가능하다.

cloudflare

Cloudflare 내부 DNS 정식 출시 (새 탭에서 열림)

Cloudflare Internal DNS는 퍼블릭 DNS와 프라이빗 DNS를 하나의 글로벌 플랫폼과 제어 평면에서 통합하는 서비스다. 이를 통해 스플릿-호라이즌 DNS의 동기화 문제를 줄이고, Zero Trust 정책·감사·가시성을 DNS에도 적용할 수 있다. Cloudflare Gateway를 사용하는 Enterprise 고객은 추가 비용 없이 사용할 수 있으며, 기존 DNS 어플라이언스와 클라우드별 DNS를 대체하는 것을 목표로 한다. ## 기존 내부 DNS 운영의 한계 - 퍼블릭 DNS, 사설 DNS, 클라우드별 DNS가 서로 다른 플랫폼에서 운영되는 경우가 많다. - 시스템마다 보안 정책과 관리 방식이 달라 전체 DNS 구성을 한눈에 파악하기 어렵다. - 스플릿-호라이즌 DNS에서는 같은 호스트명에 대해 내부 사용자와 외부 사용자에게 서로 다른 응답을 제공해야 한다. - 여러 DNS 환경의 레코드를 별도로 관리하면 설정이 서로 어긋나는 드리프트가 발생하고, 장애로 이어질 수 있다. - 레거시 DNS 장비는 하드웨어 교체 주기, 용량 확장, 유지보수 부담을 발생시킨다. ## Cloudflare Internal DNS의 핵심 가치 - 퍼블릭·프라이빗 DNS를 하나의 API, 감사 로그, 정책 관리 체계로 통합한다. - 공유된 존에 여러 DNS 뷰를 적용해 스플릿-호라이즌 DNS를 중복 구성 없이 구현한다. - Cloudflare Gateway의 사용자·기기 기반 정책으로 어떤 DNS 뷰를 사용할지 제어한다. - DNS 질의 필터링, 라우팅, 로깅을 기존 Zero Trust 정책과 동일한 체계로 관리한다. - 1.1.1.1을 운영하는 글로벌 인프라를 활용하므로 별도 장비 설치나 용량 사전 확보가 필요 없다. ## 두 가지 핵심 구성 요소 - **Gateway Resolver** - DNS 재귀 조회와 정책 평가를 담당한다. - 질의를 차단하거나 특정 업스트림으로 전달할 수 있다. - 유연한 조건식, 로깅, 감사 기능을 제공한다. - 정책에 따라 내부 DNS 뷰 또는 퍼블릭 DNS 경로를 선택한다. - **Internal Authoritative DNS** - 프라이빗 리소스의 권한 있는 DNS 레코드를 제공한다. - 애플리케이션, 서비스 엔드포인트, 데이터베이스 등의 내부 존을 관리한다. - Cloudflare의 기존 권한 있는 DNS 플랫폼 위에서 동작한다. ## 주요 객체: 존, 뷰, 리졸버 정책 - **Internal Zone** - 내부 리소스의 권한 있는 레코드를 저장한다. - 예: `corp.internal`, `db.corp.internal`. - **DNS View** - 특정 사용자·기기 그룹이 볼 수 있는 존과 레코드의 해석 맥락을 정의한다. - 내부 사용자에게는 사설 주소를, 외부 사용자에게는 퍼블릭 주소를 제공하는 데 사용된다. - **Resolver Policy** - Gateway에서 질의를 평가하고 특정 DNS View로 전달한다. - 조건에 따라 질의를 허용, 차단하거나 퍼블릭 DNS로 보낼 수 있다. - **Zone Reference** - 하나의 공유 존을 여러 뷰에서 재사용한다. - 동일한 레코드를 뷰마다 복사하지 않으므로 중복과 설정 불일치를 방지한다. ## DNS 질의 처리 과정 - 클라이언트의 질의는 먼저 Gateway Resolver에 도착한다. - 리졸버 정책이 내부 뷰를 지정하면 해당 질의는 Internal Authoritative DNS로 전달된다. - 정책이 질의를 차단하면 응답 없이 삭제된다. - 일치하는 정책이 없으면 1.1.1.1을 통해 퍼블릭 DNS 계층에서 조회한다. - 내부 뷰에서 이름을 찾지 못할 경우 퍼블릭 DNS로 폴백하도록 구성할 수 있어, 클라이언트는 내부·외부 이름을 구분할 필요가 없다. ## DNS 변경 사항의 전파 - 대시보드, Terraform, 직접 API 호출 등 모든 변경은 동일한 DNS Records API를 거친다. - 하나의 쓰기 경로를 사용하므로 변경 이력과 감사를 일관되게 관리할 수 있다. - 변경 내용은 Cloudflare 핵심 데이터센터에 저장되고 검증된 뒤 글로벌 네트워크로 복제된다. - 관련 캐시가 무효화되므로 TTL 만료를 기다리지 않고 수 초 내에 변경 사항이 반영된다. - Terraform 변경도 대시보드나 API 변경과 동일한 전파 경로를 따른다. ## 설정 방법 - Cloudflare 대시보드의 **Networking → Internal DNS**에서 시작한다. - 일반적인 구성 순서는 다음과 같다. 1. 내부 존 생성 2. 내부 DNS 레코드 생성 3. DNS View 생성 후 존 연결 4. Gateway Resolver Policy를 만들어 특정 트래픽을 해당 뷰로 라우팅 - 예시로 `corp.internal` 존을 만들고 `db.corp.internal`을 `10.0.1.50`으로 지정할 수 있다. - Cloudflare API와 Terraform을 모두 사용할 수 있다. - 현재 Cloudflare Gateway를 사용하는 Enterprise 고객이 이용 대상이다. ## Connectivity Cloud와의 통합 - 다음과 같은 DNS 연결 방식과 함께 사용할 수 있다. - Cloudflare One Client(WARP) - DNS over HTTPS(DoH) - DNS over TLS(DoT) - 표준 DNS 53번 포트 - PAC 파일 배포 - Cloudflare WAN - Cloudflare WAN을 사용하면 개별 단말에 One Client를 설치하지 않아도 연결된 네트워크의 장치가 내부 호스트명을 조회할 수 있다. - 원격 사용자, 지사, 데이터센터, 클라우드 환경을 하나의 제어 평면으로 연결해 일관된 DNS 경험을 제공한다. - Internal DNS는 독립적인 DNS 제품이라기보다 Zero Trust와 네트워크 연결을 포함한 Cloudflare Connectivity Cloud의 기능 확장이다. 내부·외부 DNS를 여러 시스템에서 따로 운영하고 있다면, 공유 존과 DNS View를 중심으로 구성을 통합하는 것이 유용하다. 특히 Cloudflare Gateway와 WAN을 이미 사용 중인 조직은 별도 DNS 장비를 줄이고, 정책·감사·전파 경로를 단일화하는 방안을 검토할 만하다.

cloudflare

잘못된 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 전환 절차를 철저히 검증해야 한다.

github

GitHub Copilot이 GitHub Pages에서 DNS 설정을 전혀 필요 없게 만드는 방법 (새 탭에서 열림)

GitHub Copilot CLI와 Namecheap API를 연동하면 DNS 레코드를 직접 수정하지 않고도 GitHub Pages 사이트를 사용자 도메인에 연결할 수 있다. 글에서는 저장소 생성부터 도메인 등록, DNS 설정, HTTPS 적용 및 배포 확인까지 약 14분 만에 완료하는 과정을 소개한다. 핵심은 Copilot CLI의 Namecheap 스킬이 API를 통해 DNS 작업을 자동화하되, 실제 변경 전에는 사용자 승인을 받는다는 점이다. ## GitHub Pages 사이트 만들기 - 공개 GitHub 저장소를 생성한다. - Copilot CLI에 원하는 결과를 설명해 `index.html`과 랜딩 페이지를 만들도록 한다. - GitHub Pages 활성화도 Copilot CLI를 통해 처리할 수 있다. - 우선 `github.io` 주소로 사이트가 배포되며, 이후 사용자 도메인을 연결한다. ## 저렴한 도메인 등록 - 비싼 `.com` 도메인이 아니어도 사이드 프로젝트를 시작할 수 있다. - 글에서는 `.click` 최상위 도메인을 사용했다. - `ghpagesblog.click` 도메인을 약 2달러에 등록했다. ## Namecheap API 활성화 - Namecheap의 **Profile → Tools → Business & Dev Tools → Namecheap API Access**로 이동한다. - API를 활성화한다. - API를 호출할 컴퓨터의 공인 IP를 **Whitelisted IPs**에 추가한다. - 발급된 API 키를 안전하게 보관한다. - API 키는 이후 Copilot CLI가 Namecheap 계정과 DNS를 관리할 때 사용한다. ## Copilot CLI에 Namecheap 스킬 설치 - 다음 명령으로 Namecheap 자동화 스킬을 설치한다. ```bash gh skill install github/awesome-copilot namecheap --scope user ``` - Copilot CLI에 Namecheap 도메인 목록 조회 등을 요청하면 사용자 이름과 API 키를 입력하도록 안내한다. - 인증 정보가 설정되면 계정의 도메인 목록을 반환해 API 연결이 정상인지 확인할 수 있다. - API 키는 로컬에 저장되므로 보관 위치와 접근 권한에 주의해야 한다. ## DNS 레코드 자동 설정 - Copilot CLI에 특정 Namecheap 도메인을 GitHub Pages 사이트에 연결하도록 요청한다. - 자동화 스킬은 DNS를 변경하기 전에 사용자에게 승인을 요청한다. - 기존 Namecheap 주차(parking) 또는 리디렉션 레코드를 제거하고 GitHub Pages에 필요한 설정으로 교체한다. - 루트 도메인에는 GitHub Pages의 A 레코드를 설정한다. - `www` 서브도메인에는 GitHub Pages를 가리키는 CNAME 레코드를 설정한다. - 저장소에도 `CNAME` 파일을 커밋해 GitHub Pages가 해당 사용자 도메인에 응답하도록 구성한다. ## 배포 및 도메인 확인 - Copilot CLI는 설정이 끝났다고 가정하지 않고 도메인 해석 상태를 직접 확인한다. - DNS가 올바르게 GitHub Pages를 가리키는지 검증한다. - GitHub Pages의 사용자 도메인 설정과 실제 사이트 연결 상태를 함께 확인하는 방식이다. - 글의 목표는 DNS 전파와 HTTPS 적용을 포함한 전체 배포 과정을 수동 설정 없이 완료하는 것이다. 실용적으로는 GitHub Pages와 Namecheap을 사용하는 개인 프로젝트에서 이 방식을 활용할 수 있다. 다만 DNS 레코드 삭제·교체와 API 키 사용이 포함되므로, 자동화 도중 표시되는 변경 내용을 반드시 검토하고 승인하는 것이 좋다.

cloudflare

Cloudflare DMARC 관리 기능이 이제 정식 출시되었습니다 (새 탭에서 열림)

Cloudflare DMARC Management가 무료 서비스에서 정식 출시(GA)로 전환되며, 도메인의 이메일 인증 상태를 한곳에서 확인하고 DMARC 적용 단계를 안전하게 높일 수 있도록 개편되었습니다. SPF·DKIM·DMARC·BIMI 상태와 발신 소스를 분석해 인증 실패나 위조 발신을 파악하고, `p=none`에서 `p=quarantine`, `p=reject`로 전환할 때 발생할 수 있는 문제를 줄이는 것이 핵심입니다. 이를 통해 전문 컨설턴트나 XML 보고서 수작업 분석 없이도 도메인 보호와 이메일 전달률 개선을 지원합니다. ## 이메일 인증의 역할 - **SPF**는 도메인을 대신해 이메일을 보낼 수 있는 IP 주소와 서비스를 지정합니다. - **DKIM**은 이메일에 암호화 서명을 추가해 전송 중 메시지가 변조되지 않았는지 검증합니다. - **DMARC**는 SPF와 DKIM을 연결하고, 인증 실패 메일을 허용·격리·거부할지 정책으로 지정합니다. - DMARC 보고서를 통해 어떤 발신자가 도메인을 사용하고 있는지도 확인할 수 있습니다. - **BIMI**는 지원되는 받은편지함에 브랜드 로고를 표시하며, 이를 사용하려면 강력한 DMARC 정책이 필요합니다. - 네 가지 설정이 올바르면 도메인 사칭 메일을 차단하고 정상 메일의 전달 가능성을 높일 수 있습니다. ## DMARC가 필수가 된 배경 - Google, Microsoft, Yahoo 등 주요 메일 제공업체가 최근 이메일 인증 요구사항을 강화했습니다. - DMARC·SPF·DKIM이 없거나 잘못 설정된 도메인은 정상적인 메일도 스팸 처리되거나 거부될 수 있습니다. - 이메일 인증 문제는 브랜드 사칭뿐 아니라 고객 커뮤니케이션 실패와 매출 손실로 이어질 수 있습니다. - 과거의 권장사항이었던 DMARC가 이제는 도메인에서 이메일을 보내기 위한 사실상 필수 조건이 되었습니다. ## DMARC 적용 단계의 불확실성 - `p=none`은 모니터링만 수행하고 인증 실패 메일을 차단하지 않습니다. - `p=quarantine`은 의심스러운 메일을 스팸함으로 보냅니다. - `p=reject`는 인증되지 않은 메일을 완전히 차단합니다. - 너무 빨리 정책을 강화하면 외부 이메일 서비스나 누락된 발신 시스템의 정상 메일이 중단될 수 있습니다. - 반대로 전환을 지나치게 늦추면 도메인 사칭과 이메일 전달률 저하 위험이 계속됩니다. - 기존에는 XML 집계 보고서를 분석하고 모든 정상 발신 소스를 직접 식별해야 했지만, Cloudflare는 이를 셀프서비스 방식으로 단순화하는 것을 목표로 합니다. ## 발신 소스 조사 기능 - DMARC 보고서에서 발신 서비스와 함께 **소스 IP 주소**를 확인할 수 있습니다. - 각 발신 소스가 DMARC, SPF, DKIM 정렬(alignment)을 통과했는지 또는 실패했는지 한눈에 볼 수 있습니다. - IP 주소를 Cloudflare의 **Investigate** 탭에서 직접 조회할 수 있습니다. - Investigate 탭에서는 다음 정보를 제공합니다. - IP 평판 - 지리적 위치 - ASN(자율 시스템 번호) - 악성 활동과의 알려진 연관성 - 이에 따라 보고서가 단순한 통계 자료가 아니라 정상 인프라와 무단 발신자를 구분하는 조사 도구로 활용됩니다. ## 이메일 인증 레코드 통합 점검 - DMARC, DKIM, SPF, BIMI 레코드 상태를 하나의 화면에서 확인할 수 있습니다. - 각 레코드는 자동 분석을 통해 **통과·경고·실패** 상태로 표시됩니다. - 레코드별 상세 결과와 수정 권장사항을 확인할 수 있습니다. - 점검 항목에는 다음이 포함됩니다. - **SPF**: 중복 레코드, DNS 조회 제한 초과, 허용 범위가 지나치게 넓은 `+all`, 누락된 메커니즘 - **DKIM**: 키 형식 오류 또는 잘못 구성된 키 - **BIMI**: 강력한 DMARC 정책을 갖췄지만 BIMI 레코드가 없는 경우 - 안내 문구는 RFC 전문 용어보다 이해하기 쉬운 평이한 표현으로 제공되어, 다음 조치를 쉽게 판단할 수 있도록 설계되었습니다. ## 실용적인 활용 방향 먼저 Cloudflare DMARC Management에서 SPF·DKIM·DMARC·BIMI 상태와 발신 IP를 점검하고, 실패한 소스가 실제 사용 중인 외부 서비스인지 확인하는 것이 좋습니다. 정상 발신 흐름을 모두 파악한 뒤 `p=none`에서 단계적으로 정책을 강화하면, 정상 메일 중단 위험을 줄이면서 최종적으로 `p=reject` 수준의 도메인 보호에 도달할 수 있습니다.

cloudflare

이란의 인터넷이 부분적으로 복구됐음을 Cloudflare Radar 데이터가 보여준다 (새 탭에서 열림)

이란의 인터넷은 약 3개월간 이어진 전국적 차단 이후 2026년 5월 26일부터 부분적으로 복구되기 시작했다. Cloudflare Radar는 트래픽과 DNS 요청이 크게 증가했지만, 최대치가 차단 이전 활동량의 40%에 그쳐 완전한 복구는 아니라고 분석했다. 특히 테헤란과 주요 통신망에 회복이 집중됐고, IPv6 연결은 여전히 사실상 중단된 상태다. ## 첫 번째 전국 인터넷 차단 - 2026년 1월 8일경 첫 번째 전국적 인터넷 차단이 시작됐다. - 이란발 트래픽은 거의 0에 가까운 수준으로 떨어졌다. - 1월 21일과 25일에 일시적으로 트래픽이 회복됐지만 곧 다시 감소했다. - 이후 1월 27일부터 비교적 완전한 회복이 나타났다. ## 두 번째 장기 차단 - 미국과 이스라엘의 공격이 시작된 2월 28일, 두 번째 전국적 차단이 발생했다. - Cloudflare Radar는 현지 시간 오전 10시 30분경부터 트래픽이 급격히 감소한 것을 관측했다. - 트래픽은 기존 수준의 1% 미만으로 떨어졌으며, 소량의 웹·DNS 트래픽만 외부로 전달됐다. - 이 차단은 약 3개월 동안 지속됐다. ## 5월 26일부터 나타난 부분 복구 - 5월 26일 11:00 UTC경부터 웹 트래픽과 DNS 요청이 동시에 증가했다. - 11:45 UTC에 짧은 급증이 있었고, 12:00 UTC 이후에는 꾸준한 증가세가 나타났다. - 직전 일주일과 비교하면 Cloudflare 네트워크를 통과한 데이터량이 약 15배 증가했다. - 밤 시간대에는 트래픽이 감소하고, 5월 27일 현지 오전 6시 30분경부터 다시 증가하는 일중 변동 패턴도 관측됐다. - 이는 실제로 더 많은 사용자가 웹사이트와 온라인 서비스에 접속하기 시작했다는 신호다. ## 테헤란과 주요 통신사에 집중된 회복 - 새로 증가한 HTTP 요청의 91.6%가 수도 테헤란에서 발생했다. - 다른 지역에서도 소폭 증가했지만 테헤란만큼 뚜렷하지 않았다. - Iran TCI, IranCell, RighTel, MCCI 등 주요 인터넷 사업자에서도 트래픽 증가가 나타났다. - Cloudflare는 각 통신망을 ASN(자율 시스템 번호) 단위로 구분해 트래픽 변화를 측정했다. ## DNS 요청 증가가 보여주는 접속 회복 - Cloudflare 공개 DNS 리졸버인 `1.1.1.1`에 대한 요청도 크게 증가했다. - DNS 요청은 사용자가 웹사이트나 온라인 서비스를 찾을 때 발생하므로, 인터넷 이용자 활동의 회복을 보여주는 지표가 된다. - 트래픽 증가와 DNS 요청 증가는 단순한 네트워크 신호가 아니라 실제 사용자 접속이 늘고 있음을 뒷받침한다. ## 아직 제한적인 복구 수준 - 5월 26일 트래픽 최고치는 2026년 관측된 차단 이전 최대 활동량의 약 40%에 불과했다. - 따라서 이번 변화는 전국 인터넷의 완전한 정상화가 아니라 부분적인 복구로 해석된다. - 1월에도 잠시 회복된 뒤 다시 차단된 사례가 있었기 때문에, 현재의 증가세가 일시적일 가능성도 있다. - 향후 며칠간 트래픽이 계속 증가해 차단 이전 기준선에 접근하는지가 중요하다. ## IPv6는 여전히 사실상 중단 - 이란의 발표된 IPv6 주소 공간과 IPv6 트래픽은 여전히 거의 0에 가까운 상태다. - 반면 IPv4 주소 공간 발표는 두 차례의 차단 기간에도 비교적 안정적으로 유지됐다. - IPv4 주소가 글로벌 라우팅 테이블에서 제거되지 않았다는 점은, 이번 차단이 단순한 라우팅 철회 방식이 아니었음을 시사한다. - 애플리케이션 필터링이나 허용 목록(whitelisting) 같은 방식으로 특정 서비스와 연결을 제한했을 가능성이 있다. 이번 변화는 이란의 인터넷이 회복 국면에 들어섰다는 중요한 신호지만, 아직 정상화로 보기는 어렵다. 향후 트래픽 규모, 지역별 분포, IPv6 주소 공간의 복구 여부를 함께 관찰해야 하며, 사용자는 서비스 접근이 다시 제한될 가능성도 고려해야 한다.

cloudflare

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 또는 동등한 예외 메커니즘을 마련하는 것이 권장된다. 단, 검증 우회는 장애 범위와 원인이 명확할 때만 일시적으로 적용하고, 복구 즉시 해제해야 한다.

cloudflare

1.1.1.1 공개 DNS 리졸버를 위한 지속적인 개인정보 보호 약속 (새 탭에서 열림)

Cloudflare는 1.1.1.1 공용 DNS 리졸버 출시 8주년을 맞아 독립적인 외부 기관을 통해 실시한 개인정보 보호 실사 결과를 발표했습니다. 이번 검토를 통해 사용자 데이터를 제3자에게 판매하지 않고 소스 IP 주소를 25시간 내에 삭제한다는 핵심 원칙이 여전히 철저히 준수되고 있음을 재확인했습니다. 기술적 환경 변화 속에서도 투명성을 유지함으로써 사용자 신뢰를 강화하고 업계의 개인정보 보호 표준을 선도하겠다는 의지를 보여줍니다. **독립적 검토를 통한 신뢰성 확보** - 2020년 첫 실사 이후 기술 스택의 규모와 복잡성이 증가함에 따라, Big 4 회계법인을 통해 시스템 전반에 대한 두 번째 독립 검토를 완료했습니다. - 단순한 선언을 넘어 외부 전문가의 객관적인 검증을 통해 1.1.1.1의 개인정보 보호 제어 장치가 실제 운영 환경에서 약속대로 작동하고 있음을 입증했습니다. - DNS 쿼리 데이터를 다른 Cloudflare 데이터나 제3자 데이터와 결합하여 개별 사용자를 식별하지 않는다는 약속을 기술적으로 뒷받침하고 있습니다. **핵심 개인정보 보호 원칙의 재확인** - **데이터 판매 및 공유 금지**: 사용자의 개인정보를 제3자에게 판매하거나 공유하지 않으며, 광고 타겟팅 목적으로 데이터를 활용하지 않습니다. - **최소 정보 원칙**: 요청 내용(What)만 처리하며, 요청자가 누구인지(Who) 식별할 수 있는 정보는 보관하거나 사용하지 않습니다. - **신속한 데이터 삭제**: 사용자의 소스 IP 주소는 익명화 처리를 거친 후 25시간 이내에 시스템에서 영구적으로 삭제됩니다. **운영의 투명성과 기술적 예외 사항** - **네트워크 문제 해결**: 전체 트래픽의 최대 0.05%에 해당하는 무작위 샘플링 패킷은 네트워크 트러블슈팅 및 공격 방어 목적으로만 제한적으로 사용됩니다. - **익명화 데이터 활용**: Cloudflare Radar와 같은 연구 및 분석 서비스를 위해 익명화된 로그 데이터를 활용하지만, 이는 개인 식별이 불가능한 구조 내에서 이루어집니다. - **범위의 집중**: 이번 조사는 개인정보 보호 약속에 초점을 맞추어 진행되었으며, 기술적 변화 속에서도 개인의 프라이버시에 영향이 없음을 확인했습니다. 인터넷 사용자의 활동이 추적되지 않아야 한다는 철학 아래, Cloudflare는 기술적·제도적 장치를 통해 1.1.1.1 리졸버의 안전성을 지속적으로 증명하고 있습니다. 개인정보 보호와 속도를 동시에 확보하고자 하는 사용자라면, 독립적인 검증을 마친 1.1.1.1 DNS를 기본 리졸버로 설정하여 사용하는 것을 추천합니다.

cloudflare

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

cloudflare

케이블 절단, 폭 (새 탭에서 열림)

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와 같은 실시간 모니터링 도구를 활용하여 인프라 이상 징후에 신속히 대응할 수 있는 복원력을 갖추어야 합니다.

cloudflare

CNAME이 먼저인가 A 레 (새 탭에서 열림)

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

cloudflare

이란의 인터넷 차단에 대해 우리가 (새 탭에서 열림)

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의 트래픽 및 라우팅 페이지를 통해 지속적으로 모니터링할 수 있습니다.

datadog

언제나 DNS 문제다... (새 탭에서 열림)

제공된 내용에는 본문이 아니라 Datadog 웹사이트의 메뉴와 링크 목록만 포함되어 있어, 기술 블로그 글의 주장이나 기술적 세부사항을 정확히 요약할 수 없습니다. 링크 주소상 글은 **gRPC의 DNS 및 로드 밸런싱 관련 장애 분석 글**로 보이지만, 본문 없이 내용을 추정하면 부정확할 수 있습니다. 글의 본문을 붙여 주시면 요청하신 형식에 맞춰 다음과 같이 정리해 드리겠습니다. - 핵심 주장과 결론을 2~4문장으로 요약 - DNS 해석, gRPC 로드 밸런싱, 장애 원인 등 섹션별 설명 - 구체적인 기술적 원인과 대응 방법 - 실용적인 운영 권장사항

datadog

언제나 DNS 문제다… 그렇지 않은 경우를 제외하면: gRPC, Kubernetes, AWS 네트워킹 심층 분석 (새 탭에서 열림)

데이터독(Datadog)의 엔지니어들이 서비스 업데이트 중 발생한 원인 불명의 DNS 에러를 추적하며, 쿠버네티스 네트워킹과 AWS VPC 환경의 복잡한 상호작용을 해결해 나가는 과정을 다룬 글입니다. 로그상으로는 단순한 DNS 문제처럼 보였으나, 실제 원인은 AWS VPC의 연결 추적(conntrack) 한계와 하위 네트워크 레이어의 패킷 드랍에 있었습니다. 이 글은 고도화된 인프라 환경에서 단순히 리소스를 증설하는 것보다 커널 수준의 메트릭과 VPC 플로우 로그를 통한 심층 분석이 왜 중요한지를 잘 보여줍니다. **DNS 오류의 표면적 원인과 NodeLocal DNSCache** * 서비스 배포 시마다 DNS 에러가 발생하여 쿼리 지연과 모니터링 성능 저하가 나타났습니다. * 쿠버네티스의 `node-local-dns`가 메모리 부족(OOM) 및 최대 동시 요청 수(`max_concurrent`) 제한인 1,000개에 도달하여 요청을 거부하는 현상이 발견되었습니다. * 하지만 실제 초당 쿼리 수(QPS)는 예상 용량보다 훨씬 낮았으며, 이는 상위 DNS 리졸버와의 TCP 연결 실패로 인해 타임아웃이 발생하면서 동시 요청 슬롯이 빠르게 점유되었기 때문임이 밝혀졌습니다. **AWS VPC 연결 추적(conntrack)과 패킷 드랍** * 네트워크 성능을 정밀하게 확인하기 위해 AWS ENA(Elastic Network Adapter) 메트릭을 분석한 결과, `conntrack_allowance_exceeded` 수치가 급증한 것을 확인했습니다. * VPC 수준의 연결 추적 테이블(Hypervisor 레벨)이 포화 상태에 도달하면 보안 그룹 등의 상태 저장을 위한 연결 생성이 불가능해져 패킷이 드랍됩니다. * 특이하게도 인스턴스 내부의 리눅스 conntrack 엔트리는 6만 개 미만으로 안정적이었으나, VPC 레벨의 conntrack은 이미 한계에 도달하여 두 레이어 간의 가시성 차이가 존재함을 발견했습니다. **VPC 플로우 로그를 통한 심층 분석** * 인스턴스 유형을 상위 모델로 변경하여 임시적으로 문제를 해결할 수 있었으나, 근본 원인 파악을 위해 VPC 플로우 로그 분석을 병행했습니다. * Cilium, 쿠버네티스, AWS 네트워킹이 결합된 환경에서는 역경로 필터링(Reverse Path Filtering)이 정상적인 패킷을 'Martian packet'(출처가 불분명한 패킷)으로 오인하여 드랍하는 등 복잡한 문제가 발생할 수 있음을 시사했습니다. * DNS 전파 시간과 네트워크 마이크로버스트(Traffic Spikes) 역시 이러한 연결 추적 테이블 포화에 기여하는 핵심 요소임을 확인했습니다. **실용적인 결론** 단순히 로그에 나타나는 "DNS 에러"에만 집중하기보다, AWS ENA 메트릭의 `conntrack_allowance_exceeded`나 VPC 플로우 로그와 같은 하위 레이어의 지표를 함께 모니터링해야 합니다. 특히 대규모 쿠버네티스 클러스터를 운영한다면, 인스턴스 크기에 따른 VPC 수준의 conntrack 제한 수치를 미리 파악하고 적절한 인프라 사이징과 네트워크 정책 설정을 검토해야 합니다.