도메인 이름 시스템 DNS는 인터넷의 전화번호부 역할을 하며 사람이 읽을 수 있는 이름을 하루에도 수십억 번씩 IP 주소로 변환합니다. DNS 데이터베이스에는 IP 주소 및 도메인 별칭과 같은 중요한 DNS 레코드가 저장되어 있어 사이버 위협의 표적이 되고 있습니다. 하지만 이 중요한 인프라는 1980년대에 보안 기능이 내장되지 않은 채 설계되었습니다. 기존의 DNS 유효성 검사는 응답에 대해 동일한 IP 주소를 일치시키는 데 의존했는데, 이는 IP 주소가 스푸핑될 수 있기 때문에 안전하지 않습니다. DNSSEC는 이러한 근본적인 차이를 해결하기 위해 존재하며, 원래 신뢰에 기반하여 운영되던 시스템에 암호화 검증을 추가합니다.
DNSSEC 요약
일반적으로 DNSSEC로 알려진 도메인 이름 시스템 보안 확장은 DNS 보안 확장의 약자로, DNS 데이터에 암호화 서명을 추가하는 IETF 프로토콜 사양의 집합입니다. 이러한 서명을 통해 DNS 확인자는 수신하는 정보가 실제로 신뢰할 수 있는 출처에서 왔으며 그 과정에서 변조되지 않았는지 확인할 수 있습니다.
DNSSEC가 해결하는 핵심 문제는 간단합니다. 이 기능이 없으면 공격자는 가짜 DNS 응답을 확인자 캐시에 주입할 수 있습니다. DNS 캐시 포이즈닝으로 알려진 이 공격은 사용자 모르게 악성 사이트로 리디렉션합니다. DNSSEC는 데이터 원본 인증을 활성화하고 디지털 서명을 통해 DNS 레코드의 무결성을 보장하며 공개 키 암호화를 사용하고 신중한 DNS 영역 키 관리를 통해 사칭 및 데이터 변조를 방지하여 이를 방지합니다.
인터넷 엔지니어링 태스크포스(IETF)는 2000년대 초에 RFC 4033, 4034, 4035를 포함한 일련의 RFC를 통해 DNSSEC를 표준화했습니다. 2010년 7월에 ICANN이 DNS 루트 영역에 서명함으로써 전 세계적으로 실질적인 DNSSEC 배포를 가능하게 하는 글로벌 신뢰 앵커를 구축한 것이 배포의 주요 이정표가 되었습니다.
DNSSEC가 하는 일과 하지 않는 일을 이해하는 것이 중요합니다. DNSSEC는 DNS 데이터를 인증하여A, AAAA, MX 및 TXT 레코드가 진짜이고 수정되지 않았는지 확인합니다. 하지만 DNS 쿼리나 응답은 암호화하지 않습니다. DNS 트래픽은 관찰할 수 있는 모든 사람에게 그대로 표시됩니다. 암호화를 위해서는 TLS를 통한 DNS 또는 HTTPS를 통한 DNS와 같은 보완 프로토콜이 필요합니다.
또한 DNSSEC가 DNS 인프라에 대한 모든 공격을 막는 것은 아닙니다. 볼륨 DDoS 공격은 서명 여부와 관계없이 여전히 DNS 서버를 압도할 수 있습니다. 그리고 DNSSEC는 사용자가 합법적으로 등록된 피싱 도메인을 방문하는 것을 막을 수 없습니다.
키 관리와 신뢰 체인 구축이 필요하기 때문에 DNSSEC를 구현하는 것은 복잡할 수 있습니다. DNSSEC를 성공적으로 배포하려면 부모 영역과 체인의 모든 영역도 서명해야 합니다.
ICANN 데이터에 따르면 현재 대부분의 최상위 도메인은 DNSSEC를 지원하며, 1,400개 이상의 TLD가 서명되어 있습니다. 그러나 두 번째 수준 도메인 채택은 다른 이야기를 들려줍니다. .com 영역의 약 1~2%만이 DNSSEC를 사용하도록 설정되어 있으며, .nl(네덜란드) 및 .se(스웨덴)와 같은 국가 코드 TLD는 의무 정책으로 인해 서명률이 90%를 초과합니다.
왜 신경 써야 할까요? DNSSEC가 없으면 조직에서 수행하는 모든 DNS 쿼리는 조용한 조작에 취약하기 때문입니다. 해결사의 캐시를 오염시키는 공격자는 직원을 자격 증명 수집 사이트로 리디렉션하거나 이메일 전송을 가로챌 수 있으며, 이 모든 것이 명백한 경고 없이 이루어집니다.
DNS와 DNSSEC의 결합 방식
DNSSEC에 대해 자세히 알아보기 전에 오늘날 도메인 네임 시스템이 어떻게 작동하는지 간략하게 정리해 보겠습니다. 브라우저에 URL을 입력하면 컴퓨터의 스텁 확인자는인터넷 서비스 제공업체, 기업 네트워크 또는 Google의 8.8.8.8 또는 Cloudflare의 1.1.1.1과 같은 공용 서비스에서 제공하는 재귀적 DNS 확인자에 연결합니다. DNS 확인자는 서버 체인을 따라 올바른 IP 주소를 검색하여 DNS 쿼리를 처리하므로 효율적이고 정확한 확인을 보장합니다.
www.example.com 확인을 고려해 보세요. 재귀 DNS 확인자는 먼저 13개의 논리적 루트 DNS 이름 서버 중 하나를 쿼리하여 .com에 대한 정보를 요청합니다. 루트 서버는 Verisign에서 운영하는 .com TLD 서버에 대한 추천으로 응답합니다. 그런 다음 확인자는 .com 서버에 example.com에 대한 정보를 요청하여 example.com의 권한 있는 이름 서버에 대한 또 다른 추천을 받습니다. 마지막으로 확인자는 해당 권한 있는 서버를 쿼리하여 www.example.com 에 대한 IP 주소가 포함된 실제 A 레코드를 가져옵니다.
이 계층적 시스템 내에서 리소스 레코드, 권한 있는 이름 서버, 영역 서명 키와같은 다양한 DNS 구성 요소가 함께 작동하여각 DNS 영역을 관리, 제어 및 보호합니다.
이 우아하고 계층적인 시스템은 1987년 RFC 1034와 1035에 정의되었습니다. 문제는 무엇일까요? 기존 DNS 프로토콜은 강력한 인증 없이 설계되었습니다. 응답은 주로 공격자들이 악용하는 시스템인 소스 IP 주소와 16비트 트랜잭션 ID를일치시키는 방식으로 검증되었습니다.
2008년 발생한 카민스키 취약점은 이 설계가 얼마나 취약한지 잘 보여주었습니다. 보안 연구원 댄 카민스키는 공격자가 단일 쿼리 기간 동안 추측을 쏟아내어 높은 확률로 확인자 캐시에 가짜 응답을 주입할 수 있음을 보여주었습니다. 이 공개로 인해 업계 전반에서 긴급 패치가 이루어졌고 전 세계적으로 DNSSEC 배포가 크게 가속화되었습니다.
DNSSEC는 핵심 쿼리/응답 모델을 변경하지 않고 기존 DNS를 감싸는 확장 계층으로 통합됩니다. 서명되지 않은 영역은 유효성 검사하지 않는 확인자에 대해 계속 정상적으로 작동합니다. 유효성 검사 확인자는 서명된 영역에 대해 추가 암호화 검사를 수행하기만 하면 됩니다. 이러한 이전 버전과의 호환성은 DNS 네임스페이스 전반에 걸쳐 점진적으로 도입하는 데 매우 중요했습니다.
핵심 DNSSEC 개념 및 레코드 유형
DNSSEC는 검증 가능한 신뢰 체인을 생성하기 위해 함께 작동하는 몇 가지 새로운 DNS 리소스 레코드 유형을 도입합니다. 이러한 기록과 그 관계를 이해하는 것은 서명된 영역으로 작업하는 모든 사람에게 필수적입니다.
DNSSEC의 기본 단위는 리소스 레코드 세트 또는 RRSet입니다. 이것은 동일한 이름, 유형 및 클래스를 공유하는 DNS 레코드의 그룹입니다. DNSSEC는 개별 레코드에 서명하는 대신 전체 RRSet에 서명합니다. 이 접근 방식은 원자 무결성을 보장합니다. 모든 레코드의 서명을 무효화하지 않고는 세트의 레코드 하나를 조작할 수 없습니다.
RRSIG 레코드에는 RRSet을 덮는 디지털 서명이 포함되어 있습니다. 영역의 개인 키를 사용하여 생성된 각 리소스 레코드 서명에는 서명자 이름, 유효 기간 및 사용된 알고리즘과 같은 메타데이터가 포함됩니다. 확인자는 RRSet 데이터의 해시를 다시 계산하고 암호화 서명과 비교하여 이러한 서명을 확인합니다.
DNSKEY 레코드는 서명을 확인하는 데 사용되는 공개 키를 게시합니다. 이러한 레코드는 영역 정점(예: example.com.)에 표시되며 키의 역할을 나타내는 플래그를 포함합니다. 플래그 값 256은 영역 서명 키를 나타내고, 257은 키 서명 키를 나타냅니다.
DS 레코드 또는 위임 서명자 레코드는 부모 영역과 자식 영역 간의 링크를 만듭니다. 상위 영역에 저장되며 하위 영역의 공개 키의 암호화 해시를 포함합니다. 예를 들어, example.com에 대한 DS 레코드는 .com 영역에 저장되어 확인자는 example.com의 DNSKEY 레코드가 진짜인지 확인할 수 있습니다. 각 영역의 공개 키는 부모 영역의 개인 키로 서명되며, 이는 DNSSEC에서 신뢰 체인을 설정하는 데 필수적입니다. 이 프로세스를 통해 부모 영역에서 하위 영역으로 신뢰가 전달되어 안전하고 검증 가능한 계층 구조를 형성합니다.
NSEC 및 NSEC3 레코드는 인증된 존재 거부를 가능하게 합니다. DNS 쿼리가 존재하지 않는 이름을 요청할 때 이러한 레코드는 해당 이름이 실제로 존재하지 않음을 증명하여 공격자가 존재하지 않는 이름을 진짜라고 주장할 수 없도록 합니다. NSEC는 기존 이름을 정렬된 순서대로 체인으로 연결하는 반면, NSEC3는 암호화 해시 레코드 이름을 사용하여 영역 콘텐츠를 쉽게 열거할 수 없도록 합니다.
CDS 및 CDNSKEY 레코드는 자동화된 키 관리를 지원합니다. 이를 통해 자식 영역은 업데이트된 DS 또는 DNSKEY 정보를 부모 영역에 알릴 수 있으므로 기존에 등록기관에 필요했던 수동 조정을 줄일 수 있습니다.
영역 서명 키(ZSK)와 키 서명 키(KSK)를 분리하는 것은 특별한 주의가 필요합니다. ZSK는 일반 영역 데이터(A, AAAA, MX 레코드)에 서명하는 반면, KSK는 DNSKEY RRSet 자체에만 서명합니다. 이러한 분리를 통해 운영자는 보다 안정적인 KSK 및 상위 영역의 관련 DS 레코드는 변경하지 않고 ZSK를 자주 교체할 수 있습니다.
시스템 보안 확장 이름 지정
NSSE(네임 시스템 보안 확장)는 도메인 네임 시스템(DNS)의 보안을 강화하기 위해 설계된 포괄적인 프로토콜 및 표준 집합을 나타냅니다. NSSE의 핵심은 디지털 서명과 공개 키 암호화를 사용하여 DNS 데이터를 인증하고 무결성을 보장하는 DNSSEC입니다. 이러한 시스템 보안 확장의 주요 목적은DNS 데이터를 조작하고 사용자를 사기성 사이트로 리디렉션하는 DNS 스푸핑 및 DNS 캐시 포이즈닝 공격과 같은 위협을 방어하는것입니다.
도메인 소유자는 네임 시스템 보안 확장을 활용하여 도메인과 연결된 DNS 데이터가 인터넷을 통해 이동하는 동안 변경되지 않고 진본임을 보장할 수 있습니다. 이는 서명된 각 영역에서 공개 키 인프라를 사용하여 이루어지며, 이 공개 키 인프라는 확인자가 DNS 레코드의 디지털 서명을 확인하는 데 사용하는 공개 키를 게시합니다. 따라서 사용자와 애플리케이션은 도메인 이름 시스템에서 수신하는 정보가 합법적이라고 신뢰할 수 있으므로 사용자 신뢰를 유지하고 다양한 사이버 위협으로부터 보호할 수 있습니다.
DNSSEC 유효성 검사의 엔드투엔드 작동 방식
DNSSEC 유효성 검사는 DNS 확인 경로를 따라 신뢰 앵커라고 하는 알려진 시작점에서 검증을 구축합니다. 대부분의 확인자의 경우 이 앵커는 루트 영역의 KSK로, IANA 및 확인자 소프트웨어 업데이트를 통해 배포됩니다. 유효성을 검사하는 재귀 확인자는 서명된 도메인에 대한 쿼리를 처리할 때 DNS 계층 구조의 각 단계에서 암호화 확인을 수행합니다. 확인자는 이미 루트 DNSKEY를 신뢰합니다. 이 키를 사용하여 TLD(.com 등)의 DS 레코드를 포함하는 루트 영역의 RRSIG를 확인합니다. 그런 다음 .com의 DNSKEY를 가져와서 DS 해시와 일치하는지 확인합니다. 이 프로세스는 대상 도메인까지 계속됩니다.
완전 서명된 환경에서 www.example.com 을 쿼리해 보세요. 확인자가 확인합니다:
- 루트의 DNSKEY(신뢰할 수 있는 앵커)가 .com의 DS 레코드에 서명합니다.
- .com의 DNSKEY는 DS 해시와 일치하고 example.com의 DS 레코드에 서명합니다.
- example.com의 DNSKEY는 해당 DS와 일치하고 www에 대한 A 레코드에 서명합니다.
이렇게 하면 루트에서 요청된 DNS 레코드까지 끊어지지 않는 신뢰 체인이 생성됩니다. 잘못된 서명, 만료된 RRSIG 또는 DS/DNSKEY 해시 실패와 같은 불일치가 발생하면 체인이 중단됩니다.
ICANN에서 의도적으로 잘못 구성한 dnssec-failed.org와 같은 테스트 도메인을 사용하여 유효성 검사 실패를 관찰할 수 있습니다. 유효성 검사 확인자는 이 도메인에 대해 SERVFAIL을 반환하여 액세스를 완전히 차단합니다. 유효성 검사 확인자를 사용하지 않는 사용자(여전히 전 세계적으로 약 70%)의 경우 도메인이 정상적으로 해결되므로 현재 배포의 격차를 보여줍니다.
DNSSEC는 HTTP 또는 SMTP와 같은 애플리케이션 프로토콜을 변경하지 않습니다. 단지 애플리케이션이 수신하는 IP 주소 및 기타 DNS 데이터가 변경되지 않은 진짜 데이터인지 확인할 뿐입니다. 브라우저는 여전히 정상적으로 HTTPS 연결을 만들며, DNSSEC는 합법적인 서버를 가리키는 DNS 쿼리 응답을 보장할 뿐입니다.
인증된 존재 거부의 경우, NSEC 또는 NSEC3 레코드는 쿼리된 이름 또는 유형이 존재하지 않음을 증명합니다. 확인자는 영역에 어떤 이름이 존재하는지 보여주는 암호화 서명된 증거를 수신하여 쿼리된 이름이 나타날 수 있는 간격을 확인할 수 있습니다.
실제 DNSSEC 리소스 레코드
주요 DNSSEC 관련 DNS 레코드 유형을 보다 실용적으로 자세히 살펴보겠습니다.
RRSIG 레코드는 영역의 개인 키(일반적으로 일반 레코드의 경우 ZSK)를 사용하여 생성됩니다. 각 서명은 서명 알고리즘(예: ECDSAP256SHA256), 서명된 이름의 레이블 수, 원본 TTL 및 시작/만료 타임스탬프를 지정합니다. 이러한 타임스탬프는 매우 중요합니다. 확인자는 일반적으로 30일로 설정된 유효 기간을 벗어난 서명을 거부합니다. 영역 운영자는 유효성 검사 실패를 방지하기 위해 만료 전에 레코드를 사임해야 합니다.
DNSKEY 레코드는 영역 정점에 나타나며 롤오버 기간 동안 여러 개의 키를 포함할 수 있습니다. 플래그 필드는 키 역할을 구분합니다. 257은 SEP(보안 진입점) 비트가 설정된 KSK를 나타내고 256은 ZSK를 나타냅니다. 키 태그(키 데이터에서 계산된 16비트 식별자)는 확인자가 DNSKEY 레코드를 해당 DS 레코드와 빠르게 일치시키는 데 도움이 됩니다.
상위 영역의 DS 레코드에는 하위 영역의 KSK 해시가 포함됩니다. 일반적인 DS 레코드에는 키 태그, 알고리즘 번호, 다이제스트 유형(일반적으로 SHA-256), 다이제스트 자체가 포함됩니다. DNSSEC 유효성 검사 중에 확인자는 자식의 DNSKEY를 가져와서 해시를 계산하고 비교합니다. 불일치하면 BOGUS 상태가 발생하여 유효성 검사에 실패합니다.
NSEC 레코드는 표준 정렬된 순서로 영역의 이름을 통해 연결됩니다. 각 NSEC는 다음 기존 이름을 가리키고 해당 이름에 있는 레코드 유형을 나열합니다. 이렇게 하면 존재하지 않음을 증명하지만, 공격자가 체인을 따라 모든 이름을 열거할 수 있는 ‘존 워킹’에 존 콘텐츠가 노출됩니다.
NSEC3는 체인 연결 전에 솔트와 반복 횟수로 이름을 해싱하여 영역 워킹을 해결합니다. 이렇게 하면 사소한 열거를 방지할 수 있지만, 단호한 공격자는 여전히 오프라인에서 예측 가능한 이름을 크랙할 수 있습니다. 옵트아웃 플래그는 서명된 영역 내에서 서명되지 않은 위임을 허용하므로 서명되지 않은 하위 도메인이 많은 대규모 영역에 유용합니다.
CDS 및 CDNSKEY 레코드는 DS 및 DNSKEY 형식을 미러링하지만 자식 영역 자체에 게시됩니다. 상위 영역 운영자는 이러한 레코드를 폴링하여 위임 서명자 레코드를 자동으로 업데이트하여 키 롤오버 및 초기 DNSSEC 배포를 간소화할 수 있습니다.
DNS 레코드 그룹화
DNSSEC 구현의 기본 측면은 DNS 레코드를 리소스 레코드 세트(RRSet)로 그룹화하는 것입니다. RRSet은 영역 내에서 동일한 이름과 유형을 공유하는 DNS 레코드의 모음입니다. DNSSEC는 각 개별 레코드에 서명하는 대신 단일 RRSIG 레코드로 전체 RRSet에 서명합니다. 이 접근 방식은 DNS 데이터 서명 및 유효성 검사 프로세스를 간소화하여 도메인 소유자와 확인자 모두에게 더 효율적으로 만들어 줍니다.
DNS 레코드를 RRSet으로 그룹화하면 DNSSEC 구현이 간소화될 뿐만 아니라 DNS 인프라의 관리 용이성도 향상됩니다. RRSet 내의 레코드가 변경되면 전체 세트가 다시 서명되어 모든 관련 DNS 데이터의 무결성과 신뢰성이 유지됩니다. 도메인 소유자의 경우, 이는 서명을 관리할 때 복잡성이 줄어들고 DNS 레코드의 변조 또는 무단 변경에 대해 더욱 강력하게 방어할 수 있음을 의미합니다. 궁극적으로 DNS 레코드를 그룹화하는 것은 최신 DNS 인프라의 확장성과 보안을 지원하는 모범 사례입니다.
영역 서명 키, 서명 모드 및 키 관리
DDNSSEC 키 관리는 두 가지 역할을 중심으로 합니다. ZSK(영역 서명 키)는 영역 데이터-A, AAAA, MX, TXT 및 기타 일반 레코드의 일상적인 서명을 처리합니다. 키 서명 키(KSK) 는 더 제한적이지만 중요한 기능을 수행하며, DNSKEY RRSet만 서명하여 부모 영역의 DS 레코드에 대한 신뢰할 수 있는 링크를 만듭니다.
운영자가 이러한 역할을 분리하는 데는 그럴 만한 이유가 있습니다. ZSK 개인 키는 자주 사용되며 노출 위험이 높기 때문에 30~90일마다 교체하면 유출로 인한 잠재적 피해를 줄일 수 있습니다. KSK는 1년에 한 번이하로거의 변경되지 않는데, 이는 각 로테이션마다 상위 영역의 DS 레코드를 업데이트해야 하며 일반적으로 등록기관의 조정이 필요하기때문입니다.
DNSSEC 구현에는 세 가지 주요 서명 모드가 있습니다:
- 오프라인 서명: 에어 갭 머신 또는 HSM에서 영역이 서명된 다음 서명된 영역 파일이 권한이 있는 서버로 전송됩니다. 보안이 운영 편의성보다 중요한 정적 영역에 가장 적합합니다.
- 중앙 집중식 온라인 서명: 전용 서명 서비스가 서명되지 않은 업데이트를 수신하여 권한 있는 DNS 서버에 배포하기 전에 서명합니다. 동적 업데이트 지원과 보안의 균형을 맞춥니다.
- 즉시 서명: 권한 있는 서버는 DNS 요청이 도착하면 실시간으로 DNSSEC 서명을 생성합니다. 매우 동적인 영역에 적합하지만 서버가 손상될 경우 키 노출 위험이 증가합니다.
키 롤오버는 신뢰의 사슬이 끊어지지 않도록 신중한 타이밍이 필요합니다. 표준 접근 방식은 새 키를 미리 게시하는 것입니다. 새 키를 DNSKEY RRSet에 추가하고 캐시가 만료될 때까지 기다린 다음(일반적으로 두 번의 TTL 기간) 이전 키를 폐기합니다. KSK 롤오버의 경우, 새 DS는 이전 KSK를 제거하기 전에 부모 영역을 통해 전파되어야 합니다.
2018년 루트 KSK 롤오버는 그 위험성을 잘 보여주었습니다. 광범위한 준비에도 불구하고 약 0.3%의 확인자가 신뢰 앵커 업데이트에 실패하여 일시적인 서버 실패 응답을 경험했습니다. 단일 영역의 경우 이러한 오류는 사소해 보일 수 있지만,영향을 받는 사용자에게는 사실상 도메인을 오프라인 상태로 만들 수있습니다.
위임 서명자
위임 서명자(DS) 레코드는 DNS 계층 구조 내에서 자식 영역의 보안을 부모 영역에 연결하는 DNSSEC의 신뢰 체인의 초석입니다. DS 레코드에는 자식 영역의 키 서명 키(KSK)의 암호화 해시 버전이 포함되어 있으며, 이 키 서명 키는 부모 영역에 게시됩니다. 이를 통해 재귀 확인자는 자식 영역에서 제공한 DNSKEY 레코드가 진짜이고 변조되지 않았는지 확인할 수 있습니다.
이 연결을 설정함으로써 도메인 소유자는 DS 레코드를 통해 부모 영역에서 자신의 DNS 데이터까지 신뢰를 확장하여 확인 프로세스의 모든 단계가 유효성을 검사할 수 있습니다. 이 메커니즘은 공격자가 체인의 어느 지점에서든 사기성 DNS 데이터를 삽입하는 것을 방지하므로 전체 DNS 인프라의 무결성을 유지하는 데 필수적입니다. 도메인 소유자의 경우 위임 서명자 레코드를 올바르게 구성하는 것은 DNSSEC를 배포하고 DNS 기반 공격으로부터 도메인을 보호하는 데 있어 매우 중요한 단계입니다.
DNSSEC의 장점과 한계
DNSSEC의 주요 가치는 DNS 캐시 중독 및 DNS 스푸핑 공격을 방어하는 것입니다. 응답의 신뢰성을 암호화 방식으로 증명함으로써 공격자가 사용자를 피싱 사이트로 조용히 리디렉션하거나 가짜 MX 레코드를 통해 이메일을 가로채는 것을 방지합니다. 2008년의 카민스키 취약점은 이러한 공격이 얼마나 파괴적인지 보여주었습니다. DNSSEC는 서명된 영역에 대해 근본적으로 무력화합니다.
기본 보호 외에도 DNSSEC는 고급 보안 애플리케이션을 지원합니다. DANE(DNS 기반 명명된 엔터티 인증)을 사용하면 도메인 소유자는 TLSA 레코드를 사용하여 DNS에 직접 TLS 인증서 정보를 게시할 수 있습니다. 이를 통해 기존 인증 기관에만 의존하지 않고 SMTP 서버 또는 웹 서비스에 대한 인증서를 확인할 수 있습니다. 이러한 애플리케이션에는 인증된 DNS 데이터가 필요한데 , 바로 DNSSEC가 제공하는 것입니다.
제한 사항을 이해하는 것도 마찬가지로 중요합니다:
- 기밀성 없음: DNSSEC는 인증은 하지만 암호화는 하지 않습니다. DNS 쿼리 및 DNS 쿼리 응답은 관찰자에게 계속 표시됩니다. 암호화에는 TLS를 통한 DNS 또는 HTTPS를 통한 DNS가 필요합니다.
- DDoS 보호 기능 없음: DNSSEC는 DNS 인프라에 대한 볼륨 공격을 막을 수 없습니다. 실제로 서명된 응답이 클수록 증폭 공격이 더 심해질 수 있습니다.
- 합법적으로 보이는 위협에 대한 보호 기능이 없습니다: DNSSEC는 합법적으로 등록되고 올바르게 서명된 도메인 이름을 오타 스쿼팅하거나 사용자가 잘못된 도메인 이름을 신뢰하는 것을 방지할 수 없습니다.
성능 고려 사항에는 상당히 큰 DNS 응답이 포함됩니다. 서명은 RRSet당 약 500바이트가 추가됩니다 . 이로 인해 때때로 TCP 폴백 (지연 시간 추가)이 트리거되고 대역폭 소비가 증가합니다. DNSSEC를 사용하는 개방형 확인자는 일반 DNS에 비해 리플렉션 공격을 50배 이상 증폭시킬 수 있습니다.
이러한 장단점에도 불구하고 ICANN과 NIST를 비롯한 보안 기관에서는 가치가 높은 도메인에 DNSSEC를 권장합니다. 오버헤드가 있는 것은 사실이지만, DNS 스푸핑이 심각한 공격을 가능하게 할 수 있는 공개 서비스의 경우 보호 기능이 복잡성을 정당화할 수 있습니다.
위험, 도전 과제 및 채택이 여전히 불균등한 이유
DNSSEC는 도입 주저의 상당 부분을 설명하는 운영상의 위험을 소개합니다. 잘못된 구성(만료된 서명, DS/DNSKEY 불일치 또는 잘못된 서명 체인)으로 인해 유효성 검사에 실패할 수 있습니다. 리졸버 유효성 검사에 뒤처진 약 30%의 사용자에게는 잘못 구성된 영역이 작동을 멈추기만 하면 됩니다. 점진적인 성능 저하가 없으며 쿼리는 SERVFAIL을 반환합니다.
몇 가지 장벽으로 인해 DNSSEC 배포가 지연되고 있습니다:
- 다자간 조정: 서명을 하려면 도메인 소유자, 등록기관 및 DNS 호스팅 공급업체 간의 조율이 필요합니다. DS 레코드는 등록기관 시스템을 통해 상위 영역에 도달해야 합니다.
- 전문성 격차: 많은 조직에서 DNSSEC 경험이 부족합니다. 잘못된 구성으로 인한 서비스 중단에 대한 두려움 때문에 시작하지 못합니다.
- 레거시 인프라: 일부 엔터프라이즈 환경에는 DNSSEC 유효성 검사를 완전히 지원하지 않는 확인자 또는 어플라이언스가 포함되어 있어 호환성 문제가 발생할 수 있습니다.
도입 통계는 고르지 않은 진전을 보여줍니다. 루트 DNS 영역은 2010년부터 서명되었으며, 현재 1,400개 이상의 TLD가 DNSSEC를 지원합니다. 그러나 두 번째 수준의 채택은 매우 다양합니다. .nl 영역은 레지스트리 인센티브와 의무 정책에 힘입어 95% 이상의 서명이 이루어졌습니다. 반면 .com은 1.5% 정도에 불과하며 수백만개의 도메인이 서명되지 않은 상태로 남아 있습니다.
확인자 측면에서, APNIC의 측정에 따르면 전 세계적으로 DNS 확인자의 약 30%가 DNSSEC 유효성 검사를 수행하며, 이는 2018년의 약 10%에서 증가한 수치입니다. 진전이 계속되고 있지만 대부분의 최종 사용자는 여전히 유효성이 검사되지 않은 DNS 응답을 받고 있습니다.
DNSSEC는 유효성 검사 실패 외에도 보안 고려 사항을 제시합니다. 대량의 서명된 응답은 권한 있는 서버를 DNS 증폭 공격에 매력적으로 만듭니다. 운영자는 응답 속도 제한을 구현하고 확인자 구성 모범 사례를 준수하여 자신도 모르는 사이에 공격 인프라가 되지 않도록 해야 합니다.
주요 기관들은 계속해서 더 광범위한 도입을 지지하고 있습니다. ICANN은 배포 가이드를 발행하고 있으며, 국가 사이버 보안 기관은 정부 및 중요 인프라 도메인에 DNSSEC를 점점 더 많이 권장하고 있습니다. CDS/CDNSKEY를 통한 자동화로 운영상의 마찰이 줄어들면서 2030년에는 2단계 도입이 50%에 달할 것으로 예상됩니다.
실제 운영: DNS 루트 영역 서명식 및 신뢰 앵커
DNS 루트 영역은 DNSSEC 아키텍처에서 고유한 위치를 차지합니다. DS 레코드를 제공할 상위 영역이 없기 때문에 루트의 KSK는 최종 신뢰 앵커로서 대역 외에서 신뢰되어야 합니다. 모든DNSSEC 신뢰 체인이 여기에서 시작되므로 이를 올바르게 설정하는 것은 매우 중요합니다.
ICANN은 미국과 유럽의 안전한 시설에서 매년 4~6회 루트 서명식을 진행합니다. 이러한 서명식에는 특별한 절차적 통제가 수반됩니다: 하드웨어 보안 모듈(HSM)은 루트 개인키를 저장하며, 여러 명의 암호화 담당자가 스마트카드와 PIN을 동시에 사용할 때만 액세스합니다. 물리적 보호 장치에는 변조 방지 가방, 모니터링되는 금고, 완전한 비디오 문서가 포함됩니다.
2010년 7월의 초기 루트 영역 서명은 DNSSEC가 이론에서 실제 글로벌 배포로 전환하는 계기가 되었습니다. 기존 2010년 KSK를 KSK-2016으로 교체하는 2018년 KSK 롤오버를 통해 시스템의 기본 신뢰 앵커를 업데이트할 수 있는 능력을 테스트했습니다. 광범위한 지원에도 불구하고 약 0.2%의 해결자가 오래된 소프트웨어 또는 구성으로 인해 문제를 경험했습니다. 향후 롤오버는 2020년대 중반으로 예정되어 있습니다.
재귀 확인자는 소프트웨어 배포 또는 IANA에서 유지 관리하는 자동 업데이트 프로토콜을 통해 루트 신뢰 앵커를 얻습니다. 최신 리졸버 소프트웨어에는 일반적으로 최신 앵커와 업데이트를 가져오는 메커니즘이 포함되어 있어 키가 변경되더라도 신뢰 체인이 그대로 유지됩니다.
이러한 절차는 복잡해 보일 수 있지만 정당한 보증을 제공합니다. 루트 영역의 무결성은 전 세계적으로 DNSSEC를 뒷받침하며, 문서화되고 감사 가능한 프로세스는 이 중요한 인프라가 적절하게 엄격하게 운영된다는 신뢰를 구축합니다.
도메인에 DNSSEC 배포하기
도메인에 DNSSEC를 사용하도록 설정할 준비가 되셨나요? 이 프로세스에는 검증부터 지속적인 유지 관리까지 여러 단계가 포함됩니다.
확인해야 할 전제 조건:
- TLD가 DNSSEC를 지원하는지 여부(ICANN의 배포 리소스 확인)
- 등록기관이 DS 기록 제출을 수락하는 경우
- DNS 호스팅 공급업체가 영역 서명 및 DNSKEY 관리를 지원합니다.
Cloudflare 및 AWS Route 53과 같은 많은 관리형 DNS 공급자는 서명을 자동으로 처리합니다. 자체 관리 영역의 경우 권한 있는 서버 소프트웨어와 호환되는 서명 도구가 필요합니다.
일반적인 배포 단계:
- ZSK 및 KSK 쌍 생성 (또는 공급자 관리 서명 활성화)
- DNS 영역에 서명하고 로컬에서 DNSSEC 서명 확인
- DNSKEY 레코드 게시 (선택 사항으로 자동화된 DS 관리를 위한 CDS/CDNSKEY)
- 등록기관의 인터페이스를 통해 DS 기록 제출하기
- 전파 시간을 허용한 다음 전체 체인을 확인합니다.
유효성 검사도 마찬가지로 중요합니다. 조직에서 재귀 확인자를 운영하는 경우 DNSSEC 유효성 검사를 사용 설정하세요 (예: BIND의 dnssec-validation yes ). 알려진 도메인에 대해 테스트: 제대로 서명된 사이트는 AD(인증된 데이터) 플래그를 반환해야 하며, dnssec-failed.org는 SERVFAIL을 반환해야 합니다.
운영 모범 사례:
- 서명 만료를 모니터링합니다: RRSIG는 일반적으로 30일간 지속됩니다. 만료되기 훨씬 전에 자동으로 사임하세요.
- 키 롤오버를 테스트합니다: 프로덕션 전에 스테이징 환경에서 롤오버 절차를 연습하세요.
- 알림을 구현합니다: 확인자에서 DNSSEC 유효성 검사 실패에 대한 모니터링을 구성합니다.
- 절차를 문서화하세요: 명확한 런북은 인시던트 또는 예정된 롤오버 시 당황을 방지합니다.
정확한 인터페이스는 등록 기관 및 공급업체마다 다르므로 특정 버튼 클릭을 외우기보다는 기본 작업을 이해하는 데 집중하세요. 신중한준비와 테스트를 통해 서비스 중단 없이 DNSSEC를 배포하는 것이 목표이며, 이를 달성할 수 있습니다.
DNSSEC 모범 사례
DNSSEC를 성공적으로 배포하려면 단순히 서명을 활성화하는 것 이상의 지속적인 주의와 업계 모범 사례 준수가 필요합니다. 도메인 소유자는 정기적인 키 교체를 우선시하여 키 손상 위험을 최소화하고 모든 개인 키를 하드웨어 보안 모듈 또는 기타 보호된 환경을 사용하여 안전하게 보관해야 합니다.
서명 만료일을 추적하고 만료되기 전에 레코드를 즉시 해지하는 등 DNSSEC 유효성 검사를 지속적으로 모니터링하는 것이 필수적입니다. 또한 DNS 인프라의 모든 구성 요소(권한 서버, 재귀 확인자, 등록 기관 인터페이스)가 DNSSEC 구현 및 유효성 검사를 완벽하게 지원하는지 확인하는 것도 중요합니다.
테스트는 또 다른 중요한 단계입니다. 도메인 소유자는 유효성 검사 성공 및 실패 시나리오를 모두 시뮬레이션하는 도구와 테스트 도메인을 사용하여 DNS 데이터가 올바르게 서명 및 유효성 검사되고 있는지 정기적으로 확인해야 합니다. 이러한 모범 사례를 따르면 도메인 소유자는 탄력적인 DNS 인프라를 유지하고, DNS 기반 공격으로부터 사용자를 보호하며, 도메인 네임 시스템의 지속적인 무결성과 신뢰성을 보장할 수 있습니다.
결론 및 다음 단계
DNSSEC는 도메인 이름 시스템을 모든 것을 신뢰하는 아키텍처에서 디지털 서명을 통한 암호화 검증과 계층적 신뢰 체인을 통해 1980년대 DNS가 설계된 이래 존재해 온 취약점을 해결하는 아키텍처로 전환합니다. 보호 메커니즘인 RSIG 서명, DNSKEY/DS 연결, NSEC/NSEC3를 통한 인증 거부는 사용자를 조용히 리디렉션할 수 있는 DNS 캐시 포이즈닝 및 DNS 스푸핑 공격을 방지합니다. 위조 DNS 데이터가 포함된 기존 DNS 레코드의 경우, 유효성 검사 확인자는 조작된 DNS 데이터를 완전히 거부하기만 하면 됩니다.
운영상의 복잡성에도 불구하고 DNSSEC는 2010년 루트 서명 이후 크게 발전했습니다. 광범위한 TLD 지원, CDS/CDNSKEY를 통한 자동화 개선, 확인자 유효성 검사 비율의 증가는 모두 모멘텀을 나타냅니다. 주요 보안 기관은 스푸핑으로 인해 심각한 피해가 발생할 수 있는 도메인에 대해 이 기술을 지지하고 있습니다.
DNS 인프라를 담당하는 담당자에게는 실용적인 다음 단계가 있습니다:
- 현재 서명된 도메인 및 영역 인벤토리
- 중요한 대민 서비스부터 단계적으로 DNSSEC 배포 계획 세우기
- 가능한 경우 내부 확인자에서 DNSSEC 유효성 검사를 사용하도록 설정합니다.
- DNSSEC 장애에 대한 모니터링 및 사고 대응 절차 수립
추가 학습 리소스에는 핵심 DNSSEC RFC(4033, 4034, 4035), ICANN 및 지역 네트워크 정보 센터의 배포 가이드, Verisign의 DNSSEC 분석기 같은 테스트 도구가 있습니다. 이해에서 실행에 이르는 과정이 그 어느 때보다 명확해졌으며 보안상의 이점이 투자를 정당화합니다.