DNSSEC 검증 체커

도메인의 DNSKEY 레코드를 Google, Cloudflare 등 여러 공개 DNS 리졸버에 조회하여 DNSSEC 서명 체인이 올바르게 검증되는지 진단합니다.

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

DNSSEC의 신뢰 사슬을 진단하기

이 도구는 도메인의 DNSKEY 레코드를 여러 공개 리졸버에 물어, DNSSEC의 서명이 위까지 온전히 검증되는지를 보고합니다. DNSSEC를 켠 줄 알았는데 사슬이 도중에 끊겨 있는 상태를 찾아낼 수 있습니다.

**DNSSEC가 지키는 것은 「답이 손대어지지 않았다」는 것이지 「내용이 비밀이다」는 것이 아닙니다.** 오가는 것은 예나 지금이나 누구에게나 보이며, 담보되는 것은 참됨뿐입니다. **그리고 가장 잦은 빠뜨림은 부모 영역에 DS 레코드를 등록하는 일을 잊는 것입니다.** 제 영역에 키를 두고 서명을 했더라도 **등록기관을 통해 부모(이를테면 `.com`)에 DS를 등록하지 않으면 신뢰의 사슬이 거기서 끊겨 아무것도 검증되지 않습니다.** 거꾸로 키 교체가 어긋나 불일치가 생기면 **검증하는 리졸버에서는 도메인 전체가 풀리지 않게 됩니다.** 어중간한 상태가 켜지 않은 상태보다 오히려 위험할 수 있다는 뜻입니다.

사용하는 방법

도메인을 넣습니다 `example.com`처럼 도메인만 넣으면 됩니다.
검증의 결과를 읽습니다 **서명의 사슬이 부모까지 닿는지가 판정됩니다.**
DS 레코드의 유무를 확인합니다 **여기가 빠져 있으면 키를 아무리 두어도 검증되지 않습니다.**
여러 리졸버의 답을 견줍니다 어긋남이 있다면 캐시나 설정 가운데 하나를 의심할 수 있습니다.

더 잘 활용하기 위한 팁

AD(Authenticated Data) 플래그는 조회한 DNS 리졸버 자신이 DNSSEC 검증을 수행한 경우에만 설정됩니다. DNSSEC을 지원하지 않는 리졸버로는 의미 있는 판정을 얻을 수 없습니다.
"DNSSEC 미적용"은 오류가 아닙니다. 현재도 대다수 도메인이 DNSSEC을 사용하지 않으며, 이는 검색 순위나 이메일 전달률에 직접적인 영향을 주지 않습니다.
"검증 실패"로 판정된 경우, 먼저 등록기관(레지스트라) 관리 화면에 등록한 DS 레코드의 키 태그와 다이제스트가 현재 DNSKEY와 일치하는지 확인하세요.
DNSSEC 서명(RRSIG)에는 유효기간이 있습니다. DNS 관리 소프트웨어의 자동 재서명이 중단되지 않았는지도 확인 대상입니다.
DNSSEC을 새로 활성화한 직후에는 DS 레코드가 상위 존에 반영될 때까지 일시적으로 "검증 실패"로 표시될 수 있습니다.

이럴 때 쓸 수 있습니다

DNSSEC를 켠 뒤의 확인

**설정 화면에서 켜 두는 것만으로는 일이 끝나지 않은 경우가 많습니다.**

키 교체를 끝까지 지켜볼 때

키를 바꾼 앞뒤로 검증이 끊기지 않았는지 확인할 수 있습니다.

이름이 풀리지 않는 까닭을 가릴 때

**DNSSEC의 불일치는 일부 이용자에게만 도메인이 사라진 것처럼 보이게 합니다.**

거래처의 도메인을 살필 때

상대가 자기 쪽 대비를 어디까지 해 두었는지 알 재료가 됩니다.

DNSSEC 용어

DNSKEY: 영역의 공개 키를 두는 레코드로, 서명을 검증하는 데 쓰입니다.
DS 레코드: **자식 영역 키의 지문을 부모 영역에 등록하는 레코드입니다.** 이것이 없으면 신뢰의 사슬이 끊깁니다.
RRSIG: 레코드마다 붙는 서명 자체입니다. 기한을 지니며 때때로 갱신됩니다.
신뢰의 사슬: 뿌리에서 부모를 거쳐 자식까지 서명이 이어지는 구조입니다. **한 군데만 끊겨도 검증할 수 없습니다.**
키 교체: 키를 새것으로 바꾸는 작업입니다. **절차를 그르치면 도메인 전체가 풀리지 않게 됩니다.**
검증하는 리졸버: DNSSEC의 서명을 실제로 확인하는 리졸버입니다. **불일치가 있으면 여기서는 아무 답도 돌아오지 않습니다.**

자주 묻는 질문

"DNSSEC 미적용" 자체는 위험하지 않습니다. 현재도 대다수 도메인이 DNSSEC 없이 운영되고 있습니다. 다만 DNS 캐시 포이즈닝 대응책으로서 가능하다면 도입을 검토할 가치는 있습니다.

DNSSEC을 강제하는 리졸버(많은 기업 네트워크와 일부 ISP)를 사용하는 사용자는 해당 도메인의 이름을 전혀 해석할 수 없게 될 수 있습니다(SERVFAIL로 처리됨). DNSSEC 활성화 직후 DS 레코드 반영을 기다리는 일시적인 상태가 아니라면 신속한 수정이 필요합니다.

DNSKEY 갱신(롤오버) 직후에는 신구 키가 리졸버 캐시에 일시적으로 혼재하여 리졸버마다 검증 결과가 다르게 나타날 수 있습니다. 시간을 두고 다시 확인해 보세요.

다릅니다. DNSSEC은 "이름 해석 응답이 변조되지 않았는지"를 보증하는 장치이고, SSL/TLS는 "통신 내용이 암호화되고 접속 대상이 인증서 소유자인지"를 보증하는 장치입니다. 둘은 독립적이며, 한쪽만 도입된 상태도 있을 수 있습니다.

이 도구는 DNSKEY 공개 여부와 리졸버의 AD 판정이라는 표면적인 상태만 확인합니다. 서명 체인(RRSIG·NSEC/NSEC3 일치 여부 등)에 대한 엄밀한 분석이 필요하다면 dnsviz.net 등 전문 도구를 함께 사용하세요.

여담 ― DNS에 "위조 방지" 장치를 추가하게 된 배경

DNS는 1983년 설계 당시 응답을 보낸 주체를 암호학적으로 확인할 수단이 없었습니다. 리졸버는 그럴듯한 트랜잭션 ID가 붙은 UDP 패킷이 돌아오면 그대로 신뢰하는, 성선설에 기반한 프로토콜이었기 때문에 발신지 IP 위조나 ID 추측이 가능하면 가짜 응답을 주입할 수 있었습니다. 2008년 보안 연구자 Dan Kaminsky는 이 약점을 이용해 실용적인 속도로 캐시 포이즈닝(가짜 레코드를 리졸버 캐시에 주입하는 공격)을 수행할 수 있음을 보여 업계에 충격을 주었습니다.

DNSSEC(DNS Security Extensions)은 이 문제에 대한 표준화된 해답으로, 공개키 암호를 사용해 "이 응답은 정당한 존 관리자가 서명한 것"임을 증명합니다. 도메인은 자신의 DNSKEY로 레코드에 전자 서명을 하고, 상위 존에 등록한 DS 레코드가 그 DNSKEY의 다이제스트를 보증함으로써 DNS 루트부터 개별 도메인까지 끊기지 않는 "신뢰 체인(Chain of Trust)"을 구축합니다.

DoH(DNS over HTTPS) 응답에 포함된 AD(Authenticated Data) 플래그는 리졸버 자신이 이 DNSSEC 검증을 대행한 결과입니다. 애플리케이션이 직접 서명 검증을 구현하지 않아도, 신뢰할 수 있는 리졸버에 조회해 AD=true가 반환되면 응답이 변조되지 않았음을 간접적으로 확인할 수 있습니다. 다만 이는 리졸버와 애플리케이션 사이의 통신 경로(HTTPS)가 별도로 보호되어 있다는 전제하에 성립합니다.

모든 여담 보기