DNSSEC란 무엇이며 어떻게 작동할까요?
DNSSEC(Domain Name System Security Extensions)는 IP(Internet Protocol) 네트워크를 통해 전송되는 데이터의 보안을 위해 DNS 레코드에 추가되는 암호화 서명입니다. DNSSEC는 DNS를 만든 설계자가 프로토콜 보안 조치를 포함하지 않았기 때문에 존재합니다. 이 때문에 공격자는 레코드를 위조하고 사용자를 사기성 웹사이트로 유도할 기회를 발견할 수 있었습니다. 따라서 DNS 응답에 신뢰성 및 무결성 레이어를 추가하기 위해 DNSSEC 프로토콜이 도입되었습니다.
DNSSEC는 기존 DNS 레코드에 암호화 서명을 추가해 보안 DNS를 설정하는 방식으로 작동합니다. 서명은 AAAA 및 MX와 같은 일반적인 레코드 종류와 함께 DNS 이름 서버에 저장됩니다. 그런 다음 요청된 DNS 레코드에 해당하는 서명을 확인해 해당 레코드가 권한 있는 이름 서버에서 직접 추출되었는지 확인할 수 있습니다. 즉, 디지털 전송 중에 기록이 중독되거나 변조되지 않아 가짜 레코드가 도입되는 것을 방지할 수 있습니다.
용이한 서명 유효성 검사
DNSSEC는 상황에 따라 다음 DNS 레코드 종류 중 하나를 추가해 서명 유효성 검사를 용이하게 합니다.
리소스 레코드 서명(RRSIG): 레코드 집합에 대한 암호화 DNSSEC 서명을 포함합니다
DNSKEY: 공개 서명 키를 포함합니다
DS: DNSKEY 레코드의 해시를 포함합니다
NSEC 및 NSEC3: 영역에 있는 다음 레코드 이름에 대한 링크를 제공하고 레코드 이름에 사용할 수 있는 레코드 종류도 나열합니다
CDNSKEY 및 CDS: 요청된 DS 상태를 하위 영역에서 상위 영역으로 전달하고 상위 영역의 DS 레코드에 업데이트를 요청합니다
도메인에서 DNSSEC를 활성화해야 하나요?
DNSSEC는 캐시 중독 및 대답 위조로부터 도메인을 보호합니다. 웹사이트 소유자의 아키텍처가 처음부터 끝까지 보호되는 오늘날의 디지털 환경에서는 DNS 공격이 성공하면 브랜드의 평판이 크게 훼손될 수 있기 때문에 DNS는 도메인에 꼭 필요한 요소입니다. DNS 레졸루션은 사용자가 웹사이트의 애플리케이션과 상호 작용하기 전에 발생합니다. 공격자가 DNS를 가로채면 웹사이트를 방문하려는 사용자가 의도된 사이트 대신 가짜 사이트(사용자를 속이기 위한 사이트)와 접속이 될 수 있습니다. 이 프로토콜의 공격적인 캐싱 아키텍처는 중독된 레코드를 신속하게 수정하기 어렵게 만듭니다.
따라서 웹사이트가 강력한 방화벽으로 보호되는 경우에도 사이트의 DNS 아키텍처가 DNSSEC로 충분히 보호되지 않으면 사용자의 데이터와 기술이 리스크에 노출됩니다.
DNS 레코드를 RRSet로 그룹화
DNSSEC를 도메인과 통합하려면 이름 및 레코드 종류별로 DNS 레코드를 RRSet(Resource Record Set)로 그룹화해야 합니다. DNS 자체는 DNS 영역으로 분할됩니다. 영역은 DNS 소유자의 전체 기업이나 네트워크 관리자가 감독하는 전체 DNS 네임스페이스의 일부입니다. 이 영역에서는 권한 있는 이름 서버 같은 DNS 구성요소를 심층적으로 유지 관리할 수 있습니다.
각 영역은 ZSK(Zone Signing Key)라는 퍼블릭 키와 프라이빗 키를 페어링해 서명됩니다. 결과 서명은 영역 파일 자체에 RRSIG 레코드로 게시됩니다. 예를 들어 호스트 이름 'www.dsnsecexample.com'에 A와 AAAA 레코드가 모두 포함된 경우 영역 파일은 각 IP 버전에 해당하는 RRSIG 레코드를 알립니다.
DNS 영역을 서로 격리함으로써 한 영역이 공격자에 의해 감염될 가능성을 차단해 인접 영역을 보호합니다.
리소스 레코드 서명
RRSIG 레코드에는 RRSet의 디지털 DNSSEC 서명이 들어 있습니다. 이러한 디지털 서명은 서명된 RRSet에 있는 모든 데이터를 인증하는 데 사용됩니다. 리졸버는 DNSKEY 레코드에 저장된 퍼블릭 키를 사용해 서명을 확인할 수 있습니다.
레코드 종류와 소유된 도메인 이름에 대한 이러한 RRSet은 서명된 DNS 영역 내에 저장됩니다. 도메인 이름 서버가 ZSK 쌍의 프라이빗 키를 사용해 지정된 영역 내의 RRSet에 서명하는 경우 RRSIG 레코드가 각 RRSet의 디지털 서명을 저장하는 데 사용됩니다. 따라서 서명된 영역에는 각 RRSet에 대한 RRSIG 레코드가 포함됩니다.
RRSIG 레코드는 다음 구성요소로 이루어집니다.
지원 종류: RRSIG가 지원하는 DNS 레코드 종류
알고리즘: 최종 서명을 생성하는 암호화 알고리즘
레이블 수: 원래 RRSIG 레코드 이름(와일드카드 확인에 사용됨)의 레이블 수
원본 TTL: 지원되는 레코드 집합의 TTL 값
서명 만료: 서명이 만료되는 시간
서명 개시: 서명이 처음 생성된 시간
키 태그: 이 RRSIG 서명을 확인하는 데 사용되는 DNSKEY 레코드를 식별하는 숫자 값
서명자 이름: 이 서명의 유효성을 검사하는 데 사용되는 DNSKEY 레코드의 이름
서명: 전송을 확인하는 데 사용되는 암호화 서명
ZSK(Zone Signing Key)
ZSK는 전송된 데이터를 인증하는 키입니다. ZSK는 KSK(Key Signing Key)와 동일한 RRSet의 한 부분이며 여기에 DNSKEY RRSet에 서명하는 프라이빗 키가 있습니다. 각 영역에는 ZSK 쌍이 있으며, DNSSEC 사용 영역은 퍼블릭 ZSK를 DNSKEY 레코드로 알려서 리졸버가 RRSIG 값을 인증할 수 있게 합니다.
DNSSEC 유효성 검사는 ZSK와 기타 DNSSEC 인증 키를 구분하지 않으므로 하나의 키를 KSK와 ZSK로 모두 사용할 수 있습니다. 영역 관리자만 프라이빗 ZSK에 접속할 수 있으므로 유효성 검사에 성공한 것은 DNS 레코드가 위조되거나 전송 중에 조작되지 않았음을 나타냅니다.
ZSK는 영역에 서명하는 데 사용되는 프라이빗 키에 해당하며, 일반적으로 이 RRSet에 서명하는 프라이빗 키에 해당하는 서명 퍼블릭 키와 동일한 RRSet의 일부입니다.
KSK(Key Signing Key)
KSK는 DNSKEY 레코드의 보안 포스처를 더욱 개선하기 위해 구현된 연산 비용이 높은 키 쌍입니다. 영역 관리자의 관리 부담을 덜어주기 위해 도입되었습니다. KSK는 프라이빗 키에 해당하며 지정된 영역의 다른 인증 키를 서명하는 데 사용됩니다. 일반적으로 KSK에 해당하는 프라이빗 키는 ZSK에 서명합니다. ZSK에는 DNS 영역 내에 있는 다른 데이터에 서명하기 위한 해당 프라이빗 키가 있습니다. 리졸버는 퍼블릭 KSK를 발표하는 관련 일반 텍스트 DNSKEY 레코드로 이 디지털 서명을 인증합니다.
KSK와 해당 DS(Delegation Signer) 레코드는 주기적으로 업데이트되며 ZSK는 더 자주 업데이트됩니다. 따라서 보안 및 운영 측면에서 이상적인 아키텍처는 자주 순환되는 ZSK에 보다 지속적인 별도의 KSK를 사용해 자체 서명하는 것입니다. 이렇게 구축하면 잠재적인 위협으로부터 DNS 영역을 보호하는 동시에 지속적인 DNSSEC 유지 관리 작업을 최소화하는 데 더 효과적입니다.
DS(Delegation Signer) 레코드
DNSSEC는 DS(Delegation Signer) 레코드를 수립해 퍼블릭 DNS 리졸버를 갖춘 "신뢰 체인" 모델을 만들었습니다. 이러한 시나리오에서 공격자는 이론적으로 DNS 응답을 스푸핑하고 영역의 무결성을 손상시키는 위조된 DNSKEY 레코드를 반환할 수 있습니다. DS 레코드는 상위 영역에 퍼블릭 KSK의 지문을 게시합니다.
유효성 검사 중 리졸버는 상위 영역의 DS 레코드가 하위 영역의 해당 DNSKEY 레코드와 일치하는지 확인해 하위 키 쌍의 합법성을 인증합니다. 이러한 신뢰 체인은 루트 영역까지 유지되며, 여기에는 대부분의 리커시브 리졸버에 내장된 신뢰 앵커가 포함됩니다.
NSEC 및 NSEC3
NSEC(Next Secure) 레코드는 지정된 영역 내에 이름이 있는지 여부를 확인하는 데 사용할 수 있습니다. '존재 거부' 인증 문제라고도 하는 영역에 레코드가 없는 경우의 문제를 해결하기 위해 도입되었습니다. 공격자는 이 취약점을 악용하고 웹사이트의 호스트 이름에 대한 NXDOMAIN 응답을 위조함으로써 사이트를 사용할 수 없게 만들 수 있습니다.
NXDOMAIN은 존재하지 않는 이름에 대한 쿼리를 수신할 때 존재하는 영역의 다음 정식 레코드를 나타내는 NSEC 레코드와 해당 이름에 나타나는 레코드 종류를 포함해 이 결함을 해결합니다.
예를 들어, 'example.com' 영역이 정렬되었고 'beta.example.com'이 첫 번째 레코드인 경우 'alpha.example.com'에 대한 쿼리는 NXDOMAIN과 'beta.example.com.' 가리키는 NSEC 레코드가 됩니다. NSEC 레코드는 다른 레코드와 마찬가지로 ZSK가 서명하며 해당 RRSIG를 가집니다. 따라서 NXDOMAIN 응답에는 인증된 RRSIG NSEC 레코드가 유효해야 합니다.
NSEC3는 영역의 모든 유효한 레코드를 나열하는 데 사용되는 NSEC 레코드의 문제를 해결하기 위해 개발되었습니다. NSEC3는 영역의 NSEC 이름이 일반 텍스트로 표시되는 대신 해시된다는 점을 제외하고 NSEC와 동일하게 동작합니다. 이렇게 하면 정보를 안전하게 보호하고 영역 보행을 방지할 수 있습니다.
DNSSEC 운영 모드
정적 영역의 오프라인 서명
DNSSEC 운영 모드에는 여러 가지가 있으며, 각 모드에는 DNS 영역의 데이터가 서명되는 방식에 대한 고유한 접근 방식이 있습니다. 이러한 모드 중 가장 일반적인 모드는 정적 영역의 오프라인 서명입니다. 이 모드를 사용하면 외부 위협으로부터 서명 시스템을 강력하게 보호할 수 있습니다. 이 운영 모델은 현재 네트워크에 연결되어 있지 않은 시스템에서 발견된 프라이빗 키를 보존하며 DNS 영역에서 발견된 정보가 자주 변경되지 않는 경우에 효과적입니다.
중앙 집중식 온라인 서명
중앙 집중식 온라인 서명은 DNSSEC 운영의 또 다른 반복 모드입니다. 관리자가 제한된 전용 접속 DNS에서 데이터에 서명하는 경우 중앙 집중식 온라인 서명을 통해 DNS 데이터를 신속하게 변경해 영역에 게시할 수 있습니다. 정적 영역의 오프라인 서명과 마찬가지로 중앙 집중식 온라인 서명에서는 단일 또는 복제된 중앙 서명자가 모든 데이터 서명을 수행합니다. 그런 다음 새로 서명된 데이터가 권한 있는 DNS 서버로 배포됩니다.
즉석 서명
즉석 데이터 서명은 권한 있는 DNS 서버가 필요에 따라 데이터에 서명할 수 있게 하는 DNSSEC 작업 모드입니다. 이 접근 방식의 문제점은 각각 인터넷에 직접 접속할 수 있는 다양한 시스템에 키가 존재하는 상황을 만들어 공격자가 네임스페이스에 대한 외부 접속용 경로를 더 많이 도입할 수 있다는 것입니다. 발신자가 비밀 키 값을 선택한 다음 수신자에게 안전하게 전송하는 키 배포는 즉석 서명을 통해 더욱 복잡해지고 각 노드의 컴퓨팅 요구사항이 불필요하게 증가할 수 있습니다.
DNSSEC 통합의 리스크
DNSSEC는 네트워크 보안을 향상시키는 매우 중요한 방법이지만 의도하지 않게 심각한 취약점이 발생할 수 있습니다. DNSSEC는 서버, 서비스 또는 네트워크가 동시에 여러 디바이스의 트래픽으로 인해 방해를 받는 DDoS 공격 리스크를 높이고 영향을 증폭시킬 수 있습니다. DNSSEC는 레코드를 제대로 확인하기 위해 추가 필드와 암호화 정보가 필요하기 때문에 DNS 쿼리 응답 수를 늘립니다. 즉, 공격자들은 대량의 응답을 통해 DNSSEC가 없는 경우보다 특정 영역에 대해 훨씬 더 많은 공격을 감행할 수 있습니다.
쓰리웨이 핸드셰이크 필요
TCP(Transmission Control Protocol)는 연결 지향 프로토콜이므로 속도가 느리고 쓰리웨이 핸드셰이크가 필요합니다. 따라서 DNS(및 DNSSEC)는 UDP(User Datagram Protocol)에 의존합니다. UDP는 연결 열기, 유지 관리 또는 종료에 대한 요구사항이 없고, 서명된 데이터를 대상에 전달할 수도 없는 빠르지만 더 위험한 프로토콜입니다. UDP는 체크섬 형태로 가장 기본적인 오류 검사 기능만 제공하며 핸드셰이크가 필요하지 않으므로 공격자가 전송된 데이터를 쉽게 가로챌 수 있습니다.
UDP 스푸핑은 공격자가 표적의 IP 주소를 UDP 소스 IP 주소로 나열하는 유효한 UDP 요청 패킷을 만드는 것입니다. 그런 다음 공격자는 스푸핑된 소스 IP를 일부 중간 서버로 보낼 수 있으며, 이 서버는 모든 UDP 응답 패킷을 보내 요청 패킷보다 훨씬 큰 응답을 생성합니다. 이러한 응답은 표적의 IP 주소로 전송되는 공격 트래픽 수준을 높이기에 충분합니다.
이러한 상황은 DNS 쿼리의 길이도 늘리므로 공격 심각도가 높아집니다. 이러한 공격이 증폭되는 범위는 요청 크기에 대한 응답 크기의 비율로 표현될 수 있습니다. 예를 들어, 공격자가 64바이트 요청을 DNS 서버에 보내면 3400바이트 이상의 악성 트래픽을 생성해 선택된 피해자에게 보낼 수 있습니다.
루트 서명 세리머니 이해
DNS 루트 서명 세리머니는 앞으로 몇 달 동안 루트 DNS 영역의 퍼블릭 키 정보를 서명하기 위해 수행되는 엄격한 절차입니다. 이 프로세스는 공모자 그룹이 루트 서명 키를 손상시킬 수 있는 절호의 기회를 보장합니다. 이는 루트 KSK를 보호하는 두 위치 중 하나에서 이루어집니다. 이 프로세스에 사용되는 프라이빗 서명 키는 DNSSEC 보안 인터넷을 잠금 해제하는 키입니다.
무상위 루트 DNS 영역 문제 해결
이 세리머니에서는 일부 상위 영역에서 무결성을 감독할 수 없는 영역을 의미하는 무상위 루트 DNS 영역 문제를 해결합니다. 세리머니 관리자, 내부 증인, 인증정보 금고 관리자, 하드웨어 금고 관리자, 3명의 암호 담당자를 포함한 소수의 참가자가 필요합니다. 각 구성원은 인터넷 커뮤니티에서 자원한 암호 담당자를 제외하면 ICANN(Internet Corporation for Assigned Names and Numbers) 직원입니다.
인증정보 금고 접속
두 가지 금고, 즉 인증정보 금고와 하드웨어 금고가 있습니다. 루트 키에 접속하려면 둘 다 접속해야 합니다. 인증정보 금고 관리자는 인증정보 금고를 엽니다. 여기에는 안전한 보관 상자가 있습니다. 각각에는 세리머니 관리자와 암호 담당자가 보유한 두 개의 키가 필요합니다. 이 보관 상자에는 하드웨어 금고에 있는 하드웨어 보안 모듈을 여는 데 필요한 운영자 카드와 보안 권한 카드가 있습니다. 카드는 인증정보 금고에 보관되는 훼손 방지 가방에 싸여 플라스틱 케이스 안에 보관됩니다.
하드웨어 금고 열기
그런 다음 하드웨어 금고 관리자가 금고실로 들어와 하드웨어 보안 모듈이 포함된 하드웨어 금고를 엽니다. 하드웨어 금고에는 배터리나 하드 디스크가 없는 노트북도 포함되어 있으며, 보안 모듈에 명령을 보낼 수 있도록 지정되어 있습니다. 이것은 세리머니 중 루트 DNS 키를 서명하는 데 사용되는 것입니다. 모든 측면은 꼼꼼하게 기록되고 다음 세대를 위해 인터넷에 라이브 스트리밍됩니다.
암호 담당자의 참여
세리머니가 시작되면 암호 담당자는 세리머니 관리자에게 작업자 카드를 넘겨야 합니다. 세리머니 관리자는 DVD로 노트북을 부팅하고 세리머니 로그를 기록하는 USB를 초기화합니다. 관리자는 세 개의 운영자 카드를 사용해 보안 모듈을 활성화한 다음 이더넷 케이블을 통해 노트북에 연결합니다. 키 서명 요청이 노트북에 로드되고 키 서명 요청의 PGP 해시가 계산된 다음 제공된 해시와 동일한지 확인합니다. 이 때 세리머니 관리자는 프라이빗 KSK로 키 서명 요청에 서명하고 디지털 서명 컬렉션, 즉 RRSIG 레코드를 만듭니다.
도메인 보안을 강화하기 위해 지금 DNSSEC 구현하기
도메인에 대한 DNS 공격이 성공하면 디지털 생태계의 무결성과 브랜드 전체의 평판에 영구적으로 영향을 미칠 수 있습니다. DNSSEC 암호화 서명은 DNS 확인 프로세스를 강화해 캐시 손상과 응답 위조 등의 사이버 위협으로부터 도메인을 보호합니다. 결과적으로, 기업 및 사용자의 데이터 및 기술에 대한 엔드투엔드 보안이 구현됩니다.
Akamai의 다양한 DNS 솔루션 알아보기
Akamai는 도메인 소유자의 우수한 DNS 서비스를 다양하게 지원하기 위해 플랫폼을 지속적으로 확장하고 있습니다.
도메인 안정성과 복원력을 달성하기 위한 Edge DNS 서비스
데이터센터, 클라우드 배포, CDN의 부하를 분산할 수 있는 Global Traffic Management
애플리케이션을 대규모 확장할 수 있는 Application Load Balancing(ALB) Cloudlet
네트워크의 모든 디바이스가 DNS 보안 툴을 확인하게 하고 DNS 리졸버를 보안 툴로 만드는 Secure Internet Access Enterprise
다양한 DNS 자료를 활용하려면 Akamai 커뮤니티에 참여하세요
DevOps 전문가이신가요? Akamai 개발자 커뮤니티를 확인하세요
추가 도움이 필요하신가요? 지금 문의하세요.
2021년 3월 19일 최초 발행, 2022년 6월 업데이트.