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