DNSSEC 검증이 조용히 꺼진다? Cloudflare가 EDE 33으로 NTA 투명성 문제를 해결한 방법

들어가며: DNSSEC이 깨지면 무슨 일이 벌어지는가

2026년 7월 3일, 알바니아 국가 도메인 .al을 관리하는 AKEP가 DNSSEC 키 롤오버를 시도했습니다. 결과는 참담했어요. 루트 존의 DS 레코드는 여전히 옛 DNSKEY(id=26319)를 가리키고 있는데, .al 네임서버는 새 키만 서빙하기 시작한 겁니다. DNSSEC 명세를 따르는 모든 검증 리졸버는 이 서명을 거부해야 했고, Cloudflare의 1.1.1.1도 예외가 아니었습니다.

문제는 .al이 알바니아 정부 서비스, 은행, 언론사의 온라인 거점이라는 점이에요. 검증 리졸버를 쓰는 사용자 입장에서는 이 도메인들이 전부 "접속 불가"가 되어버렸습니다. 호스팅 위치나 권한 네임서버와 무관하게, .al 아래 모든 도메인이 영향을 받았어요.

불과 두 달 전에는 독일 .de TLD에서 비슷한 사고가 났었죠. 당시 대응은 Negative Trust Anchor(NTA) 를 설치해서 DNSSEC 검증을 일시적으로 중단하는 것이었습니다. 이번 .al 사고에서도 같은 조치를 취했지만, Cloudflare는 여기서 한 걸음 더 나아갔습니다. 응답에 EDE 33 코드를 실어서 "이 답변은 검증되지 않았음"을 명시적으로 알린 거죠. 이게 이 글의 핵심입니다.

참고로 이 내용은 Cloudflare의 근거자료를 바탕으로 재구성했습니다.

Part 2: NTA는 왜 '조용한 위험'인가

DNSSEC 신뢰 체인의 구조

DNSSEC은 루트 존에서 개별 도메인까지 신뢰 체인(chain of trust) 을 만듭니다. 루트 존은 각 서명된 TLD의 DNSKEY 지문인 DS 레코드를 가지고 있어요. 리졸버가 .al을 검증할 때는 .al 네임서버가 서빙하는 DNSKEY가 루트의 DS 레코드와 일치하는지 확인합니다. 일치하면 .al 네임서버의 응답을 신뢰하는 구조입니다.

이번 사고의 타임라인을 정리하면 다음과 같아요.

NTA의 트레이드오프

NTA는 RFC 7646에 정의된 개념으로, 리졸버에게 "이 존을 서명되지 않은 것으로 취급하고 검증을 건너뛰라"고 지시합니다. 도메인이 다시 접속 가능해지는 대신, DNSSEC 스푸핑 방어가 사라집니다.

여기서 진짜 문제는 투명성이었어요. NTA 아래에서 서빙된 응답은 정상 검증된 응답과 겉보기에 완전히 동일했습니다. RFC 7646은 운영자가 NTA 적용 사실을 공개하도록 권고하지만, 그건 out-of-band(상태 페이지 등) 방식이라 사용자가 직접 찾아봐야 하는 구조였죠. 애플리케이션이나 모니터링 도구 입장에서는 응답만 보고 검증 우회 여부를 알 방법이 없었습니다.

Part 3: EDE 33이 해결한 것 — 응답 자체가 말하게 하라

EDE(Extended DNS Error)란

RFC 8914에 정의된 EDE 코드는 리졸버가 DNS 응답에 추가 컨텍스트를 실어 보낼 수 있게 해줍니다. Quad9의 Babak Farrokhi가 NTA 존재를 응답에 직접 시그널링하는 Internet-Draft를 제안했고, Cloudflare가 공동 저자로 참여해서 1.1.1.1에 구현했습니다. 그게 바로 EDE 33 (Negative Trust Anchor) 입니다.

실제 응답은 이렇게 생겼어요:

$ 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

응답 자체는 NOERROR에 정상적인 A 레코드가 들어있어요. google.al은 해석됩니다. 하지만 두 개의 EDE 코드가 함께 따라붙습니다.

• EDE 9 (DNSKEY Missing): 근본 원인인 DNSSEC 실패를 노출. 신뢰 체인이 깨졌고 검증이 실패했음.
• EDE 33 (Negative Trust Anchor): 1.1.1.1이 NTA를 적용해서 응답을 그대로 서빙했음을 알림.

두 코드를 합치면 클라이언트와 운영자 모두에게 완전한 가시성을 제공합니다. "답변은 진짜지만, DNSSEC 검증은 되지 않았다" 는 사실을 응답 자체가 말해주는 거예요.

주의할 점: EDE 33은 "존 전체"에 적용된다

1.1.1.1은 NTA가 활성화된 동안 생성되는 모든 응답에 EDE 33을 붙입니다. DNSSEC을 아예 쓰지 않는 도메인이라도 NTA 범위에 들어가면 EDE 33이 따라옵니다. 이건 의도된 동작이에요. NTA는 존 전체를 커버하고, 투명성은 그 아래 서빙되는 모든 응답에 동일하게 적용되어야 하니까요.

이건 이전 .de 사고 때 Cloudflare가 지적했던 문제도 해결합니다. 당시 1.1.1.1은 근본 원인인 DNSSEC 에러 대신 EDE 22 (No Reachable Authority)를 잘못 반환했었는데, 이번 .al 사고에서는 EDE 9와 EDE 33을 정확히 함께 반환했습니다.

Part 4: 한국 개발 생태계에서 이게 왜 중요한가

국내 환경에서의 시사점

국내 SI/금융권에서도 DNSSEC 도입이 늘고 있는 추세지만, TLD 레벨 장애 대응 매뉴얼을 갖춘 조직은 거의 없습니다. 대부분의 운영팀은 "DNSSEC 켜면 보안이 좋아진다"까지만 이해하고, 롤오버 실패 시 어떻게 대응할지에 대한 런북이 없는 경우가 많아요.

이번 사례에서 배워야 할 점은 세 가지입니다.

1. NTA는 최후의 수단이지 기본값이 아니다. 검증을 끄는 순간 스푸핑 방어가 사라진다는 사실을 명확히 인지해야 합니다.
2. 모니터링 도구는 EDE 코드를 파싱해야 한다. 응답만 보고 NOERROR라고 판단하면, 실제로는 검증이 우회된 응답을 정상으로 오인할 수 있습니다.
3. 리졸버 선택이 곧 관측 가능성이다. Cloudflare 1.1.1.1, Quad9, Google DNS 등이 EDE 지원 범위를 어디까지 넓히는지 주시할 필요가 있습니다.

한계와 주의사항

• EDE 33은 Internet-Draft 단계입니다. IANA가 코드는 할당했지만, 아직 표준이 아닙니다. Unbound는 PR 리뷰 중이고, Knot의 kdig는 이미 인식합니다. 다른 리졸버 구현체가 얼마나 빨리 따라올지는 미지수예요.
• NTA 자체는 여전히 존 전체 검증을 끄는 강경 조치입니다. 세분화된 예외 처리가 아닙니다.
• .al은 이 글 작성 시점까지 여전히 unsigned 상태입니다. DS 레코드가 복원되지 않아 모든 .al 도메인이 DNSSEC 보호를 받지 못하고 있어요.

다음 단계 학습 방향

• RFC 7646 (Negative Trust Anchors): NTA의 정의와 운영 지침을 원문으로 읽어보세요.
• RFC 8914 (Extended DNS Errors): EDE 코드 전체 목록과 활용 사례를 확인하면 모니터링 도구 설계에 도움이 됩니다.
• RFC 4033~4035 (DNSSEC 기본 명세): 신뢰 체인이 어떻게 구성되는지 근본부터 이해하고 싶다면 여기서 시작하세요.
• Cloudflare Radar: 실시간 TLD 트렌드와 DNSSEC 서명 상태를 확인할 수 있습니다.

함께 보면 좋은 글

• 메타가 공개한 BOxCrete AI로 콘크리트 배합을 최적화하는 오픈소스 모델 — 오픈소스 모델이 특정 산업 도메인에 어떻게 적용되는지 사례가 궁금하다면.
• 90일 걸리던 인프라 구축, 몇 시간으로 줄인 산탄데르의 플랫폼 엔지니어링 전략 — 대규모 인프라 운영 자동화 관점에서 참고할 만한 케이스입니다.

DNS는 눈에 보이지 않을 때 가장 잘 작동합니다. 하지만 그 '보이지 않음'이 위험이 될 때, EDE 33처럼 응답 자체가 말해주는 구조가 필요합니다. 이번 사례는 인프라 투명성의 좋은 본보기예요.