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