DNSSEC
example.com과 같은 이름을 IP 주소로 변환하는 시스템인 DNS는 인증 없이 1983년에 설계되었습니다. 도메인의 권한 있는 서버에서 왔다고 주장하는 모든 답변이 허용되었습니다. DNSSEC는 모든 DNS 레코드에 암호화 서명을 첨부하여 클라이언트가 답변이 변조되지 않았는지 확인할 수 있도록 하여 이 문제를 해결합니다. 채택 속도는 느리지만 배포된 곳에서는 효과가 있습니다.
전체 기사 본문은 아래에 영어로 제공됩니다.
DNSSEC(도메인 이름 시스템 보안 확장)는 DNS 레코드에 암호화 서명을 추가하여 클라이언트가 DNS 응답의 신뢰성과 무결성을 확인할 수 있도록 합니다. DNSSEC가 없으면 네트워크 공격자는 DNS 응답을 스푸핑하고 공격자가 제어하는 서버로 트래픽을 리디렉션할 수 있습니다. 이는 DNS 하이재킹의 기초입니다. DNSSEC를 사용하면 스푸핑된 응답이 서명 확인에 실패하고 거부됩니다.
DNSSEC에 추가되는 기능
4가지 새로운 레코드 유형:
- RRSIG — 레코드 집합에 대한 서명입니다. 서명된 모든 레코드에는 해당 RRSIG가 있습니다.
- DNSKEY(영역에 대한 RRSIG 서명을 확인하는 데 사용되는 공개 키).
- DS(위임 서명자)는 상위 영역에 위치하며 하위 영역의 DNSKEY를 가리킵니다. 신뢰 체인을 설정합니다.
- NSEC/NSEC3 — 해당 영역에 이름이 존재하지 않음을 증명합니다. "이 이름은 존재하지 않습니다"라는 답변도 인증이 필요한 답변이기 때문에 필요합니다.
확인 작동 방식
example.com의 IP를 확인하려면:
- Resolver는 A 레코드에 대해 example.com을 쿼리합니다. IP와 RRSIG 서명을 가져옵니다.
- Resolver는 DNSKEY(영역 서명 키, ZSK)에 대해 example.com을 쿼리합니다.
- Resolver는 ZSK를 사용하여 RRSIG를 확인합니다.
- DNSKEY 자체를 확인하기 위해 확인자는 상위 영역(.com)에서 다음의 DS 레코드를 쿼리합니다. example.com.
- DS 레코드에는 .com의 키로 서명된 example.com의 DNSKEY 해시가 포함되어 있습니다.
- 이는 루트까지 반복되며 루트의 공개 키는 확인자에 하드코딩됩니다.
최종 결과: 루트에서 .com을 거쳐 example.com까지 확인된 체인이 원래 A 레코드에서 끝납니다. 모든 단계에서 모든 변조가 감지됩니다.
키 유형 및 회전
DNSSEC는 영역당 두 가지 키 유형을 사용합니다:
- Zone-Signing Key(ZSK). 실제 레코드(A, MX, TXT 등)에 서명합니다. 많이 사용되기 때문에 자주(개월~1년) 순환됩니다.
- 키 서명 키(KSK). ZSK에 서명합니다. 상위 영역이 참조하는 기준점이므로 거의 회전되지 않습니다. 순환하려면 등록 기관과 협력하여 DS 레코드를 업데이트해야 합니다.
루트 KSK는 약 5년에 한 번 순환됩니다. 2017년 교체는 전 세계 리졸버가 새로운 공개 키를 갖도록 하기 위해 처음이자 필요한 준비 기간이었습니다.
Adoption
DNSSEC 채택은 고르지 않습니다:
- TLD 레벨: 대부분의 주요 TLD가 서명되었습니다. .com, .org, .net, .gov, 대부분의 국가 코드.
- 도메인 수준: 2026년 현재 .com 도메인의 약 5%에 DNSSEC가 활성화되어 있습니다. — 느린 성장.
- Resolver 수준: 모든 주요 공개 확인자(1.1.1.1, 8.8.8.8, 9.9.9.9) DNSSEC를 검증합니다. 대부분의 ISP 확인자도 마찬가지입니다. 검증 없이 얻은 모든 것을 단순히 반환하지 않는 것입니다.
- 클라이언트 수준: 대부분의 운영 체제는 검증을 위해 구성된 확인자를 신뢰합니다. 그들은 서명 자체를 확인하지 않습니다. 몇 가지 응용 프로그램과 DNS-over-HTTPS 구현이 클라이언트 측 유효성 검사를 수행합니다.
채택이 느린 이유
여러 장벽:
- 운영 복잡성. 키를 생성해야 하며 레코드가 변경되면 서명이 다시 생성되고 정기적으로 롤링됩니다. 잘못된 구성으로 인해 도메인이 완전히 중단됩니다(모든 확인자가 SERVFAIL을 반환함).
- L더 큰 DNS 응답. 서명된 응답은 서명되지 않은 응답보다 몇 배 더 큽니다. 이전 DNS 인프라에서는 응답이 단일 UDP 패킷에 적합하다고 가정했습니다. 서명된 응답은 그렇지 않은 경우가 많으며 TCP 폴백이 필요합니다.
- L최종 사용자에게 제한된 이점이 있습니다. DNSSEC는 DNS 계층 변조로부터 보호하지만 대상 IP의 악성으로부터는 보호하지 않습니다. 대부분의 사용자는 DNSSEC가 언제 있는지 여부를 알지 못합니다.
- 일부 사용 사례에 대한 더 나은 대안입니다. 암호화된 DNS(DoH, DoT, DNSCrypt)는 경로상의 변조로부터 DNS 쿼리를 보호하여 동일한 위협의 대부분을 덜 복잡하게 처리합니다.
DNSSEC 및 암호화된 DNS
두 가지는 중복되지만 서로 다른 문제를 해결합니다.
- DNSSEC는 답변이 진짜이고 변조되지 않았음을 증명합니다. 쿼리 자체는 여전히 네트워크에 표시됩니다.
- 암호화된 DNS는 네트워크에서 쿼리와 답변을 숨기지만 답변이 진짜인지 증명하지는 않습니다. 단지 구성된 확인자를 신뢰합니다.
가장 강력한 설정: DNSSEC 검증 확인자에 대한 암호화된 DNS입니다. 전송 중인 쿼리를 숨기고 암호화 방식으로 답변을 확인하세요. DoH를 통한 Cloudflare 1.1.1.1 및 Google 8.8.8.8은 현재 두 가지를 모두 제공합니다.
DANE: DNSSEC가 활성화하는 것
DNSSEC가 잠금 해제하는 한 가지 다운스트림 기술은 DANE(명명된 엔터티의 DNS 기반 인증)입니다. DANE은 DNSSEC로 보호되는 DNS에 TLS 인증서 지문을 게시합니다. 브라우저는 인증 기관에만 의존하는 대신 DNS를 쿼리하여 웹사이트의 인증서를 확인할 수 있습니다. 채택이 제한됩니다(브라우저 구현 정책으로 인해 HTTPS가 아닌 SMTP에 주로 사용됨).
도메인이 DNSSEC 서명되었는지 확인하는 방법
명령줄 확인: dig +dnssec example.com — DNSSEC가 활성화된 경우 응답에 서명이 포함됩니다. DNSSEC-Analyzer(Verisign Labs)와 같은 온라인 도구는 전체 신뢰 체인을 시각적으로 보여줍니다. 브라우저 확장은 페이지당 DNSSEC 유효성 검사 상태를 표시할 수 있습니다.
자주 묻는 질문
- 내 도메인에 DNSSEC가 필요합니까?
- 엄격하게는 아닙니다. 그것이 제공하는 보호는 의미가 있지만 부분적입니다. 대부분의 개인 사이트에서는 DNSSEC를 실행하는 데 드는 운영 비용이 이점보다 더 큽니다. 금융 거래, 정부 서비스 또는 고가치 표적을 처리하는 사이트의 경우 DNSSEC와 DANE는 가치 있는 방어 계층을 추가합니다.
- DNSSEC는 모든 DNS 공격을 방지합니까?
- 아니요. DNSSEC는 유선상의 DNS 응답 변조를 방지하지만 유효한 서명이 있는 악의적인 권한 있는 서버, 등록자 계정 탈취(공격자가 새 키 게시) 또는 합법적인 DNS 확인 후 대상 IP에 대한 공격을 방지하지는 않습니다. 완전한 솔루션이 아닌 레이어입니다.
- 내 브라우저가 DNSSEC를 확인하지 않는 이유는 무엇입니까?
- 브라우저는 DNSSEC 검증을 구성된 확인자에게 위임합니다. 확인자가 잘못된 답변을 확인하고 거부하면 브라우저는 해당 답변을 볼 수 없습니다. 브라우저 측 검증에 대한 제안이 있었지만 채택되지 않았습니다. 검증 확인자(1.1.1.1, 9.9.9.9)를 사용하면 DNSSEC의 이점을 얻을 수 있습니다.
- DNSSEC 서명 도메인에 문제가 있으면 어떻게 되나요?
- 유효성 검사가 실패하고 대부분의 확인자가 SERVFAIL을 반환합니다. 도메인에 연결할 수 없는 것으로 나타납니다. 이는 프로덕션에서 발생했습니다(HBO Max의 2021년 중단은 DNSSEC 구성 오류였습니다). 절충: DNSSEC가 작동하면 안전합니다. 깨지면 큰 소리로 부서집니다.
- DNSSEC는 HTTPS를 통한 DNS와 동일합니까?
- 아니요. DNSSEC는 DNS 응답에 서명을 추가하여 진위 여부를 확인합니다. DoH(DNS over HTTPS)는 전송 중인 DNS 쿼리를 암호화합니다. 이들은 보완적이며 함께 사용하는 것이 가장 좋습니다.