DS 레코드 하나를 잘못 넣으면 도메인이 인터넷 일부에서 사라질 수 있다.
침해된 게 아니다. 느려진 것도 아니다. 불안정한 것도 아니다. 그냥 사라진다. 적어도 검증 리졸버 뒤에 있는 사용자에게는. 이렇게 터무니없이 날카로운 실패 모드 하나로 DNSSEC의 20년 채택 역사를 설명할 수 있다.
짜증나는 건 프로토콜 자체는 엉망이 아니라는 점이다. DNS는 태어날 때부터 답처럼 보이는 건 뭐든 신뢰했다. 캐시 포이즈닝이 오랫동안 악몽이었던 이유다. DNSSEC는 그 순진한 신뢰에 서명, 위임 레코드, 진짜 신뢰 체인을 추가한다. 서류상으로는 DNS 세계가 만든 것 중 가장 지적으로 만족스러운 결과물이다.
서류상이라는 말이 여기서 많은 일을 하고 있다.
신뢰의 체인
DNS는 계층 구조다. 루트 존이 꼭대기에 있고, TLD(.com, .org, .net)에 위임하고, TLD는 개별 도메인의 권한 있는 네임서버에 위임한다. DNSSEC는 이 계층을 암호화 서명으로 미러링한다.
루트 존이 키 쌍을 갖는다. 각 TLD의 DS(Delegation Signer) 레코드에 서명한다. TLD도 자체 키 쌍을 갖고, 그 아래 각 도메인의 DS 레코드에 서명한다. 도메인은 자체 키 쌍으로 실제 DNS 레코드 — A, MX, AAAA 등 — 에 서명한다. 리졸버가 답을 검증할 때는 체인을 역순으로 타고 올라간다. 레코드의 서명을 도메인의 DNSKEY로 확인하고, 도메인의 DS 레코드를 TLD의 서명으로 확인하고, TLD의 DS 레코드를 루트의 서명으로 확인한다. 모든 링크가 유지되면 답은 진본이다.
루트 키가 트러스트 앵커다. 전 세계 리졸버에 저장되어 있다. 루트 키를 건드려야 할 때마다 세레모니가 있다 — 진짜 물리적 세레모니. 금고, 하드웨어 보안 모듈, 보안 시설까지 날아오는 사람들.
이 모든 게 맞다. 건전한 암호학이다. 그리고 실제 사람이 배포하려는 순간 무너진다.
DNSSEC가 실제로 사주는 것
전송 중이거나 캐시에 있는 위조 DNS 데이터에 대한 보호. 이게 헤드라인이다.
서명을 검증하는 리졸버는 신뢰할 수 있는 키까지 체인이 연결되지 않는 답을 거부한다. 누군가 은행의 A 레코드나 메일 교환기를 위조하면, 위조된 레코드는 서명 검증을 통과해야 한다. 보통은 못 한다. DNSSEC는 부정 응답도 처리한다 — “그 이름은 존재하지 않는다”를 인증할 수 있다. 카민스키 사건 이후 시절을 보낸 사람이라면 이게 왜 중요한지 안다.
근데 DNSSEC가 하지 않는 것도 봐야 한다. 기밀성은 제공하지 않는다. 쿼리는 DNS-over-HTTPS나 DNS-over-TLS를 쓰지 않는 한 여전히 평문이다. DDoS 공격도 막지 못한다 — 사실 DNSSEC는 DNS 증폭 공격을 심각하게 악화시킨다. RRSIG와 DNSKEY 레코드가 담긴 응답이 크기 때문이다. 공격자들이 DNSSEC 서명된 도메인을 반사기로 좋아하는 이유다.
DNSSEC는 자체 마케팅 문제에 시달렸다. “보안 DNS”는 “서명된 DNS 데이터”보다 넓게 들린다. 실제 보호 범위는 더 좁지만, 진짜다.
아무도 안 쓰는 이유
운영 거래 조건이 비참하기 때문이다.
키 관리가 악몽이다. DNSSEC는 존의 암호화 키를 관리해야 한다. 키가 만료된다. 로테이션이 필요하다. KSK 롤오버는 상위 존 — 레지스트라 — 과 협조해서 DS 레코드를 업데이트해야 한다. 타이밍을 놓치면 전체 도메인이 꺼진다. “느려진다”가 아니다. 꺼진다. 모든 쿼리에 SERVFAIL. 웹사이트, 이메일, 전부 — DS 레코드를 고치고 캐시가 만료될 때까지 기다려야 사라진다.
강조한다. 잘못 설정된 DS 레코드는 우아하게 성능 저하되지 않는다. 존을 죽인다. DNS는 보통 관대하다 — A 레코드 하나를 실수하면 서브도메인 하나가 죽을 수 있다. DNSSEC는 DNS를 단순한 무상태 디렉토리에서, 실수 한 번의 대가가 전면 장애인 취약한 암호화 지뢰밭으로 바꾼다.
레지스트라 지원이 이상하게 들쭉날쭉이다. 일부 레지스트라는 DNSSEC 설정을 간단하게 만든다. 대부분은 인터페이스 깊숙이 묻어놓아서 보물지도가 필요하다. 2026년에 DS 레코드 해시를 웹 폼에 수동으로 붙여넣게 하는 곳이 있다. 체인은 게으른 링크 하나를 용납하지 않는다.
리스크-보상 계산이 안 맞는다. 캐시 포이즈닝은 실제 공격이지만, 대부분의 조직이 걱정하는 공격이 아니다. 피싱, 랜섬웨어, 크리덴셜 탈취가 CISO를 잠 못 자게 한다. 캐시 포이즈닝은 위협 모델 3페이지에 있다. 경험해본 적 없을 공격에 대비해서 상당한 운영 복잡성을 떠안으라고 하는 것이다.
디버깅이 잔인하다. DNSSEC가 고장 나면 에러 메시지가 SERVFAIL이다. 그게 전부. 서명 오류? 키 만료? DS 레코드 누락? 시간 오차? SERVFAIL. 알아서 파악해라.
DNSSEC에는 Let’s Encrypt 모먼트가 없었다
HTTPS 채택률은 수년간 40%에 머물렀다. Let’s Encrypt가 무료 자동 인증서를 들고 나왔다. 5년 안에 HTTPS가 90%를 넘었다. 장벽은 DNSSEC가 겪는 것과 같은 종류였다 — 인증서 관리가 복잡하고, 실수하기 쉽고, 수동이었다. Let’s Encrypt는 자동화로 해결했다.
DNSSEC에는 그런 게 없다. “이 명령어 하나 실행하면 DNSSEC가 작동합니다”는 존재하지 않는다. 일부 관리형 DNS 제공자가 처리해준다. 하지만 레지스트라와 DNS 제공자가 같은 회사이거나 DS 레코드 교환을 자동화한 경우에만 작동한다. 많은 곳이 안 했다.
Let’s Encrypt의 교훈은 “무료로 만들어라”가 아니다. DNSSEC는 이미 무료다. 교훈은 “안 보이게 만들어라”다. DNSSEC는 안 보이는 것의 반대다.
더 나쁜 건, DNSSEC의 성공도 안 보인다. HTTPS가 작동하면 브라우저 상태가 바뀌고, 혼합 콘텐츠가 차단되고, 사용자가 뭔가를 느낀다. DNSSEC가 작동하면 아무 일도 안 일어난다. 리졸버가 조용히 거짓을 거부한다. 훌륭한 보안 엔지니어링. 최악의 마케팅.
닭과 달걀
검증 리졸버는 서명된 존이 없으면 검증을 신경 쓰지 않는다. 검증할 게 없는데 왜 지연을 추가하나? 존 운영자는 리졸버가 검증을 안 하면 서명을 하지 않는다. 보호가 사용자에게 닿지 않는데 왜 운영 리스크를 감수하나?
인터넷은 기묘하게 답답한 균형을 발명했다. 널리 존경받고, 기술적으로 건전하고, 선택적 의식으로 취급되는 프로토콜. 모두가 모두를 기다린다.
DNSSEC가 실패한 건 암호학이 틀려서가 아니다. 인터넷이 아키텍처 불순물보다 운영 복잡성에 훨씬 더 가혹하기 때문이다. 보안 메커니즘이 존 운영자, 레지스트라, 리졸버 사이의 세심한 협조를 요구하면서, 성공의 보상은 침묵이고 실수의 벌은 장애라면, 설정을 모욕적으로 쉽게 만들어야 한다.
DNSSEC는 모욕적으로 쉬워진 적이 없다. 사람들이 여전히 멀리서 감탄하는 이유다.