DNSSEC로 DNS 응답의 무결성과 출처를 검증하는 방법
DNSSEC의 디지털 서명, 신뢰 체인, DNSKEY·RRSIG·DS 레코드와 운영 시 고려할 성능·호환성 이슈를 정리한다.
2026-08-14 · 최초 발행 2025-06-02
DNS는 인터넷의 전화번호부 역할을 하지만, 처음 설계될 때부터 응답 데이터의 무결성과 출처를 검증하는 구조는 아니었다. DNSSEC(DNS Security Extensions)는 기존 DNS에 디지털 서명을 더해 이 빈틈을 메운다.
IETF에서 표준화한 DNSSEC의 기본 사양은 RFC 4033, RFC 4034, RFC 4035에 정의되어 있다. DNS 프로토콜 자체를 대체하는 방식이 아니라, DNS 레코드와 키 정보를 이용해 응답이 위조되지 않았는지 확인하는 확장 기술이다.
DNS 응답이 공격 표면이 되는 지점
DNSSEC는 공격자가 캐시에 잘못된 정보를 넣어 정상 도메인 질의에 가짜 IP 주소를 돌려주도록 만드는 DNS 캐시 포이즈닝을 막는 데 쓰인다. Dan Kaminsky가 2008년에 발견한 대규모 DNS 취약점도 이런 위협과 맞닿아 있다.
질의와 응답 사이에서 데이터를 가로채 사용자를 가짜 웹사이트로 보내는 중간자 공격 역시 대상이다. 공격자가 정상 DNS 서버처럼 위장해 응답을 보내더라도, 검증 가능한 서명이 없으면 그 데이터를 신뢰할 수 없게 만든다.
서명 키와 신뢰 체인이 연결되는 방식
DNSSEC는 공개키와 개인키를 사용하는 비대칭 암호화 기반의 디지털 서명을 사용한다. 존 소유자는 개인키로 DNS 레코드에 서명하고, 클라이언트는 공개키로 서명을 확인해 데이터 무결성을 검증한다.
KSK(Key Signing Key)는 ZSK에 서명하는 상위 키이며 변경 빈도가 낮다. ZSK(Zone Signing Key)는 실제 DNS 레코드에 서명하는 키로, 주기적으로 변경한다. 신뢰 앵커(Trust Anchor)는 신뢰 체인의 시작점으로 루트 도메인의 KSK를 뜻한다.
이 키 구조는 루트 도메인부터 하위 도메인까지 이어지는 검증 경로를 만든다.
각 도메인 레벨에서 상위 도메인은 하위 도메인의 키를 연결하고, 클라이언트는 루트에서 출발해 이 체인을 따라 검증한다.
검증에 사용되는 DNS 레코드
DNSKEY 레코드에는 도메인의 공개키가 들어 있으며, 존 데이터를 검증하는 데 사용한다.
example.com. IN DNSKEY 256 3 8 AwEAAcQ...
example.com. IN DNSKEY 257 3 8 AwEAAbx...
RRSIG(Resource Record Signature)는 DNS 레코드 세트의 디지털 서명을 담는다. 서명 생성 및 만료 시간, 서명 알고리즘 등의 정보도 함께 포함한다.
example.com. IN RRSIG A 8 2 3600 20230615000000 20230601000000 12345 example.com. AOyn/k...
DS(Delegation Signer) 레코드는 하위 도메인 KSK의 해시값을 담고, 상위 도메인에 등록되어 신뢰 체인을 이어 준다.
example.com. IN DS 12345 8 2 A5B1C3...
NSEC와 NSEC3는 부재 증명(Proof of Non-existence)을 제공한다. 요청한 도메인이나 레코드 타입이 존재하지 않는다는 사실을 증명하는 레코드다. NSEC는 다음에 존재하는 도메인 이름을 가리키며, NSEC3는 존 열거 공격(Zone Enumeration)을 막기 위해 이를 개선한 방식이다.
키 생성부터 DS 등록까지
DNSSEC 적용은 KSK와 ZSK 쌍을 만들고, 안전한 키 관리 정책을 세우는 것에서 시작한다. BIND에서는 다음과 같이 키를 생성할 수 있다.
dnssec-keygen -a RSASHA256 -b 2048 -f KSK example.com
dnssec-keygen -a RSASHA256 -b 1024 example.com생성한 키로 DNS 존 파일의 모든 레코드에 서명한다.
dnssec-signzone -o example.com -k Kexample.com.+008+12345 example.com.zone Kexample.com.+008+67890그다음 상위 도메인 레지스트라에 DS 레코드를 등록해 신뢰 체인을 완성한다.
키 롤오버도 운영 과정에 포함된다. ZSK는 일반적으로 1-3개월마다, KSK는 일반적으로 12-24개월마다 교체한다. Pre-Publish, Double-Signature, RFC 5011 등 다양한 롤오버 방법을 활용할 수 있다.
리졸버가 서명을 확인하는 경로
클라이언트는 DNSSEC를 지원하는 리졸버로 쿼리를 보낸다. 리졸버는 권한 서버에서 응답과 RRSIG를 받고, DNSKEY 레코드를 요청해 서명을 검증한다. 이어 상위 도메인의 DS 레코드를 통해 신뢰 체인을 확인한다. 검증이 성공하면 응답을 전달하고, 실패하면 SERVFAIL을 반환한다.
도입 범위와 운영 부담
루트 존은 2010년 7월 15일에 서명이 완료되었다. gTLD(Generic Top-Level Domain)는 .com, .net, .org 등을 포함해 대부분 DNSSEC를 적용했으며, ccTLD(Country Code Top-Level Domain)도 .kr, .us, .de 등을 포함해 다수가 적용했다. 글로벌 도입률은 2023년 기준 약 30-40% 수준이며, 한국에서는 KISA가 .kr 도메인에 DNSSEC를 지원한다.
운영에서는 추가 레코드로 인한 DNS 응답 크기 증가를 고려해야 한다. UDP 패킷 크기 제한인 512 바이트 때문에 TCP 폴백이 늘어날 수 있고, 암호화 연산은 서버 부하를 높인다. EDNS0(Extension Mechanisms for DNS) 적용도 필요하다.
키 관리와 롤오버 절차는 복잡하며, 장애가 생겼을 때 트러블슈팅 난이도도 높아진다. 운영 인력의 전문성이 요구되는 이유다. 모든 DNS 서버와 리졸버가 DNSSEC를 지원하는 것도 아니므로, 검증 실패 시 도메인 접근 불가 문제가 생길 수 있다. 방화벽과 프록시를 포함한 네트워크 장비 호환성도 검토해야 한다.
DNSSEC를 활용하는 보안 구성
금융 서비스에서는 뱅킹 도메인의 보안을 강화하는 수단으로 사용할 수 있다. 미국 정부 기관은 .gov 도메인에 DNSSEC를 의무화했으며, 중요 인프라에서도 핵심 서비스 도메인 보호에 활용한다.
DANE(DNS-based Authentication of Named Entities)는 RFC 6698로 표준화되었다. TLS/SSL 인증서를 DNS에 게시하고 DNSSEC로 검증해 인증기관(CA) 시스템의 취약점을 보완한다.
_443._tcp.example.com. IN TLSA 3 0 1 a5b1c3...
이메일 보안에서도 SPF, DKIM, DMARC 레코드의 무결성을 보장하고, 이메일 스푸핑과 피싱 공격을 막는 데 활용할 수 있다.
기밀성은 별도의 기술로 보완한다
DNSSEC는 DNS 쿼리와 응답 자체의 기밀성을 보장하지 않는다. NSEC/NSEC3를 통한 존 데이터 노출 가능성, 느린 배포 및 채택 속도, 구현과 운영의 복잡성도 한계로 남는다.
DNS over TLS(DoT)는 TCP 포트 853을 통해 DNS 통신을 암호화한다. DNS over HTTPS(DoH)는 HTTPS로 DNS 쿼리를 암호화하며, DNS over QUIC(DoQ)는 QUIC 프로토콜을 사용한다. DNSSEC가 응답의 무결성과 출처를 확인한다면, 이 기술들은 DNS 통신 암호화의 공백을 보완한다.