DNSSEC는 약 25년의 시간을 썼고, 어떤 정직한 지표로 봐도 여전히 반올림 오차 수준이다. APNIC의 2025년 수치는 리졸버 측 검증을 36% 정도로 잡는다 — 그쪽은 조용히 이기고 있다 — 하지만 실제로 서명된 존은 위임의 7% 부근에 머문다. .com의 5% 미만이 서명돼 있다. DNS 스푸핑에 대한 정답이라고 모두가 동의하는 표준이 거의 아무 데도 배포되지 않았다.
흔한 설명은 DNSSEC가 너무 복잡하다는 것이다. 키 알고리즘, RRSIG 레코드, 루트부터 내려오는 신뢰 사슬. 무서운 것들.
나는 안 믿는다. 암호학은 벽이 아니다. 벽은 조직도다.
두 회사가 필요하다
DNSSEC를 켜는 건 서로 다른 두 벤더가 소유한 두 개의 작업이다.
첫 번째 작업: DNS 운영자가 존에 서명하고 DNSKEY를 게시한다. 대부분의 관리형 DNS 제공자는 토글 하나로 해준다. 이 부분은 쉽고, 채택이 죽는 지점도 아니다.
두 번째 작업: 부모 존이 — 당신의 등록대행자를 거쳐 레지스트리에 닿는다 — 일치하는 DS 레코드를 게시해야 검증 리졸버가 루트에서 당신까지 신뢰 사슬을 세울 수 있다. 그런데 등록대행자는 대개 DNS 호스트와 다른 회사다. 그래서 DNSSEC 활성화의 마지막 단계는, 사람이 한 회사 대시보드에서 해시를 복사해 두 번째 회사 대시보드에 손으로, 정확히, 붙여 넣는 일이다.
그게 장벽의 전부다. 머클 트리가 아니다. 서로를 들어본 적 없는 두 벤더 사이의 복사-붙여넣기.
도메인을 통째로 지울 수 있는 그 한 단계
왜 그 복사-붙여넣기가 유독 독성이 강한지, 그리고 그걸 끝낸 사람들조차 왜 이후로 영원히 DNSSEC를 두려워하는지 보자.
DNS에서 다른 거의 모든 걸 틀리면 서비스 품질이 저하되는 정도로 끝난다. 그런데 DS 레코드를 틀리면 — 오래된 해시, 안 맞는 키, 부모가 따라오지 못한 롤오버 — 검증 리졸버는 경고도 폴백도 서빙하지 않는다. SERVFAIL을 반환한다. 당신의 도메인은 고장 나 보이는 게 아니라 사라진 것처럼 보이고, 그것도 검증하는 인터넷의 1/3에게만 그렇다. 이건 디버깅하기 최악의 실패다. 사용자 절반은 사이트가 멀쩡하다고 우기기 때문이다.
그리고 이 일이 키 롤오버마다 영원히 반복된다. 그러니 수동 핸드셰이크는 설정할 때 성가신 정도가 아니다. 키를 회전할 때마다 다시 장전하는 상시 부채다. 합리적인 운영자라면 “보안 이득은 작고, 하방은 도메인 전체 장애”라는 계산을 보고 그냥 꺼둔다. 게을러서가 아니다. 계산을 하는 것이다.
한 회사가 양쪽을 다 가지면, 그냥 된다
암호학이 문제가 아니었다는 깔끔한 증거: 한 회사가 등록대행자이자 DNS 운영자일 때 무슨 일이 벌어지는지 보라.
Cloudflare는 양쪽을 다 운영한다. CDS/CDNSKEY 스캔을 지원하고, 자사 등록대행 도메인에 대해서는 DS 레코드를 직접 제출한다 — 대시보드 간 복사-붙여넣기가 없다. 대시보드가 하나뿐이기 때문이다. 이 구조에서 채택률은 7%가 아니다. 거의 전부이고, 사용자 눈에는 보이지도 않는다.
같은 암호학. 같은 롤오버. 바뀐 건 딱 하나, 대화해야 할 두 당사자가 이제 한 당사자가 됐다는 것. 핸드셰이크를 제거하니 채택은 더 이상 문제가 아니게 된다. 그건 핸드셰이크가 바로 문제였다는 뜻이다.
해결책은 오래전에 나왔다
이 부분이 업계를 부끄럽게 해야 한다: 핸드셰이크를 자동화하는 메커니즘은 10년 넘게 공표된 표준으로 존재해 왔다.
RFC 7344(2014)는 CDS와 CDNSKEY를 정의했다 — 자식이 원하는 DS를 부모에게 신호로 게시하는 레코드로, 사람이 붙여 넣길 기다리는 대신 부모가 자동으로 끌어갈 수 있게 한다. RFC 8078(2017)은 이를 표준화 트랙에 올리고, 결정적으로 DNSSEC를 인밴드로 켜고 끄는 것까지 다뤘다. 7344가 풀지 못한 유일한 것은 바로 첫 삽입이었다 — DS가 하나도 없는 상태에서는 신호를 인증할 근거도 없다는 진짜 닭-달걀 문제다. 2024년 7월 공표된 RFC 9615가 정확히 그 틈을 인증된 부트스트래핑으로 메운다. DNS 운영자가 서명된 신호 레코드를 게시하면, 부모는 첫 DS가 존재하기도 전에 그걸 암호학적으로 검증할 수 있다.
이 중 어느 것도 이론이 아니다. .ch와 .cz 레지스트리는 이미 자식 존에서 CDS를 스캔해 DS를 직접 게시한다. PowerDNS는 2026년 RFC 9615 부트스트래핑을 출시했다. ICANN 자체 보안위원회는 SAC126(2024)에서 레지스트리와 등록대행자에게 DS 프로비저닝을 자동화하라고 못 박았다. 다리는 놓여 있다. 업계 대부분이 아직 건너지 않았을 뿐이다.
기본값으로 켜라 — 단, 전제 하나
옵트인은 할 만큼 했다. “뭘 하는지 아는 사람만 DNSSEC를 켜라”의 25년은 한 자릿수 서명률을 낳았다. 옵트인은 7%로 가는 길이다. 보안 기본값을 7%에서 70%로 옮기는 유일한 레버는 기본값 자체를 뒤집는 것이고, 70%를 넘긴 유럽 ccTLD들은 서명을 보물찾기가 아니라 가장 저항이 적은 길로 만들어 거기 도달했다.
그러니 입장은 단순하다: DNS와 등록대행을 둘 다 운영하는 모든 제공자는 서명과 DS 제출을 기본값으로 해야 한다. 모든 레지스트리는 CDS/CDNSKEY를 스캔해야 한다. 모든 등록대행자는 그걸 존중해야 한다. 롤오버가 도메인을 망가뜨린다는 공포는 실재한다 — 그러나 그건 수동 버전에 대한 공포다. CDS가 구동하는 자동화·모니터링 롤오버가 바로, 단일 운영자 환경이 이미 아무도 밤잠 설치지 않고 DNSSEC를 돌리는 방식이다.
정직한 전제 하나가 있고, 그건 중요하다. 기본값 켜기는 한 운영자가 서명 과 DS 제출을 처음부터 끝까지 통제할 때만 안전하다. 존에 서명은 하면서 DS 삽입을 CDS도 안 스캔하는 등록대행자에게 떠넘기는 “기본값”은 아무것도 안 하느니만 못하다 — 다리를 반만 놓고 사람들에게 건너라고 부른 셈이다. 그러니 규칙은 “스위치를 켜라”가 아니다. “핸드셰이크 전체를 자동화한 다음 스위치를 켜라”다. 이건 진짜 엔지니어링 기준이다. 그리고 그건 RFC 7344, RFC 8078, RFC 9615가 이미 넘어놓은 바로 그 기준이다.
당신의 도메인이 서명되지 않은 이유는 DNSSEC가 이해하기 어려워서가 아니다. 켜는 데 늘 두 회사가 대화해야 했고, 그 둘을 사람 없이 대화하게 만드는 프로토콜이 2014년부터 RFC 안에 앉아 있었기 때문이다. 변명은 오래전에 만료됐다. 기본값을 배포하라.