2019년 Route 53 DDoS와 DNS 완화 책임성

요약

보존된 AWS 후속 발표에 따르면 아마존(Amazon)은 2019년 10월 22일 Route 53에 대한 DDoS 공격을 탐지하고 완화했다. 공격은 특정 DNS 이름과 경로, 특히 S3 버킷의 글로벌 이름을 겨냥했다. 질의는 인터넷의 다른 지점에서 운영되는 재귀 리졸버를 통해 Route 53에 도달했다. [1]
AWS는 영향을 받은 리졸버를 운영하던 소수의 ISP가 자체 완화 전략을 적용했다고 밝혔다. 이 조치들로 인해 해당 리졸버를 통한 소수의 AWS 이름 조회가 실패했다. AWS는 완화 조치가 개선되도록 운영자를 식별하고 연락하고 있다고 말했다. [1]
당시 보도는 간헐적 해석 오류, 완화 과정에서 표시된 정상 질의, 퍼블릭 DNS에 의존하는 AWS 서비스 엔드포인트에 대한 영향을 전했다. 이후 보도는 AWS의 말을 인용해 간헐적 오류가 태평양 표준시(PDT) 오전 10시 30분부터 오후 6시 30분까지, 그리고 오후 5시 16분부터 매우 소수의 이름에서 더 높은 오류율로 나타났다고 전했다. 이 세부 사항은 인용된 보도이며 독립적인 완전한 패킷 기록이 아니다. [21]
Route 53의 문서화된 아키텍처는 다수의 엣지 로케이션, 다양한 연결성, 셔플 샤딩(shuffle sharding), 애니캐스트 스트라이핑을 사용한다. AWS는 필터링과 우선순위 기반 트래픽 셰이핑도 설명했다. 이러한 설계 진술은 가용한 방어를 설명하지만 2019년 사건 당시 모든 엣지, 리졸버, 규칙이 어떻게 작동했는지를 증명하지는 않는다. [2]
Whalebone의 독립 분석은 트래픽이 슬로우드립(slow-drip) 또는 무작위 서브도메인 패턴과 일치하는 것으로 보인다고 평가하고, 공격적인 DNSSEC 부정 캐싱을 가능한 방어로 논의했다. AWS는 보존된 후속 발표에서 이 특성을 확인하지 않았다. 이는 인용된 가설이며 확립된 근본 원인이 아니다. [22]
퍼블릭 DNS와 재귀 해석은 별개의 통제 표면이다. 퍼블릭 DNS 운영자는 존 데이터를 게시하고 제공한다. 재귀 리졸버는 퍼블릭 DNS 서버를 선택하고, 답을 캐시하고, 실패를 재시도하고, 로컬 정책을 적용한다. 대규모 애니캐스트 배치는 인터넷 라우팅과 고르지 않은 캐치먼트에도 의존한다. [11][19][20]
리졸버 방어는 부수적 장애를 만들 수 있다. 의심 트래픽의 차단, 레이트 리밋, 폐기, 리디렉션은 리졸버를 보존하면서 정상 요청을 억압할 수 있다. 오래된(stale) 데이터 제공은 일부 조건에서 연속성을 개선할 수 있지만 신선도를 가용성과 맞바꾸며, 이 사건에서 활성화되었다고 가정할 수 없다. [13]-[15]
Route 53의 레코드 수준 페일오버는 애플리케이션 이름을 엔드포인트 간에 옮길 수 있다. 이것만으로 독립적인 퍼블릭 DNS 공급자가 제공되지는 않는다. 고객은 엔드포인트 복원력과 통제면 다양성을 구분해야 한다. [9][10]
책임성은 실질적인 통제를 따른다. AWS는 Route 53의 퍼블릭 DNS 엣지와 자체 완화를 통제했고, 리졸버와 ISP 운영자는 로컬 규칙과 캐시를 통제했으며, 다른 네트워크는 출처 검증과 트래픽 전달을 통제했고, 고객은 실제 계약상 제약 안에서 의존성 매핑과 아키텍처를 통제했다.
복구 기준은 조율된 증거 사슬이다. 퍼블릭 DNS 응답률, 이름별·질의 클래스별 오탐, 애니캐스트 캐치먼트 상태, 리졸버 규칙 차이, 만료·롤백 기록, 다중 네트워크 프로브, 고객 대상 통지, 그리고 정상 이름이 회복되었다는 증명이 그것이다.

공개 기록은 완화 경계를 확인한다

가장 강한 사건별 출처는 SRE Weekly가 보존한 AWS 후속 발표다. 과거 AWS 상태 페이지는 탐색과 딥링크가 어려웠기 때문이다. 보존된 텍스트에 따르면 AWS는 2019년 10월 22일 Route 53에 대한 DDoS 공격을 탐지한 뒤 완화했다. 또한 질의가 인터넷 리졸버를 거쳐 Route 53으로 이동하면서 공격이 처음에는 다른 많은 DNS 서버 운영자에게 체감되었다고 말한다. 특정 DNS 이름과 경로, 특히 글로벌 S3 버킷 이름 접근에 쓰이는 경로가 겨냥되었다. [1]

다음 단락이 책임성의 분기점이다. AWS는 공격이 광범위하게 분산되어 있다고 설명했다. 영향을 받은 DNS 리졸버를 운영하던 소수의 ISP가 자체 완화 전략을 구현했다. AWS는 그 조치들이 해당 리졸버를 통한 소수의 AWS 이름 조회를 실패시키고 있다고 말했다. 완화 조치가 정상 요청에 영향을 주지 않도록 운영자를 식별하고 연락하며 협력하려 한다고 했다. [1]

이 진술은 단순한 장애 이상을 확립한다. 최소 두 개의 상이한 방어 영역을 확인한다.

Route 53의 퍼블릭 DNS 서비스가 적대적 트래픽을 탐지하고 완화했다.
재귀 리졸버 운영자가 영향을 보고 로컬 완화를 배치했다.

두 방어는 운영상 서로 바꿀 수 없었다. 리졸버 운영자는 자신의 질의 처리 용량, 상위 링크 또는 고객을 보호했을 수 있다. AWS는 퍼블릭 DNS 용량과 Route 53 뒤의 서비스 경로를 보호했다. 두 목적 모두 합리적일 수 있다. 장애는 한 규칙이 정상 트래픽을 적대적으로 분류하거나 실제 사용자가 필요로 하는 이름, 질의 패턴, 목적지, 응답을 차단할 때 발생한다.

당시 보도는 시간과 증상 기록을 더하지만 신중히 다뤄야 한다. The Register는 AWS 지원 메시지가 DDoS 공격을 언급했고 완화가 대부분 트래픽을 흡수하면서 일부 정상 고객 질의를 표시했다고 하며, 일부 S3 클라이언트에 대해 리전별 S3 엔드포인트 이름을 우회책으로 제안했다고 보도했다. 또한 퍼블릭 DNS 해석이 필요한 다른 AWS 서비스 엔드포인트에 간헐적 영향이 있었다고 전했다. 이후 업데이트에서 AWS의 말을 인용해 일부 AWS DNS 이름에 대한 간헐적 오류가 PDT 오전 10시 30분부터 오후 6시 30분까지 발생했고, 매우 소수의 이름은 오후 5시 16분부터 더 높은 오류율을 겪었다고 전했다. [21]

이 진술들은 완전한 인시던트 데이터셋을 제공하지 않는다. 모든 리졸버 운영자, 영향받은 모든 이름, 모든 완화 규칙을 식별하지 않는다. 모든 증상이 같은 원인을 가졌음을 증명하지도 않는다. 다만 책임성 분석이 "Route 53"을 자족적 상자로 다루지 않고 DNS 트랜잭션을 조직 전반에서 추적해야 하는 이유를 보여준다.

하나의 DNS 조회는 독립적으로 통제되는 여러 시스템을 거친다

사용자가 애플리케이션 이름을 입력할 때 보통 도메인의 퍼블릭 DNS 서버에 직접 질의하지 않는다. 기기의 스텁 리졸버가 재귀 리졸버에 질의를 보낸다. 그 리졸버는 캐시에서 답할 수 있다. 쓸 수 있는 캐시 답이 없으면 DNS 위임 사슬을 따라 퍼블릭 DNS 서버에 질의한다. RFC 1034와 RFC 1035가 이 과정의 개념과 메시지 동작을 정의한다. [19][20]

대규모 퍼블릭 DNS 운영자를 위해 쓰인 RFC 9199는 이 구분을 명확히 요약한다. 퍼블릭 DNS 서버는 존 내용을 알고 로컬 사본에서 답한다. 재귀 리졸버는 클라이언트를 위해 퍼블릭 DNS 서버와 다른 서버를 반복적으로 질의한다. 리졸버는 어느 가용 서버에 물을지, 지연이나 실패에 어떻게 반응할지 결정한다. [11]

따라서 트랜잭션은 여러 실질적 통제 지점을 넘는다.

도메인 보유자는 등록기관, 레지스트리, 공급자 인터페이스의 제약 안에서 레코드와 위임 선택을 통제한다.
퍼블릭 DNS 공급자는 존 제공, 엣지 용량, 응답 로직, 라우팅, 자체 공격 완화를 통제한다.
인터넷 라우팅은 재귀 리졸버를 퍼블릭 DNS 애니캐스트 인스턴스에 매핑하고 양방향 패킷을 전달한다.
재귀 리졸버는 캐싱, 재시도 동작, 서버 선택, 로컬 필터링, 레이트 리밋, 스텁에 돌려줄 응답을 통제한다.
접속 공급자는 링크, 출처 검증 정책, DNS를 제공하는 경우 리졸버 운영, 고객 소통을 통제한다.
애플리케이션 소유자는 소프트웨어가 해석 실패를 다루는 방식과 대체 엔드포인트나 의존성의 존재 여부를 통제한다.

이 경로 어느 단일 기록도 주권을 갖지 않는다. 호스티드 존에 정답이 있어도 리졸버에 답이 닿지 않을 수 있다. 네임서버 주소가 계속 광고되는 동안 도달한 엣지가 포화될 수 있다. 리졸버는 트래픽을 폐기하는 것으로 건강하게 유지되는 동안 애플리케이션이 접근 불가가 될 수 있다. 상태 페이지가 완화가 활성이라고 말하는 동안 사용자의 실행 코드는 여전히SERVFAIL, 타임아웃 또는 다른 실패를 볼 수 있다.

이것이 운영 현실 계층이 중요한 이유다. 기록, 티켓, 서비스 설명은 증거다. 실행 중인 DNS 경로가 사용자가 받는 결과다. 책임성은 둘을 조율하는 데서 나온다.

Route 53의 아키텍처는 방어를 설명하되 사건 그 자체를 설명하지 않는다

AWS는 2019년 공격 이전에 Route 53의 DDoS 복원력을 공개적으로 설명했다. 2016년 AWS 포스트는 서비스가 다수의 엣지 로케이션에서 실행되며 DNS 트래픽에 큰 글로벌 표면을 만든다고 했다. 각 엣지의 복수 인터넷 연결, 셔플 샤딩, 애니캐스트 스트라이핑을 설명했다. AWS의 설명에서 고객 위임 집합의 각 네임서버는 고유한 엣지 로케이션 집합에 대응해 고객 간 중첩을 줄인다. 한 네임서버가 불가하면 클라이언트가 다른 것을 재시도할 수 있다. 애니캐스트 스트라이핑은 요청을 분산하고 지연을 줄일 수 있다. [2]

AWS는 엣지 로케이션 전반의 결정적 패킷 필터링과 우선순위 기반 트래픽 셰이핑도 설명했다. [2] 이후 AWS 자료는 Route 53과 CloudFront가 글로벌 엣지 용량과 인라인 완화의 이점을 받는다고 했다. 2020년 위협 리뷰는 DNS 반사가 AWS Shield가 관찰한 흔한 인프라 계층 벡터로 남아 있으며, 애플리케이션 계층 요청 플러드는 더 적은 트래픽으로 과도한 처리 부담을 만들 수 있다고 했다. [3]

이 문서들은 통제 도구상자를 설명한다.

지리적·네트워크적 분산
복수의 퍼블릭 DNS 네임서버
애니캐스트 캐치먼트 분산
셔플 샤딩을 통한 고객 격리
다양한 연결성
필터링
트래픽 셰이핑
모니터링과 인라인 완화

그러나 2019년 10월 22일 어느 메커니즘이 실패했거나 성공했는지는 확립하지 않는다. 2016년 블로그는 사건 이전 것이지만 패킷 트레이스가 아닌 제품·아키텍처 설명이다. 2020년 리뷰는 사건 이후 것이며 Route 53 사후분석이 아닌 더 넓은 Shield 관찰을 다룬다. 현재 백서와 문서는 현재 지침이지 완전한 과거 통제 상태가 아니다. [2]-[7]

이 구분은 인시던트 글쓰기의 흔한 오류, 즉 공급자의 설계 설명을 모든 시점의 구현 증명으로 바꾸는 오류를 막는다. 강한 아키텍처도 고르지 않은 캐치먼트, 질의 클래스 사각지대, 오탐 필터, 조율 공백을 가질 수 있다. 방어의 존재는 가능성을 말할 뿐이다. 인시던트 증거는 실행 중인 시스템이 실제로 한 일을 보여야 한다.

애니캐스트는 부하를 분산하지만 관찰을 복잡하게 한다

대규모 퍼블릭 DNS 시스템은 흔히 복수의 네임서버 주소를 애니캐스트와 결합한다. 같은 서비스 IP 주소가 많은 물리 위치에서 광고될 수 있다. 그러면 인터넷 라우팅이 리졸버의 네트워크에서 보이는 경로에 따라 리졸버를 인스턴스에 매핑한다. [11]

이 아키텍처는 운영자에게 용량과 지리적 분산을 주지만 시스템을 균일하게 만들지는 않는다. RFC 9199는 리졸버 행동, 라우팅 연결성, 배치 설계가 어느 퍼블릭 DNS 서버와 인스턴스가 질의를 받는지에 영향을 준다고 밝힌다. 더 많은 위치가 잘 연결된 위치보다 자동으로 나은 것은 아니다. 캐치먼트는 고르지 않을 수 있고, 라우팅 변경은 단순 사이트 수로 예측하기 어려운 방식으로 인스턴스 간 부하를 옮길 수 있다. [11]

공격 상황에서 선택은 더 어려워진다. RFC 9199는 과부하 애니캐스트 인스턴스에 대한 두 가지 넓은 전략을 설명한다. 운영자는 경로를 철회·변경하거나 상위와 필터링을 조율하거나 다른 라우팅 기법으로 트래픽을 이동시킬 수 있다. 이는 정상·적대 트래픽을 다른 곳으로 옮겨 다른 사이트의 압박을 높일 수 있다. 또는 인스턴스가 저하된 흡수체로 남아 일부 정상 요청을 폐기하면서 공격 부하를 자신의 캐치먼트에 유지해 다른 인스턴스를 보호할 수 있다. 문서는 운영자가 두 전략을 준비하고 측정된 조건으로 선택하도록 권고한다. [11]

2019년 공개 기록은 어느 Route 53 인스턴스가 어느 전략을 썼는지 말하지 않는다. 캐치먼트 지도, 경로 변경, 엣지별 응답률을 제공하지 않는다. 이 빠진 증거는 서로 다른 네트워크의 사용자가 같은 시각에 다른 결과를 경험할 수 있으므로 중요하다.

따라서 방어 가능한 인시던트 기록에는 다음이 포함된다.

어느 퍼블릭 DNS 주소와 애니캐스트 인스턴스가 비정상 질의 부하를 받았는지
공격과 정상 트래픽이 리졸버 네트워크와 지역별로 어떻게 분산되었는지
경로가 철회, 프리펜드 또는 다른 방식으로 변경되었는지
각 조치 후 어느 캐치먼트가 이동했는지
인스턴스별 정상 응답, 타임아웃, 폐기, 오류율
재귀 리졸버가 이에 반응해 서버 선택을 바꿨는지
각 인스턴스와 리졸버 경로가 언제 정상으로 돌아왔는지

이 측정은 모든 사적 구성을 노출할 필요가 없다. 집계되고 시간 한정된 증거는 완화가 정상 서비스를 보존했는지, 부하 이동이 다른 곳에 새 장애를 만들었는지 보여줄 수 있다.

리졸버 완화의 역설

보존된 AWS 후속 발표는 일부 ISP 운영 리졸버가 도입한 완화가 소수의 AWS 이름에 대한 정상 요청을 실패시켰다고 말한다. [1] 이는 고전적인 방어 통제 역설이다. 통제가 한 위험을 줄이면서 다른 위험을 높일 수 있다.

비정상 트래픽에 직면한 재귀 운영자는 여러 계층에서 조치할 수 있다. 클라이언트, 이름, 질의 유형, 상위 목적지에 레이트 리밋을 걸 수 있다. 반복 미스를 억압하거나, 동시 상위 작업을 제한하거나, 재시도 동작을 바꾸거나, 패턴을 차단하거나, 서버 풀을 격리하거나, 트래픽을 리디렉션할 수 있다. AWS의 공개 진술은 조치를 식별하지 않으므로 정확한 규칙을 배정하는 것은 추측이다.

메커니즘이 무엇이든 네 가지 거버넌스 질문이 따른다.

첫째, 분류 단위는 무엇이었는가. 넓은 AWS 접미사를 겨냥한 규칙은 적대적 트래픽과 무관한 많은 이름에 영향을 줄 수 있다. 하나의 질의 형태를 겨냥한 규칙은 정상 소프트웨어와 충돌할 수 있다. 목적지 수준 차단은 리졸버를 보호하면서 퍼블릭 DNS 경로로의 모든 접근을 없앨 수 있다.

둘째, 정상 요청 검증은 무엇이었는가. 배치 전후로 운영자는 알려진 정상 이름, 질의 유형, DNSSEC 상태, 응답 크기의 고정 집합을 같은 실제 경로로 테스트할 수 있었다. 인프라 건강 검사는 통과하지만 실제 이름 해석은 실패하는 완화는 불완전하다.

셋째, 만료와 롤백 동작은 무엇이었는가. 시간 한계, 소유자, 제거 조건이 없는 비상 규칙은 위험을 누적한다. AWS가 운영자를 식별하고 연락해야 했다는 사실은 조율이 즉각적이지 않았음을 시사한다. 내구성 있는 규칙은 배치자, 이유, 매칭 트래픽, 만료 시점, 롤백을 승인하는 측정을 기록해야 한다.

넷째, 고객은 무엇을 배웠는가. ISP 리졸버가 실패를 돌려주는 동안 다른 리졸버가 성공하면 사용자는 접속 네트워크 문제, AWS 문제 또는 애플리케이션 문제를 볼 수 있다. 상태 설명은 진단 부담을 사용자에게 전적으로 떠넘기지 않으면서 퍼블릭 DNS 저하와 리졸버 로컬 차단을 구분해야 한다.

따라서 완화의 질은 공격 억압과 정상 서비스 보존 양쪽으로 측정된다. 정상 해석이 제거되었다면 "리졸버가 살아 있었다"는 것으로 충분하지 않다.

반사는 관련 맥락이지 입증된 원인이 아니다

DNS는 반사·증폭 공격에 자주 쓰인다. UDP는 출처 주소 위조를 허용하고 일부 DNS 질의는 요청보다 큰 응답을 낼 수 있기 때문이다. RFC 5358은 개방형 재귀 리졸버가 반사기로 악용될 수 있는 방법을 설명하고, 대규모 수신 필터링이 위조 출처 사용에 대한 근본 방어임을 강조한다. 재귀 서비스를 의도된 클라이언트로 제한하고 실용적이면 재귀와 퍼블릭 DNS 역할을 분리하도록 권고한다. [12]

RFC 2827과 RFC 3704는 일반 및 멀티홈 네트워크의 출처 주소 검증을 설명한다. 이 통제는 패킷이 무관한 네트워크에서 출발하거나 통과할 때 Route 53의 직접 권한 밖에 놓인다. DDoS 책임성이 피해 서비스를 운영하지 않는 네트워크까지 확장될 수 있는 이유를 보여준다. [17][18]

그러나 관련성은 증명이 아니다. 보존된 AWS 후속 발표는 사건을 광범위 분산으로 부르고 겨냥된 이름과 경로를 설명한다. 공격이 반사 공격이었다고 말하지 않고, 위조 출처를 식별하지 않고, 봇넷을 지명하지 않는다. 2020년 Shield 리뷰는 DNS 반사가 AWS 관찰에서 흔했다고 하지만 이는 이후의 집계 데이터셋에 관한 것이다. [1][3]

따라서 두 진술은 분리되어야 한다.

반사와 위조는 확립된 DNS DDoS 메커니즘이며 네트워크 운영자는 출처 검증 의무를 인정해 왔다.
가용한 공개 증거는 그 메커니즘이 2019년 10월 Route 53 사건을 일으켰음을 확립하지 않는다.

이 분리는 법적 신중함 이상의 의미가 있다. 잘못된 복구를 막는다. 지배적 부하가 위조되지 않은 애플리케이션형 무작위 이름 질의였다면 수신 필터링은 퍼블릭 DNS 처리 문제를 해결하지 못한다. 사건이 반사를 썼다면 이름 수준 캐싱만으로는 출처 검증을 다루지 못한다. 증거 기반 대응은 통제를 선언하기 전에 메커니즘을 식별한다.

슬로우드립 가설은 인용된 채로 머물러야 한다

Whalebone은 사건 3일 후 독립 분석을 발표했다. 공격자가 존재하지 않는 의사무작위 서브도메인에 대해 많은 질의를 퍼블릭 DNS 네임서버로 보내는 슬로우드립 패턴에 맞을 수 있다고 평가했다. 이름이 새로우므로 일반 긍정 캐싱의 효과가 줄고 퍼블릭 DNS 서비스가 미스를 반복 처리한다. Whalebone은 관찰한 트래픽에 시사적 질의가 포함되었으며 10월 19일의 이른 스파이크를 가능한 시험으로 간주했다고 보고했다. [22]

이 분석은 재귀 동작의 중요성에 대한 그럴듯한 메커니즘을 제공한다. 또한 NSEC 또는 NSEC3 레코드가 검증 리졸버가 모든 질의를 퍼블릭 DNS 서비스로 보내지 않고 추가 이름이 존재하지 않음을 추론할 수 있게 하는 공격적인 DNSSEC 검증 부정 캐시 정보 사용을 논의한다. [22]

이 가설에는 한계가 있다.

Whalebone은 AWS가 아니었다. 그 분석은 완전한 공유 데이터셋, 보편적 관찰 지점, AWS의 내부 텔레메트리를 공개하지 않는다. 보존된 AWS 후속 발표는 슬로우드립이라는 표현을 쓰지 않는다. 의사무작위 서브도메인, DNSSEC 상태, 시험 주기를 확인하지 않는다. 따라서 증거는 "Whalebone이 평가했다"는 표현을 지지하지, "공격이 그러했다"는 단정을 지지하지 않는다.

제안된 DNSSEC 조치에도 조건이 있다. 공격적 부정 캐싱은 서명된 부존재 거부 레코드, 올바른 검증, 호환 리졸버 동작을 요구한다. 입증된 범위 내 존재하지 않는 이름의 반복 퍼블릭 DNS 질의를 줄일 수 있다. 모든 DDoS 벡터에 대한 범용 필터가 아니다. 과부하 링크에 용량을 더하지 않고, 위조를 막지 않고, 실패한 경로를 복구하지 않고, 과도하게 넓은 리졸버 규칙을 고치지 않는다.

이 경계화된 다룸은 추측적 근본 원인 주장을 검증 가능한 증거 요청으로 바꾸므로 유용하다.

질의된 이름이 주로 존재하지 않는 의사무작위 이름이었는가
캐시 재사용이 불가능했기 때문에 어느 비율의 부하가 퍼블릭 DNS 서버에 도달했는가
관련 존이 서명되어 인증 거부가 가능했는가
어느 리졸버가 공격적 부정 캐싱을 지원했는가
그런 리졸버가 정상 답을 보존하며 상위 질의를 줄였는가
어떤 공격 클래스가 영향받지 않고 남았는가

책임 있는 운영자는 공급자 블로그를 최종 판정으로 다루지 않고도 이 질문들에 답할 수 있다.

캐싱은 신선도, 민첩성, 연속성을 맞바꾼다

캐싱은 DNS 복원력의 일부다. 리졸버가 매번 퍼블릭 DNS 서비스에 연락하지 않고 반복 질문에 답할 수 있기 때문이다. 더 긴 TTL은 퍼블릭 DNS 부하를 줄이고 짧은 중단 동안 답을 보존할 수 있다. 더 짧은 TTL은 계획된 변경과 트래픽 조향을 더 민감하게 만든다. RFC 9199는 복원력과 민첩성이 서로 다른 방향을 당기므로 모든 시스템에 적합한 단일 TTL이 없음을 강조한다. [11]

오래된 데이터 제공은 또 다른 옵션을 더한다. RFC 8767은 퍼블릭 DNS 서버에 도달할 수 없을 때 재귀 리졸버가 만료된 캐시 데이터를 설정된 한계와 운영 보호 안에서 사용하는 방법을 정의한다. [14] 목적은 답이 신선하다고 가장하는 것이 아니라 연속성이다.

RFC 8906은 진단 제약을 더한다. 리졸버 관점에서 답하지 않는 서버는 패킷 손실과 구분할 수 없을 수 있다. 타임아웃은 퍼블릭 DNS 프로세스가 실패했는지, 경로가 혼잡했는지, 애니캐스트 인스턴스가 철회되었는지, 필터가 교환을 폐기했는지 설명하지 않는다. [15]

이 메커니즘은 DDoS 동안 증거 문제를 만든다.

캐시된 답이 한 사용자에게 퍼블릭 DNS 실패를 숨기는 동안 캐시 미스가 다른 사용자에게 그것을 노출할 수 있다.
짧은 TTL은 질의 압박을 높이지만 더 빠른 엔드포인트 변경을 지원할 수 있다.
긴 TTL은 서비스를 보존하지만 운영자가 바꾸려는 답을 유지할 수 있다.
오래된 답은 안정된 엔드포인트에 대해서는 답이 없는 것보다 안전하지만 빠르게 바뀐 보안 또는 페일오버 레코드에 대해서는 안전하지 않을 수 있다.
부정 캐시는 무작위 이름 부하를 줄일 수 있지만 증명과 리졸버 동작이 올바를 때만 가능하다.

2019년 기록은 어느 리졸버가 오래된 데이터를 제공했는지, TTL을 무시했는지, 공격적으로 재시도했는지, 질의를 억압했는지 보여주지 않는다. 이는 발명할 사실이 아니라 조사 질문이다.

적절한 마감은 캐시 상태별 해석을 비교할 것이다. 운영자는 따뜻한 긍정 캐시, 콜드 캐시, 부정 캐시, 만료 캐시, DNSSEC 검증 경로를 테스트할 수 있다. 그런 뒤 같은 완화가 각 클래스의 정상 요청을 보존했는지 보고할 수 있다.

DNS 쿠키는 조건부 도구다

RFC 7873은 DNS 쿠키를 정의한다. 이 가벼운 메커니즘은 서버가 정상 클라이언트를 경로 밖 위조 출처 트래픽과 구분하도록 돕고 증폭 및 서비스 거부 악용에 어느 정도 저항을 제공하려는 것이다. [16]

이 메커니즘이 관련인 이유는 UDP 기반 DNS가 흔히 연결 핸드셰이크를 갖지 않기 때문이다. 패킷을 받는 서버는 출처 주소가 실제 요청자를 나타낸다고 자동 가정할 수 없다. 유효한 쿠키를 교환하는 클라이언트와 서버는 요청자가 주장된 주소에서 트래픽을 받을 수 있다는 더 큰 신뢰를 확립할 수 있다.

그러나 DNS 쿠키는 2019년 메커니즘의 증명도 아니고 보편적 답도 아니다. 양쪽에 배치가 존재해야 한다. 모든 고율 클라이언트를 선량하게 만들지 않고, 실제 클라이언트가 비싼 무작위 이름 질의를 내는 것을 막지 않으며, 서버 상위의 혼잡을 해결하지 못한다. 지원되지 않는 옵션을 무조건 요구하는 리졸버 완화는 그 자체로 정상 트래픽을 배제할 수 있다.

책임성 질문은 표준 문서의 존재가 아니다. 운영자가 어느 클라이언트가 메커니즘을 지원하는지, 어느 폴백 동작이 서비스를 보존하는지, 통제가 관찰된 공격 클래스에서 어떻게 작동하는지, 어떤 오탐 증거가 보존되는지 아는지이다.

이것이 실행 코드 우위의 또 다른 예다. 문서 속 프로토콜 옵션은 잠재력이다. 협상된 동작, 관찰된 트래픽, 측정된 결과가 운영 사실이다.

엔드포인트 페일오버는 퍼블릭 DNS 공급자 다양성이 아니다

Route 53은 헬스 체크와 DNS 페일오버 레코드를 지원한다. 애플리케이션 소유자는 기본과 보조 자원을 구성하고 헬스 체크를 연관시키고 설정된 정책 아래 Route 53이 건강한 대상으로 답하게 할 수 있다. [10]

유용한 애플리케이션 복원력이다. 그러나 그 자체로 Route 53의 퍼블릭 DNS 경로를 독립시키지는 않는다.

리졸버가 퍼블릭 DNS 서비스에서 답을 얻지 못하면 헬스 정책이 선택한 엔드포인트를 알 수 없다. 두 엔드포인트가 모두 건강해도 이름은 해석되지 않을 수 있다. 따라서 고객은 중복 컴퓨팅과 스토리지를 갖되 공통 DNS 통제 지점을 공유할 수 있다.

독립적인 퍼블릭 DNS 공급자는 그 공통 모드를 줄일 수 있지만 다른 의무를 만든다. 존 데이터는 일관되어야 한다. 위임과 글루는 정확해야 한다. DNSSEC 키와 서명은 일관된 모델이 필요하다. 헬스 의미가 공급자가 모순된 답을 돌려주게 해서는 안 된다. TTL, 변경 순서, 접근 통제, 인시던트 소유는 리허설이 필요하다. RFC 9199는 하나의 설계를 보편적으로 최적이라 다루지 말라고 경고한다. [11]

올바른 고객 질문은 "두 공급자를 쓰는가?"가 아니라 "어느 장애 도메인이 독립이고 무엇이 컷오버 작동을 증명하는가?"이다.

증거에는 다음이 포함될 수 있다.

실제로 독립된 네트워크와 통제면 위의 퍼블릭 DNS 네임서버
테스트된 존 동기화 또는 독립 관리되는 동등 레코드
공급자 변경을 통한 일관된 DNSSEC 검증
복수 접속 네트워크에서의 리졸버 측정
위임 변경을 위한 리허설된 의사결정 과정
이름이 실패하지만 엔드포인트는 도달 가능할 때의 애플리케이션 동작
여전히 등록기관, 레지스트리, 키, 자동화 또는 인력을 공유하는 의존성 문서

어떤 시스템에는 다중 공급자 DNS의 운영 비용과 위험이 이익을 넘을 수 있다. 다른 시스템에는 퍼블릭 DNS 집중이 용납할 수 없는 공통 모드다. 책임성은 그 결정을 명시하고 선택된 설계를 테스트하는 데 있다.

글로벌 S3 이름은 이름 짓기가 인프라임을 보여준다

AWS의 보존된 후속 발표는 공격이 특히 글로벌 S3 버킷 이름 접근에 쓰이는 경로를 겨냥했다고 말한다. [1] The Register는 AWS 지원이 일부 영향받은 고객에게 리전별 S3 엔드포인트 이름을 제안했고 다른 AWS 서비스 엔드포인트에 대한 퍼블릭 DNS 영향을 설명했다고 보도했다. [21]

이것이 중요한 이유는 서비스 이름이 편리한 레이블 이상이기 때문이다. 그것은 해석 경로, 통제면, 때로는 리전 또는 라우팅 정책을 선택하는 네트워크 인프라의 조각이다.

글로벌 이름은 애플리케이션 구성을 단순화하고 공급자가 배치를 관리하게 할 수 있다. 또한 이름 경로에 의존을 집중시킬 수도 있다. 리전별 이름은 하나의 영향받은 패턴을 우회하면서 애플리케이션을 리전 지식에 더 단단히 묶을 수 있다. 주소를 하드코딩하면 일시적으로 DNS 조회를 피하지만 주소 변경, 로드 밸런싱, 인증서 신원, 서비스 계약을 둘러싼 다른 실패를 만든다.

책임 있는 교훈은 DNS를 없애는 것이 아니라 링크와 서버만큼 진지하게 이름 의존성을 목록화하는 것이다.

각 중요 애플리케이션 호출에 대해 운영자는 다음을 알아야 한다.

클라이언트가 어느 이름을 해석하는지
평소 어느 재귀 리졸버를 쓰는지
어느 퍼블릭 DNS 공급자가 이름을 제공하는지
어느 캐시와 TTL 동작이 적용되는지
이름이 글로벌, 리전 또는 계정별인지
서비스 계약이 어느 폴백을 지원하는지
클라이언트가 작업을 훼손하지 않고 조회 실패를 다루는지
우회책이 어떻게 활성화되고 나중에 제거되는지

이 목록은 모호한 "클라우드 의존"을 구체적인 해석 사슬로 바꾼다.

책임성은 가시성만이 아니라 능력을 따른다

공격은 적대적이었지만 공격자의 신원과 책임이 책임성 분석을 소진하지는 않는다. 인프라 운영자는 사건을 시작하지 않았어도 예방, 억제, 오탐, 소통, 회복에 대한 통제를 유지한다.

Amazon Web Services

AWS는 Route 53의 퍼블릭 DNS 아키텍처, 엣지 용량, 서비스별 탐지, 자체 완화, 고객 통지, 리졸버 운영자와의 조율을 통제했다. 대부분 고객이 접근할 수 없는 수준에서 퍼블릭 DNS 질의 클래스와 응답률을 측정할 수 있었다. 또한 공개 기록에 등장한 글로벌 AWS 서비스 이름의 설계도 통제했다.

AWS는 모든 재귀 리졸버, ISP 필터, 고객 애플리케이션, 출처 네트워크를 통제하지 않았다. 엄밀한 기록은 영향받은 이름이 AWS 이름이었다는 이유만으로 그 결정들을 AWS에 배정해서는 안 된다.

재귀 리졸버 및 ISP 운영자

리졸버 운영자는 로컬 캐시, 재시도, 레이트 리밋, 필터, 서버 선택, 클라이언트에 돌려줄 답 또는 오류를 통제했다. AWS의 진술은 특히 일부 이름의 정상 질의 실패 원인으로 리졸버 측 완화를 지목한다. [1]

이 운영자들은 AWS의 내부 공격 분류에 대한 가시성이 적었을 수 있다. 그 정보 비대칭은 빠른 악용 연락처와 조율 경로의 필요성을 강화한다. 오탐을 테스트하고 비상 규칙을 만료시킬 의무를 제거하지는 않는다.

접속, 트랜짓, 출처 네트워크

트래픽을 운반한 네트워크는 용량, 라우팅, 필터링, 많은 경우 출처 주소 검증을 통제했다. BCP 38과 BCP 84가 안티스푸핑 책임을 설명한다. [17][18] 공개 기록은 위조 트래픽이 이 공격을 몰았음을 증명하지 않으므로 그 의무는 사건별 발견이 아니라 더 넓은 예방 계층으로 남는다.

고객

고객은 애플리케이션 의존성 매핑, 일부 환경에서의 리졸버 선택, 엔드포인트 구성, TTL 및 위임 아키텍처를 AWS와 다른 공급자가 노출한 옵션 안에서 통제했다. DNS 실패가 재시도, 저하된 기능, 큐 또는 완전 장애가 되게 할지 결정할 수 있었다.

고객은 Route 53의 엣지 완화나 ISP의 리졸버 규칙을 통제하지 않았다. "공동 책임"은 공급자가 통제한 실패를 고객에게 이전하는 문구가 되어서는 안 된다.

표준 및 소프트웨어 구현자

프로토콜 설계자와 리졸버·퍼블릭 DNS 서버 구현자는 쿠키, 오래된 데이터 제공, 부정 캐싱, 서버 선택 같은 가용 동작을 형성했다. 표준은 스스로 강제하지 않는다. 운영자가 배치 여부와 방식을 결정하고, 구현이 실제 동작을 결정한다.

악용 연락처는 운영 통제다

AWS는 완화를 개선하기 위해 리졸버 운영자를 식별하고 연락하고 있다고 말했다. [1] 이 문장은 기술 다이어그램이 흔히 생략하는 거버넌스 의존을 드러낸다. 인시던트는 Route 53만 바꿔서 완전히 복구될 수 없었다.

교차 운영자 대응은 정확한 연락처, 공유 증거, 행동 권한에 달려 있다. 감시되지 않는 악용 메일함, 낡은 연락처의 네트워크 기록, 느린 상업 지원으로만 접근 가능한 에스컬레이션 경로는 사용자에게 보이는 장애를 연장할 수 있다.

연락처 품질은 테스트할 수 있다.

리졸버 또는 네트워크의 현재 24시간 연락처가 있는가
보고자가 신원을 밝히고 인시던트를 인증할 수 있는가
양측이 불필요하게 고객 데이터를 노출하지 않고 지표를 교환할 수 있는가
수신 운영자가 규칙을 바꾸거나 제거할 권한이 있는가
조직 간 공유되는 인시던트 식별자가 있는가
각 조치가 타임스탬프화되고 측정과 상관될 수 있는가
주 채널이 응답하지 않을 때 폴백이 있는가

여기서 레지스트리와 디렉터리 정보가 실질적 가치를 갖는다. 기록 보관자는 운영자 신원과 연락처 메타데이터를 보존할 수 있다. 응답자가 답하게 하거나 리졸버가 정책을 바꾸게 할 수는 없다. 운영 시험은 기록된 경로가 가용한 시간 안에 행동을 만드는지이다.

소통은 실패한 계층을 설명해야 한다

DNS 인시던트는 증상이 실패한 통제에서 멀리 나타날 수 있어 고객에게 어렵다. 애플리케이션은 엔드포인트 타임아웃을 본다. 모니터링 시스템은 API 실패를 보고한다. 사용자는 빈 페이지를 본다. 리졸버 운영자는 비정상 질의량을 본다. 퍼블릭 DNS 공급자는 공격 트래픽과 응답 압박을 본다.

유용한 상태 통지는 과잉 주장 없이 계층과 불확실성을 식별해야 한다.

예를 들면:

퍼블릭 DNS 서비스가 DDoS 공격을 받고 있다
간헐적 실패가 경계된 이름 또는 경로 집합에 영향을 준다
일부 재귀 네트워크가 정상 질의를 거부할 수 있는 완화를 적용하고 있다
리전별 엔드포인트가 정의된 서비스에 대해 지원되는 임시 우회책이다
우회책에는 호환성과 롤백 조건이 있다
조사는 계속되며 공격 벡터는 아직 확인되지 않았다

이것은 "DNS 오류"보다 행동 가능하고 하나의 관찰 지점에서 보편적 회복을 선언하는 것보다 정직하다.

회복 소통은 퍼블릭 DNS 복구와 리졸버 정리를 구분해야 한다. Route 53 엣지가 올바르게 답하는 동안 리졸버가 차단, 실패 상태 또는 캐시된 결과를 유지할 수 있다. 다중 네트워크 프로브와 고객 보고가 종단 경로가 회복되었을 때 보여줄 수 있다.

DNS 완화를 위한 검증 행렬

이 사건은 구체적인 증거 프레임워크를 시사한다.

퍼블릭 DNS 서비스 상태

이름 클래스, 질의 유형, 응답 코드, 애니캐스트 인스턴스별 질의율
정상 응답, 타임아웃, 폐기율
용량과 포화 신호
소유자, 범위, 만료가 명시된 필터·셰이핑 변경
캐치먼트와 경로 변경
독립 네트워크의 알려진 정상 프로브 결과

재귀 리졸버 상태

캐시 히트, 캐시 미스, 상위 타임아웃,SERVFAIL율
비상 규칙 차이와 매칭 질의 수
알려진 정상 및 알려진 악성 테스트 케이스
재시도와 퍼블릭 DNS 서버 선택 동작
오래된 답 정책과 사용
롤백 시점과 제거 후 검증

네트워크 상태

각 퍼블릭 DNS 주소로의 도달 가능성
복수 접속 네트워크의 경로 및 패킷 손실 측정
관련한 출처 검증 자세
상위 필터링 요청과 기간
라우팅 변경 후 부하 이동의 증거

고객 상태

중요 이름 목록
리졸버 및 퍼블릭 DNS 의존성
글로벌 및 리전 엔드포인트 동작
실패 처리와 재시도 한계
지원되는 우회책과 롤백
지역과 접속 공급자별 사용자 가시 회복

조율 상태

공유 인시던트 식별자
연락 시도와 확인
교환된 증거
각 운영자의 결정 소유자
완화, 조정, 제거 시점
미해결 공백과 예정된 재테스트

이 행렬은 민감한 방어 공개와 일반적 보증만의 거짓 선택을 피한다. 운영자는 공격자를 돕는 서명을 드러내지 않으면서 경계된 지표, 규칙 변경 해시, 테스트 결과, 시간 범위를 보고할 수 있다.

복구의 증명은 어떤 모습인가

사후 약속은 반복된 훈련보다 약하다.

Route 53의 경우 증명에는 격리 또는 실제 안전 환경에서 대표적 적대 질의 클래스의 통제된 재현이 포함될 수 있다. 정상 질의가 정의된 오류 한계 안에서 계속 답을 받는다는 것을 보여주는 것이다. 애니캐스트 테스트는 한 인스턴스의 완화가 다른 인스턴스를 과부하시키지 않음을 보여줄 수 있다. 운영자는 규칙 버전, 카나리아 결과, 인스턴스별 측정, 자동 롤백 임계를 보존할 수 있다.

리졸버 운영자의 경우 증명에는 정상 AWS 글로벌 이름, 리전별 이름, 존재하지 않는 무작위 서브도메인, 큰 응답, DNSSEC 상태, 다양한 질의 유형을 담은 테스트 코퍼스가 포함될 수 있다. 제안된 비상 규칙은 목표 작업 부하를 억압하면서 알려진 정상 해석을 명시된 서비스 목표 안에 유지해야 한다. 규칙은 소유자와 만료를 가져야 한다.

교차 운영자 조율의 경우 테이블톱 또는 실제 안전 훈련은 퍼블릭 DNS 공급자의 인증된 경보로 시작할 수 있다. 리졸버 운영자는 수신을 확인하고, 텔레메트리에서 사건을 매칭하고, 경계된 변경을 배치하고, 측정을 돌려주고, 변경을 제거한다. 양측이 타임라인을 유지한다.

고객의 경우 회복 테스트는 정상 재귀 경로를 통한 해석을 비활성화하고, 애플리케이션 동작을 검증하고, 지원되는 대체 엔드포인트를 훈련하고, 폴백이 인증서 또는 신원 검사를 우회하지 않음을 확인할 수 있다. 테스트에는 비상 구성이 흔히 영구 부채가 되므로 롤백이 포함된다.

가장 강한 증거는 완벽한 예방 주장이 아니다. 시스템이 정상 서비스를 보존하면서 실패를 탐지, 억제, 되돌린다는 증명이다.

네트워크 인프라 명제가 제거될 수 없는 이유

이 책임성 사례는 기업 위기 관리에 대한 일반적 이야기가 아니다.

인과 사슬은 다음에 달려 있다.

분산 공격 아래의 퍼블릭 DNS 서비스
질의를 운반하고 캐시하는 재귀 리졸버
애니캐스트와 엣지 분산
네트워크별 완화 규칙
리졸버 측 오탐
DNS 위임과 서비스 이름 아키텍처
교차 운영자 연락처
종단 복구 측정

이 사실들을 제거하면 논증이 사라진다. 일반적 비즈니스 장애, 브랜드 평판 또는 내부 관리 문화에 관한 동등한 명제는 없다.

중심 원리는 실행 상태가 명목 기록보다 우선한다는 것이다. 도메인은 등록될 수 있다. 호스티드 존은 정확한 데이터를 가질 수 있다. SLA가 존재할 수 있다. 완화 티켓이 승인될 수 있다. 그 어떤 사실도 리졸버가 유효한 답을 받아 돌려준다고 보장하지 않는다.

기록은 여전히 중요하다. 위임, 연락처, 질의, 경로, 변경 기록은 운영자가 책임을 식별하고 사건을 재구성하게 한다. 그 권위는 실행 중인 시스템에 정확하고 쓸모 있다는 데서 온다, 그 시스템을 대체한다는 데서가 아니라.

따라서 운영 연속성은 전체 해석 경로의 성질이다. 고유하고 정확한 네트워크 신원, 보안 메타데이터, 작동하는 위임, 도달 가능한 퍼블릭 DNS 서버, 경계된 리졸버 동작, 조직 경계를 넘어 조율할 수 있는 응답자가 필요하다.

출처의 한계

SRE Weekly는 가장 중요한 AWS 후속 발표 텍스트를 보존하지만, 이는 완전한 AWS 사후분석이 아니라 상태 진술의 보관이다. 인용된 텍스트는 사건과 리졸버 측 완화 영향에 대한 AWS의 설명을 확립한다. 원시 텔레메트리, 리졸버 신원, 완전한 타임라인은 제공하지 않는다. [1]

AWS의 2016년 Route 53 및 Shield 포스트는 아키텍처와 완화 설계를 설명한다. 2020년 위협 리뷰는 이후의 집계 관찰을 제공한다. 현재 AWS 백서와 Route 53 문서는 통제와 고객 옵션을 설명한다. 어느 것도 2019년 10월 22일의 정확한 구성 또는 통제 사용을 증명하지 않는다. [2]-[10]

RFC 9199는 2022년에 출판되었다. 대규모 퍼블릭 DNS 운영에 관한 연구를 종합하고 유용한 애니캐스트, 라우팅, TTL 고려사항을 제공한다. 사건 보고서나 IETF 합의 표준이 아니다. [11]

나머지 RFC들은 메커니즘, 위험 또는 운영 관행을 정의한다. 반사, 위조, 오래된 데이터 제공, DNS 쿠키 또는 특정 완화가 사건 동안 존재했음을 확립하지 않는다. [12]-[20]

The Register는 당시 보도이며 시간 범위와 우회책 조언을 포함한 지원·상태 진술을 보존한다. 독립 패킷 트레이스가 아니며 보편적 영향을 추론하는 데 쓰여서는 안 된다. [21]

Whalebone은 독립 공격 패턴 분석을 제공한다. 그 슬로우드립 해석, 10월 19일 관찰, DNSSEC 부정 캐싱 제안은 인용된 주장으로 남는다. SRE Weekly가 보존한 AWS 진술은 이들을 확인하지 않는다. [22]

공개 출처는 다음을 확립하지 않는다.

완전한 공격 규모 또는 패킷률
공격자의 신원 또는 의도
봇넷 또는 위조 메커니즘
겨냥된 모든 이름
영향받은 모든 리졸버, ISP, 리전, 고객
각 정상 질의 실패를 일으킨 정확한 규칙
총 재정 손실
계약 위반 또는 서비스 크레딧
과실, 은폐 또는 규제 판정
이후 모든 통제의 내구성 있는 배치

이 불명들도 책임성 기록의 일부다. 더 강한 조사는 공백을 확신으로 채우는 대신 빠진 증거를 요청할 것이다.

결론

2019년 Route 53 DDoS는 완화가 분산 시스템 문제임을 보였다.

AWS는 대규모 퍼블릭 DNS 서비스를 통제하며 공격을 탐지하고 완화했다고 말했다. 리졸버 운영자는 자신의 인프라를 통해 사건을 보고 로컬 방어를 배치했다. 그 방어 일부는 정상 AWS 이름 조회를 실패시켰다. AWS는 규칙을 개선하기 위해 운영자를 식별하고 연락해야 했다. [1]

각 참여자는 자신이 시스템을 보호했다고 진실하게 말할 수 있었다. 사용자는 여전히 깨진 해석 경로를 경험했다.

따라서 책임의 기준은 종단이다.

퍼블릭 DNS 운영자는 공격 통제가 엣지와 캐치먼트 전반에서 정상 답을 보존함을 증명한다.
리졸버 운영자는 비상 규칙이 적대 작업과 정상 작업을 구분하고 안전하게 만료됨을 증명한다.
네트워크는 검증된 메커니즘에 맞는 출처 검증과 트래픽 통제를 배치한다.
고객은 자신의 애플리케이션이 어느 이름과 DNS 통제면에 의존하는지 이해한다.
상태 소통은 실패한 계층과 현재 지식의 한계를 식별한다.
교차 운영자 연락처가 레지스트리·디렉터리 기록을 시의적절한 운영 행동으로 바꾼다.

관련 증거는 관찰 가능한 상태다. 응답률, 규칙 매칭, 캐시 동작, 경로·도달 가능성 측정, 알려진 정상 프로브, 롤백 기록, 복수 네트워크의 사용자 가시 회복.

이 증거가 서비스 주장을 작동하는 통제로 바꾼다. 그것이 없으면 올바른 존 레코드와 활성 완화가 실패한 해석과 공존할 수 있다. 그것이 있으면 운영자는 자신의 인프라를 방어했을 뿐 아니라 공유 DNS 경로가 정상 사용자에게 계속 서비스했음을 보여줄 수 있다.

교훈은 "용량을 더 늘려라"보다 좁고 더 엄격하다. 용량이 중요하다. 애니캐스트가 중요하다. 캐싱이 중요하다. 프로토콜 방어가 중요하다. 어느 것도 단독으로 평가될 수 없다.

최종 시험은 조율된다. 안전한 대표 작업 부하를 생성하고, 퍼블릭 및 재귀 계층에 경계된 완화를 적용하고, 독립 네트워크에서 정상 이름을 검증하고, 캐치먼트와 캐시 영향을 관찰하고, 규칙을 롤백하고, 공통 타임라인을 유지한다. 시스템이 그 순서를 보여줄 수 없다면 완화는 주장으로 남는다. 보여줄 수 있다면 운영자는 방어와 연속성이 정렬되어 있음을 증명하는 것이다.

2019년 Route 53 DDoS 사태, DNS 완화 조율을 책임성 시험으로 만들다

왜 중요한가

요약