DANE/TLSA 레코드 검사기

도메인의 메일 서버(MX 호스트)가 공개한 TLSA 레코드를 여러 공개 DNS 리졸버에 질의하여 DANE 인증서 고정이 설정되어 있는지 진단합니다.

마지막 업데이트: 2026-09-20

DANE(TLSA 레코드)에 의한 인증서 검증을 진단하기

DANE는 메일 서버가 내미는 인증서의 옳고 그름을 **DNS에 둔 TLSA 레코드로 검증하는** 얼개입니다. 이 도구는 도메인의 MX 호스트가 내건 TLSA 레코드를 여러 공개 리졸버에 물어 설정되어 있는지를 보고합니다.

**여기서 결코 빼놓을 수 없는 전제는, DANE가 DNSSEC 위에서만 성립한다는 점입니다.** TLSA 레코드가 손대어지지 않았음을 담보하는 것이 바로 DNSSEC이므로, **DNSSEC를 켜지 않은 도메인에 TLSA를 두어도 방어로서는 뜻이 없습니다.** 이 점이 MTA-STS와의 가장 큰 차이로, MTA-STS가 웹 인증서에 믿음을 두는 데 비해 **DANE는 DNSSEC에 믿음을 둡니다.** 운영상 또 하나 조심할 대목은 인증서의 갱신으로, **서버 인증서를 갈 때 TLSA 레코드를 함께 고치지 않으면 검증이 통과되지 않아 메일이 닿지 않게 됩니다.** 새 지문을 먼저 더하고, 갈아탄 뒤에 옛것을 지우는 차례가 필요합니다.

사용하는 방법

도메인을 넣습니다 `example.com`처럼 도메인만 넣으면 됩니다.
MX 호스트별 결과를 봅니다 **TLSA는 MX 호스트의 `_25._tcp.호스트명`에 놓입니다.**
DNSSEC의 유무도 함께 확인합니다 **DNSSEC가 없으면 TLSA가 있어도 보호가 되지 않습니다.**
인증서 갱신의 절차를 세웁니다 **새 지문과 옛 지문을 한동안 함께 두었다가 갈아탑니다.**

더 잘 활용하기 위한 팁

TLSA 레코드는 일반 도메인 이름이 아니라 `_25._tcp.{MX 호스트명}`이라는 특수한 이름 아래에 배치됩니다. 도메인 이름만으로 TLSA를 조회해도 찾을 수 없는 이유입니다.
"DANE 미설정"은 오류가 아닙니다. DANE은 메일 암호화의 추가 방어 계층이며, 대부분의 메일 서버는 아직 도입하지 않았습니다.
DANE은 도메인의 TLSA 레코드 자체가 DNSSEC 서명 체인으로 보호되어야 비로소 신뢰할 수 있는 정보가 됩니다. TLSA 레코드를 찾았더라도, 자매 도구인 "DNSSEC 검증 검사기"로 해당 도메인이 DNSSEC을 지원하는지 함께 확인하세요.
MX 호스트가 여러 개인 경우, 우선순위 숫자가 가장 낮은(우선순위가 가장 높은) 호스트부터 최대 3개까지 검사합니다.
리졸버 간 결과가 다르다면 TLSA 레코드가 방금 갱신되어 캐시가 아직 일치하지 않았을 가능성이 있습니다. 잠시 후 다시 확인해 주세요.

이럴 때 쓸 수 있습니다

우리 메일 서버를 점검할 때

TLSA를 둔 줄 알았는데 MX 호스트 쪽에는 없는 어긋남을 찾아낼 수 있습니다.

인증서를 갱신하기 전에 확인할 때

**차례를 그르치면 메일이 멈추므로 미리 살피는 값어치가 큽니다.**

MTA-STS와의 쓰임새를 가릴 때

**믿음을 어디에 둘지—DNSSEC인지 웹 인증서인지—로 고르며, 둘 다 들일 수도 있습니다.**

거래처의 대응을 알고 싶을 때

상대가 DANE를 쓰는지 아닌지를 알 수 있습니다.

DANE 용어

TLSA 레코드: **인증서나 공개 키의 지문을 DNS에 두는 레코드입니다.** `_25._tcp.mail.example.com` 같은 이름에 놓입니다.
DNSSEC: **DANE의 전제입니다.** 이것이 없으면 TLSA 자체가 손대어질 수 있어 방어로 성립하지 않습니다.
사용법 필드: TLSA의 맨 앞 숫자로, 인증서 자체를 가리키는지 인증 기관을 가리키는지를 나타냅니다.
DANE-EE: 서버 인증서 자체의 지문을 등록하는 방식입니다. **어느 기관에도 기대지 않고 검증할 수 있습니다.**
교체: 인증서와 TLSA를 갈아 끼우는 작업입니다. **새 지문을 먼저 더하고 나중에 옛것을 지웁니다.**
기회적 TLS: 상대가 다루면 암호화한다는 예전의 임의 방식입니다. **DANE와 MTA-STS는 이를 필수로 끌어올립니다.**

자주 묻는 질문

"DANE 미설정" 자체는 위험하지 않습니다. 현재도 대다수의 메일 서버가 DANE 없이 운영되고 있습니다. 다만 STARTTLS 중간자 공격 대책으로, 가능하다면 도입을 검토할 가치는 있습니다.

둘 다 "메일 전송 시 TLS 암호화를 강제한다"는 같은 목적을 가지지만, 신뢰의 근거가 다릅니다. MTA-STS는 인증 기관(CA)의 인증서 검증 체인에 의존하고, DANE은 DNSSEC 서명 체인에 의존합니다. 이미 DNSSEC을 도입했다면 DANE이, 그렇지 않다면 우선 MTA-STS 도입이 현실적입니다. 둘을 함께 사용할 수도 있습니다.

Usage는 인증서 검증 방식(CA 검증을 요구할지, 인증서 자체를 직접 고정할지)을, Selector는 인증서 전체와 공개키 부분 중 무엇을 해시할지를, Matching Type은 해시 알고리즘(SHA-256, SHA-512 등)을 지정합니다. 조합에 따라 여러 운영 패턴에 대응할 수 있습니다.

확실한 보호를 위해서는 전송 대상으로 선택될 수 있는 모든 MX 호스트에 TLSA 레코드를 설정하는 것이 권장됩니다. 일부 호스트에만 설정되어 있으면, 그 호스트가 선택되지 않은 메일은 보호받지 못합니다.

이 도구는 TLSA 레코드의 공개 여부라는 표면적인 상태만 확인합니다. 인증서 연관 데이터의 내용이 실제 서버 인증서와 일치하는지까지는 검증하지 않으므로, 엄밀한 검증이 필요하다면 전문 도구를 함께 사용하세요.

여담 ― 메일 암호화를 "도청 방지"가 아니라 "인증서"로 지키는 발상

SMTP(메일 전송 프로토콜)의 암호화(STARTTLS)에는 오랫동안 약점이 있었습니다. 대부분의 메일 서버는 상대가 암호화를 지원하지 않으면 평문으로 전송하는 기회주의적 TLS(Opportunistic TLS) 방식을 채택하고 있어, 공격자가 중간자 공격으로 STARTTLS 명령을 몰래 제거하는 "STRIPTLS 공격"을 통해 양측이 눈치채지 못한 채 암호화가 무력화된 통신을 도청당할 위험이 있었습니다.

DANE(DNS-based Authentication of Named Entities, RFC 6698)은 이 문제에 대한 대응으로 TLSA 레코드를 DNS에 공개하는 방식입니다. 메일 서버의 인증서(또는 그 공개키 해시)를 미리 DNS에 고정해 둠으로써, 접속 대상이 실제로 예상된 인증서를 제시하고 있는지 검증할 수 있습니다. 인증 기관(CA)의 인증서 검증 체인에 의존하지 않고 DNSSEC 서명 체인만을 신뢰의 근거로 삼는다는 점이 일반적인 SSL/TLS 인증서 검증과 크게 다른 점입니다.

DANE의 약점은 이것이 작동하려면 도메인 자체가 DNSSEC으로 서명되어 있어야 한다는 점입니다. DNSSEC을 도입하지 않은 도메인에서는 TLSA 레코드 자체가 변조될 가능성을 배제할 수 없어, DANE의 보장이 무의미해집니다. 이 때문에 DANE의 보급은 DNSSEC의 보급률에 크게 좌우되며, 유럽 일부 레지스트리(.nl, .cz 등)에서 먼저 도입이 진행되고 있습니다.

모든 여담 보기