들어가며: DNSSEC 장애는 왜 특별히 치명적인가?
DNSSEC은 DNS 응답의 무결성을 보장하기 위한 필수 보안 프로토콜입니다. 하지만 이 프로토콜은 '단일 실패 지점(Single Point of Failure)'이라는 치명적인 약점을 갖고 있습니다. 루트 존에서부터 시작되는 신뢰 사슬(Chain of Trust)의 한 고리만 끊어져도, 해당 TLD 아래의 모든 도메인이 일시에 먹통이 될 수 있습니다.
2026년 7월 3일, 알바니아의 국가 최상위 도메인 .al에서 DNSSEC 키 롤오버가 실패하면서 이런 최악의 시나리오가 현실이 됐습니다. 정부 서비스, 은행, 미디어 등 알바니아의 온라인 인프라 대부분이 영향을 받았고, Cloudflare의 공개 DNS 리졸버인 1.1.1.1을 사용하는 사용자들도 예외는 아니었습니다.
이 글에서는 이번 사건을 통해 드러난 DNSSEC 운영의 어두운 면, 특히 Negative Trust Anchor(NTA) 적용 시 발생하는 '투명성 부재' 문제를 해결하기 위해 도입된 Extended DNS Error(EDE) 코드 33에 대해 자세히 살펴보겠습니다. 단순한 장애 보고가 아니라, DNS 생태계의 신뢰성과 투명성을 높이기 위한 중요한 아키텍처적 개선 과정을 함께 이해할 수 있을 것입니다.
사건 분석: .al DNSSEC 롤오버 실패의 전말
1. 무슨 일이 벌어졌나?
.al 운영 기관(AKEP)이 DNSSEC 키 롤오버를 시도했지만, 새 키(DNSKEY)를 게시하면서 이전 키를 제거하는 과정에서 문제가 발생했습니다. 루트 존의 DS 레코드는 여전히 이전 키(id=26319)를 가리키고 있었기 때문에, 검증을 수행하는 모든 리졸버는 .al 응답에 대한 검증에 실패하고 SERVFAIL을 반환했습니다.
2. 왜 장애가 장기화됐나?
장애 발생 후 약 3시간 동안 아무도 문제를 해결하지 못했습니다. 운영 기관의 연락처 주소조차 .al 도메인 아래에 있었기 때문에, 연락 자체가 불가능했기 때문입니다. 결국 Cloudflare는 사용자 피해를 최소화하기 위해 RFC 7646에서 정의된 Negative Trust Anchor(NTA) 를 1.1.1.1에 적용했습니다.
3. NTA는 무엇이고, 어떤 문제가 있었나?
NTA는 리졸버가 특정 존을 '서명되지 않은 존'으로 취급하여 DNSSEC 검증을 일시적으로 건너뛰도록 하는 메커니즘입니다. 이를 통해 사용자는 SERVFAIL 대신 정상적인 DNS 응답을 받을 수 있게 됩니다.
하지만 치명적인 문제가 하나 있었습니다. NTA가 적용된 응답은 DNSSEC 검증을 통과한 정상 응답과 클라이언트 입장에서 구분할 수 없었습니다. 즉, 사용자는 응답이 스푸핑(spoofing)된 것인지, 아니면 실제 정당한 응답인지 알 수 없었던 것입니다.
# NTA 적용 전: 검증 실패로 SERVFAIL 반환
$ dig @1.1.1.1 google.al
;; ->>HEADER<<- opcode: QUERY; status: SERVFAIL; id: 12345
;; QUESTION SECTION:
;google.al. IN A
# NTA 적용 후: 응답은 오지만, 검증 여부를 알 수 없음
$ dig @1.1.1.1 google.al
;; ->>HEADER<<- opcode: QUERY; status: NOERROR; id: 12346
;; ANSWER SECTION:
google.al. 300 IN A 142.251.142.196
위 코드에서 볼 수 있듯이, NTA 적용 후의 응답은 일반적인 정상 응답과 완전히 동일합니다. 이것이 문제의 핵심이었습니다.
해결책: EDE 코드 33 (Disclosure of Negative Trust Anchors)
RFC 8914에서 정의된 Extended DNS Error(EDE) 코드는 DNS 응답에 추가적인 컨텍스트를 담을 수 있게 해줍니다. Cloudflare와 Quad9의 Babak Farrokhi는 이 메커니즘을 활용하여 NTA 적용 사실을 응답에 직접 명시하는 새로운 EDE 코드를 제안했습니다.
실제 응답 예시
# .al 장애 기간 중 1.1.1.1에 질의한 결과
$ kdig @1.1.1.1 google.al
;; ->>HEADER<<- opcode: QUERY; status: NOERROR; id: 32848
;; Flags: qr rd ra; QUERY: 1; ANSWER: 1; AUTHORITY: 0; ADDITIONAL: 1
;; EDNS PSEUDOSECTION:
;; Version: 0; flags: ; UDP size: 1232 B; ext-rcode: NOERROR
;; EDE: 9 (DNSKEY Missing): 'no SEP matching the DS found for al.'
;; EDE: 33 (Negative Trust Anchor): 'a Negative Trust Anchor has been applied for this query (see RFC 7646)'
;; ANSWER SECTION:
google.al. 300 IN A 142.251.142.196
위 응답에서 두 가지 중요한 정보를 확인할 수 있습니다.
- EDE 9 (DNSKEY Missing): 근본적인 DNSSEC 검증 실패 원인을 알려줍니다.
- EDE 33 (Negative Trust Anchor): 이 응답이 NTA에 의해 서빙되었으며, DNSSEC 검증을 통과하지 않았음을 명시합니다.
이 두 정보를 함께 제공함으로써, 클라이언트와 운영 도구는 응답의 신뢰성을 정확히 평가할 수 있게 됐습니다.
주의사항 및 심화 팁
- NTA 적용 범위: NTA는 해당 존 전체에 적용되므로, DNSSEC을 사용하지 않는 도메인에 대한 응답에도 EDE 33이 포함될 수 있습니다. 이는 의도된 동작이며, 투명성 원칙에 부합합니다.
- 기존 EDE 코드와의 충돌: 이전
.de사건에서는 1.1.1.1이 EDE 22(No Reachable Authority)를 잘못 반환했지만, 이번에는 EDE 9와 33을 정확히 반환하여 문제를 개선했습니다. - 도입 상태: EDE 33은 IANA에 등록되었으며,
kdig도구는 이미 이름으로 인식합니다. Unbound에 대한 PR도 검토 중입니다. 다른 리졸버 구현체들의 채택이 기대됩니다.
결론: 투명성이 곧 신뢰성
이번 .al 사건은 DNSSEC 운영에서 NTA가 얼마나 중요한 도구인지, 그리고 동시에 얼마나 위험할 수 있는지를 보여줍니다. NTA는 장애 상황에서 서비스 연속성을 유지하는 데 필수적이지만, 사용자에게 검증이 생략됐다는 사실을 알리지 않으면 보안 사고로 이어질 수 있습니다.
EDE 33은 이 간극을 메우는 중요한 첫걸음입니다. 이제 DNS 응답 자체가 NTA 적용 사실을 알려줌으로써, 운영자와 모니터링 도구가 더 정확한 판단을 내릴 수 있게 됐습니다.
한국 개발 생태계에서의 적용 맥락
국내에서도 DNS 인프라를 운영하는 기업이라면 이번 사례를 주목할 필요가 있습니다. 특히, 공공기관이나 금융권처럼 높은 가용성이 요구되는 환경에서는 DNSSEC 검증 실패 시 NTA 적용을 고려해야 하지만, 그 과정에서 투명성을 보장하는 장치가 함께 마련되어야 합니다. EDE 33 도입은 단순한 기술적 개선을 넘어, 장애 대응 프로세스의 신뢰성을 높이는 계기가 될 것입니다.
다음 단계 학습 방향
- RFC 7646과 RFC 8914를 직접 읽어보며 NTA와 EDE의 상세 동작 원리를 이해해 보세요.
- 실제 DNS 리졸버(Unbound, Knot Resolver 등)에서 EDE 코드를 어떻게 처리하는지 확인해 보세요.
- DNSSEC 검증 실패 상황을 재현하고, NTA 적용 전후의 응답 차이를 직접 실습해 보세요.
함께 보면 좋은 글