{"id":"IL-0494","org":"Netlify","date":"2016-08-22","docs":[],"title":{"en":"Netlify's central load balancer IP stopped responding when Rackspace null-routed it in a DDoS, and A-record sites hung","ko":"DDoS 중 호스팅 사업자가 중앙 로드 밸런서 IP를 null route 해 A 레코드로 Netlify를 가리킨 사이트가 응답하지 않았다"},"domain":["networking","security"],"impact":{"scope":"All sites with an A record pointed at Netlify's central load balancer IP; naked domains used as primary domains were hit hardest","users":"Netlify users with A records pointed at the load balancer IP","region":"unknown"},"review":{"written_by":"session","reviewed_at":null,"reviewed_by":null},"lessons":{"en":"Netlify judged Rackspace's load balancer too vulnerable to DDoS and Rackspace's DDoS processes not up to the standard of other cloud providers, and expected Google's anycast-based Maglev load balancer to be more resilient. In the end, the only way to protect a domain from DDoS-related outages is not to expose any fixed IP address for it, which is why sites should use the www domain with a CNAME, or Netlify DNS, rather than a single A-record IP.","ko":"관리형 로드 밸런서를 쓰는 한 DDoS 대응은 Netlify가 손댈 수 없었다. Rackspace의 로드 밸런서는 DDoS 공격에 너무 약했고 DDoS 대응 절차도 함께 일하는 다른 클라우드 사업자에 못 미쳤다. 결국 도메인을 DDoS 장애에서 지키는 유일한 방법은 그 도메인에 고정 IP 주소를 아예 드러내지 않는 것이다. 단일 IP에 기대지 않고 www 도메인을 주 도메인으로 쓰는 것이 성능과 가동 시간에 중요하다. 상태 페이지 게시 체계는 가장 필요할 때 불안정했다."},"related":[],"sources":[{"url":"https://www.netlify.com/blog/2016/08/23/august-22nd-ddos-learning-review/","kind":"blog","archived":"https://web.archive.org/web/20260716172948/https://www.netlify.com/blog/2016/08/23/august-22nd-ddos-learning-review/"}],"summary":{"en":"Netlify served sites in two ways: through the Netlify CDN, with points of presence worldwide and traffic routed to the closest location, and through a central load balancer whose IP users can target with A records when their DNS provider cannot set a CNAME on a naked domain. Until August 22, 2016 that load balancer was provisioned in Rackspace's Chicago datacenter. When DDoS traffic overwhelmed it, Rackspace null-routed it, and handling the attack was out of Netlify's hands because the load balancer was a managed one.\n\nWith no timeline from Rackspace, Netlify started a new cluster of CDN machines in Google Compute behind a Google network load balancer based on Maglev. Clients who had contacted support were given the new public IP and told to change their A records to bring their naked domains back online, and once the setup proved robust, Netlify updated its documentation and announced the new IP on Twitter, Gitter and its status page. Updating the status page took longer than it should have, because its separate publishing system, built on an external CI provider, S3 and Cloudfront, turned out to be fragile.","ko":"Netlify는 사이트를 두 방식으로 내보낸다. 하나는 Netlify CDN이다. Netlify CDN은 전 세계에 PoP를 두고, 사용자를 지리적으로 가장 가까운 곳으로 보내는 트래픽 라우팅 체계를 갖췄다. 다른 하나는 DNS 사업자가 네이키드 도메인에 CNAME, ANAME, ALIAS 레코드나 CNAME flattening을 지원하지 않는 사용자가 A 레코드로 가리킬 수 있게 공개한 중앙 로드 밸런서 IP다. 2016-08-22까지 이 로드 밸런서는 Rackspace의 시카고 데이터센터에 있었다.\n\n8월 20일 토요일 밤 중앙 로드 밸런서로 들어오는 전송량이 크게 늘었고, Netlify는 용량을 더하고 Rackspace에 물었지만 걱정할 수준이 아니라는 답을 받았다. 8월 22일 월요일 오전 8시 PST에 로드 밸런서가 응답을 멈췄고, Rackspace가 DDoS 때문에 로드 밸런서를 null route 해 공개 IP로 가는 트래픽이 서버에 닿기 전에 멈춰 있었다. 관리형 로드 밸런서라 DDoS 대응은 Netlify가 손댈 수 없었고, Rackspace는 복구 예상 시각도 공격 정보도 주지 못했다.\n\nNetlify는 Rackspace에 문제를 올리는 동시에 Google Compute에 새 CDN 클러스터를 띄우고, Maglev 기반 Google 네트워크 로드 밸런서를 가리키는 새 공개 IP를 연락해 온 고객에게 알려 A 레코드를 바꾸게 했다. 이 방법이 안정적이라고 확신한 뒤 문서를 고치고 Twitter, Gitter, 상태 페이지에 새 IP를 알렸다. 상태 페이지는 Netlify로 띄울 수 없어 외부 CI, S3, CloudFront로 따로 만든 게시 체계를 썼는데, 이 체계가 불안정해 상태 페이지가 제때 갱신되지 않았다."},"trigger":{"en":"A DDoS attack against Netlify's central load balancer in Rackspace's Chicago datacenter, after which Rackspace null-routed the load balancer's public IP.","ko":"DDoS 트래픽이 Rackspace 시카고 데이터센터에 있던 Netlify 중앙 로드 밸런서로 몰렸고, Rackspace가 그 로드 밸런서의 IP를 null route 했다."},"severity":"unknown","symptoms":["network-unreachable"],"timeline":{"detected_after":null,"resolved_after":null},"date_kind":"incident","detection":{"en":"Alerts at 8am PST reported that the central load balancer had stopped responding, and Rackspace then confirmed it had null-routed the load balancer.","ko":"2016-08-22 월요일 오전 8시 PST에 중앙 로드 밸런서가 응답을 멈췄다는 알림을 받았다. 이틀 전 토요일 밤에는 로드 밸런서의 트래픽 패턴에서 들어오는 전송량 급증을 먼저 알아챘다."},"components":["cloud-load-balancer"],"root_cause":"cloud-provider","remediation":[{"text":{"en":"Started a new cluster of CDN machines in Google Compute behind a Google network load balancer","ko":"Rackspace에 문제를 올리는 동시에 Google Compute에 새 CDN 서버 클러스터를 띄우기 시작했다."}},{"text":{"en":"Gave clients who had contacted support the new public IP and told them to change their A records","ko":"새 CDN 클러스터가 준비되자 지원 채널로 연락해 온 고객에게 Google 네트워크 로드 밸런서를 가리키는 새 공개 IP를 알리고, 네이키드 도메인을 되살리도록 A 레코드를 바꾸게 안내했다."}},{"text":{"en":"Updated the documentation and announced the new IP on Twitter, Gitter and the status page","ko":"새 IP가 안정적인 해법이라고 확신한 뒤 문서 페이지를 고치고 Twitter, Gitter, 상태 페이지에 새 IP를 알렸다."}}],"action_items":[{"text":{"en":"Keep the new Google-based network IP running in place of the Rackspace load balancer","ko":"Google 기반의 새 네트워크 IP를 계속 운영한다."}},{"text":{"en":"Release Netlify's own DNS hosting, integrated with the CDN, so domains do not depend on a fixed IP","ko":"Netlify CDN과 밀접하게 통합된 자체 DNS 호스팅을 내놓는다. Netlify DNS를 쓰면 중간 CNAME이나 A 레코드 없이 사용자를 가장 가까운 활성 CDN 노드로 보낸다."}},{"text":{"en":"Fix the status page publishing process so it is updated straight away during an issue","ko":"상태 페이지 게시 과정을 고쳐 앞으로 문제가 생기면 상태 페이지가 바로 갱신되게 했다."}},{"text":{"en":"Build a mailer that sends targeted mails to all paying clients during an outage","ko":"장애 때 유료 고객 모두에게 대상을 골라 메일을 빨리 보낼 수 있는 메일 발송 도구를 만든다."}}],"contributing":["single-point-of-failure","limited-debug-access"],"recurrence_of":null,"symptoms_text":{"en":"At 8am PST on Monday, August 22, 2016, Netlify got alerts that its central load balancer, the single public IP that users point A records at, had stopped responding. Rackspace had null-routed the load balancer, so all traffic to that IP hung before it reached Netlify's servers.\n\nEvery site with an A record pointed at that IP was affected to some degree, and sites that used a naked domain with an A record as their primary domain were hit the hardest. Sites served through the Netlify CDN with a CNAME did not go through this load balancer.\n\nTwo days earlier, on the night of Saturday, August 20, the load balancer had shown a sharp surge in incoming transfer with no matching rise in outgoing requests. Netlify added capacity behind the load balancer and asked Rackspace whether the traffic was legitimate or the start of a DDoS attack; Rackspace said the level of traffic was nothing to worry about. During the outage, even after escalating to the account manager, Netlify could get no ETA and no data on the size or type of the attack.","ko":"2016-08-22 월요일 오전 8시 PST에 Netlify 중앙 로드 밸런서가 응답하지 않는다는 알림이 왔다. 로드 밸런서의 공개 IP로 가는 트래픽은 서버에 닿기 전에 멈춘 채 응답이 없었다.\n\nA 레코드로 로드 밸런서 IP를 가리킨 모든 사용자가 어느 정도 영향을 받았다. 네이키드 도메인을 A 레코드로 걸어 주 도메인으로 쓴 사이트가 가장 크게 영향을 받았다.\n\n이틀 전인 8월 20일 토요일 밤에 중앙 로드 밸런서로 들어오는 전송량이 크게 늘었지만 나가는 요청은 그만큼 늘지 않았다. 팀은 로드 밸런서 뒤에 용량을 더하고 Rackspace에 정상 트래픽인지 DDoS 공격의 시작인지 물었고, Rackspace는 걱정할 수준이 아니라고 답했다.\n\nRackspace에 연락하고서야 Rackspace가 로드 밸런서를 null route 했다는 것을 알았다. 복구 예상 시각과 공격의 규모와 종류를 물었고 계정 관리자에게까지 올렸지만 구체적인 정보를 얻지 못했다."},"updated_at":"2026-11-14T12:34:13.906016Z","url":"https://benchlet.com/incidentlib/app/cases/IL-0494","org_slug":"netlify"}