DANE에 대한 정석적 평가는 ‘비극’입니다. 암호학적으로 깔끔한 발상 — TLS 인증서를 DNS에 직접 피닝하고 인증 기관(CA)을 통째로 건너뛴다 — 이 DNSSEC 뒤에 발이 묶였다는 것. 인터넷 대부분이 끝내 배포하지 않은 그 의존성 말입니다. 종이 위에선 아름답고, 현실에선 죽었다. 저도 이 문장을 직접 써본 적이 있습니다.
틀렸습니다. 적어도 당신이 미국에 서서 Gmail을 보고 있을 때만 맞는 말입니다. 시점을 동쪽으로 몇천 킬로미터 옮기면 DANE은 경고성 우화가 아닙니다. 의무입니다. 네덜란드 정부가 요구합니다. 독일 메일 제공자들은 기본값으로 돌립니다. 2025년 말 기준, 네덜란드 조직 일곱 중 하나가 메일 서버에 DANE을 켜고 있었고 — 같은 조사에서 MTA-STS 채택률의 두 배가 넘습니다 — .nl 존에서 암호학적으로 앵커링된 메일 게이트웨이 수가 6개월 만에 대략 두 배가 됐습니다. 그리고 2026년 초, 다름 아닌 마이크로소프트가 Exchange Online에 DANE 검증을 탑재하기 시작했습니다. 다들 죽었다고 합의했던 그 프로토콜이 인생 최고의 해를 보내고 있습니다.
그래서 어느 쪽일까요 — 실패한 표준일까요, 조용한 성공일까요? 정직한 답은 둘 다이고, 그 갈림은 정확히 웹과 이메일 사이의 선을 따라 납니다. 같은 프로토콜, RFC 6698, 무엇을 보호하느냐에 따라 완전히 다른 두 운명. 그 분기가 흥미로운 지점이고, 보안 표준이 실제로 어떻게 이기고 지는지에 대해 진짜를 말해줍니다.
DANE이 실제로 뭔가
약어를 벗겨내면 DANE은 고집스러운 발상 하나입니다: 이미 도메인의 DNS를 통제하는 사람이, CA에 허락을 구하지 않고도, 그 도메인에 어떤 인증서가 정당한지 말할 수 있어야 한다.
TLSA 레코드를 발행합니다. 포트와 프로토콜을 인코딩한 이름에 놓입니다 — 메일 서버라면 _25._tcp.mail.example.com, TCP 위 포트 25 — 그리고 작은 숫자 세 개와 해시를 담습니다. 숫자는 용도(usage), 셀렉터(selector), 매칭 타입(matching type)입니다. 가장 흔한 조합은 3 1 1로, 이렇게 읽힙니다: 이건 종단 인증서 자체이고(용도 3, “DANE-EE”, CA 미개입), 공개 키를 피닝하며(셀렉터 1), 그 SHA-256 해시가 여기 있다(매칭 타입 1). 발신 서버는 그 레코드를 해석하고, TLS 핸드셰이크를 끝내고, 상대가 제시한 키를 해시해서 비교합니다. 일치하면 배달. 불일치면 거부. CA 체계 — 브라우저가 신뢰하는 150여 개 루트, 유료 검증의 그 모든 장치 — 는 그냥 관여하지 않습니다. DNS가 신뢰 앵커입니다.
그래서 DNSSEC 없이는 작동할 수 없습니다. 평문 DNS로 가져온 TLSA 레코드는 무가치합니다: 인증서를 바꿔치기할 수 있던 그 네트워크 공격자가 그걸 잡아야 할 TLSA 레코드도 바꿔치기할 수 있으니까요. DANE의 보안은 전적으로 DNSSEC의 서명 체인에서 빌려옵니다. 서명된 존이 없으면 DANE도 없습니다. 다들 가리키는 그 의존성, 진짜입니다. 다만 그게 이야기의 전부가 아닐 뿐입니다.
웹이 거부한 이유
웹에서 DANE은 깔끔하게 졌고, 질 만했다는 걸 똑바로 보는 게 좋습니다.
DANE을 브라우저로 가져오려는 진지한 시도가 있었습니다 — HTTPS 인증서를 TLSA 레코드에 피닝하고, 브라우저가 검증하게 하고, 웹 PKI에서도 CA를 잘라낸다. 아무 데도 못 갔습니다. 브라우저는 TLSA 검증을 끝내 탑재하지 않았습니다. 브라우저가 직접 DNSSEC 조회를 안 해도 되도록 DANE 레코드를 TLS 핸드셰이크에 스테이플링하자는 제안은 흐지부지됐고 벤더들은 떠났습니다. 오늘날 주요 브라우저 중 HTTPS용 DANE을 검증하는 건 없습니다. 웹에선 정석적 평가가 그냥 옳습니다: 죽었습니다.
이유는 신비롭지 않고 구체적입니다. 브라우저는 사용자가 적극적으로 기다리는 서버를 상대로 수십 밀리초 만에 TLS 핸드셰이크를 합니다; 모든 연결마다 그 핫 패스에 완전한 DNSSEC 검증 체인을 볼트로 박는 건 아무도 원치 않은 지연이었습니다. 브라우저는 이미 인증서 신뢰 문제에 다른 답을 만들어둔 상태였습니다 — 발급된 모든 인증서를 공개 감사 가능하게 만드는 인증서 투명성(CT) 로그, 그리고 브라우저 바이너리에 구워 넣은 HSTS 프리로드 목록. CA 체계 자체를 관측 가능하게 만들었기에 DNS가 신뢰 앵커일 필요가 없었습니다. 그리고 결정적으로, 웹의 클라이언트는 온갖 네트워크 위 수십억 명의 최종 사용자이고, 거기서 깨진 DNSSEC 체인은 빈 오류 페이지와 고객센터 전화를 뜻합니다. “DNSSEC 실수가 사이트를 깬다”의 폭발 반경은 용납 불가였습니다.
이 이유들 하나하나가 이메일로 옮겨가면 증발합니다.
이메일이 지켜낸 이유
서버 대 서버 SMTP는 다른 세계이고, DANE이 조용히 겨냥해 만들어진 세계입니다.
클라이언트부터 봅시다: 사람이 아니라 관리자가 운영하는 메일 서버입니다. Postfix와 Exim은 수년째 DANE을 지원합니다. “DNSSEC를 관리해야” 하는 모집단은 수십억 휴대폰 사용자가 아니라, 이미 업으로 DNS에서 살고 존 서명쯤 티켓 없이 해내는 메일 운영자 수천 명입니다. 핫 패스 지연 반론도 적용되지 않습니다 — 두 메일 서버가 협상하는 동안 진행 막대를 노려보는 사람은 없으니, 배달 시 DNS 왕복 한 번 더는 보이지도 않습니다.
그리고 대안은 사람들이 인정하는 것보다 약합니다. MTA-STS 방식 — TLS 정책을 웹 페이지로 발행하고 발신자가 최초 사용 시 그걸 신뢰하게 한다 — 은 작동하고, 구글은 2019년 Gmail을 거기에 걸었습니다. 하지만 그건 최초 사용 시 신뢰(TOFU)입니다: 발신자가 캐시된 정책 없이 당신에게 처음 접속하는 바로 그 순간, 그 한 번의 HTTPS 요청을 막을 수 있는 공격자는 발신자를 아무것도 모르게 둡니다. DANE엔 최초 사용 공백이 없습니다. 검증이 DNS에서, 암호학적으로 서명된 채, 모든 연결마다 일어나니까요. 위협 자체가 경로상에서 암호화를 벗겨내는 능동 공격자인 이메일에선, 그 차이가 핵심 전부입니다. SMTP는 인증서 투명성도 HSTS 프리로드 대응물도 끝내 갖지 못했으니, 웹이 DANE을 필요로 하지 않았던 이유가 여기선 그냥 존재하지 않습니다. 웹에서 DANE이 메우는 공백은 이미 다른 게 메웠습니다. 이메일에선 아직 열려 있습니다.
2026년, 베팅이 바뀐 해
오랫동안 이메일 DANE은 유럽 정부의 취미로 치부할 수 있었습니다 — 네덜란드 표준화 포럼이 준수-아니면-설명(comply-or-explain) 목록에 올리고, .nl과 .de 제공자 한 무리가 돌리고, 대규모로는 그 외엔 별로 없었으니까요. 구글이 DANE 대신 MTA-STS를 택한 건 시장의 판정처럼 보였습니다.
그 구도가 올해 깨졌습니다. 마이크로소프트가 Exchange Online에 수신(inbound) DANE 검증을 추가했고, 2026년 초엔 발신(outbound) 커넥터에 DANE과 MTA-STS 모드를 설정 가능하게 배포하기 시작했습니다 — 관리자가 배달을 DNSSEC 기반 DANE 강제로 설정할 수 있게, 그리고 메일 관리자용 DNSSEC 활성화 마법사를 연내에 약속하면서요. 지구상 둘째로 큰 사서함 제공자가 DANE을 일급의, 강제 가능한 옵션으로 탑재하면, “아무도 배포 안 했다”는 더 이상 참이 아닙니다. 시장은 판정에 도달한 게 아닙니다. 늘 그렇듯 갈라졌습니다 — 한쪽엔 이미 지배하는 웹 PKI에 거는 구글, 다른 쪽엔 서명된 DNS에 거는 유럽 공공 부문, 그리고 이제 마이크로소프트.
DANE에서 제가 얻는 교훈은 “좋은 프로토콜, 불운”이 아닙니다. “이 표준은 죽었나?”가 잘못된 질문이라는 겁니다. 표준에 운명이 하나라고 가정하니까요. DANE은 적어도 셋을 가졌습니다: 웹에선 진짜로 죽었고, 네덜란드 정부 메일에선 의무이고, 최대 엔터프라이즈 메일 플랫폼에서 새로 살아났습니다. 프로토콜이 이기느냐는 애초에 프로토콜의 속성이 아니었습니다. 클라이언트가 누구인지, 어떤 지연을 감내하는지, 다른 무언가가 이미 그들의 문제를 풀었는지의 속성이었습니다. 그것들을 바꾸면 판정이 바뀝니다 — RFC가 쉼표 하나 안 움직였는데도요.