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