DNSSEC 복잡성 및 고려 사항

DNS는 영역이라 부르는 더 작은 부분으로 나뉩니다. 영역은 일반적으로 도메인 이름에서 시작하며 하위 도메인에 있는 모든 레코드를 포함하고 있습니다. 관리자 하나가 각 영역을 관리합니다. 예를 들어, cloudflare.com은 cloudflare.com 및 하위 도메인(예: www.cloudflare.com, api.cloudflare.com)의 모든 DNS 레코드를 포함하는 영역입니다.

DNS에는 하위 도메인에 대한 디렉토리 서비스가 없으므로 api.cloudflare.com이 있는지 확인하려면 DNS 서버에 요청해야 하고, DNS 서버에서는 api.cloudflare.com의 존재 여부를 cloudflare.com에 확인합니다. DNSSEC에서는 그렇지 않습니다. 경우에 따라, DNSSEC를 활성화하면 가려진 영역 콘텐츠가 노출되기도 합니다. 모두가 하위 도메인에서 보안을 유지하는 데 신경을 쓰지는 않으며, 대부분의 사이트에는 'www' 하위 도메인이 있으니 영역 콘텐츠는 원래 추측하기가 쉽습니다. 하지만, 사이트 소유자가 비공개로 유지하려는 로그인 포털이나 기타 서비스로 하위 도메인을 사용하는 경우도 있습니다. 사이트 소유자는 공격자로부터 사이트를 보호하기 위해 마련한 "secretbackdoor.example.com"을 공개하고 싶어하지 않을 수도 있습니다.

DNSSEC가 하위 도메인을 노출할 수도 있게 되는 원인은 영역을 서명하는 방식과 관련이 있습니다. 역사적으로, DNSSEC는 정적 영역 서명에 사용되고 있습니다. 정적 영역은 주어진 도메인에 대한 완전한 레코드 세트입니다. DNSSEC 서명 레코드는 키 서명 키(KSK) 및 영역 서명 키(ZSK)를 사용하여 중앙 위치에 생성되고, 게시하려는 권한 있는 서버로 전송됩니다. 이 레코드 집합을 통해, 권한 있는 서버는 존재하지 않는 하위 도메인에 대한 질문 등 요청된 모든 질문에 응답할 수 있습니다.

표준 DNS의 경우 하위 도메인이 없다면 서명되지 않은 NXDOMAIN(Non-Existent Domain) 응답이 서버에서 반환되지만, DNSSEC는 이와 달리 모든 응답이 서명되도록 합니다. 이러한 작업은 존재하지 않음을 입증해주는 특별 레코드인 NSEC(NextSECure) 레코드로 수행됩니다. NSEC 레코드를 사용하여 "하위 도메인 X와 하위 도메인 Y 사이에 하위 도메인이 없다"는 점을 나타낼 수 있습니다. NSEC는 영역 내 모든 도메인 사이의 간격을 메워 모든 쿼리에 정적 레코드로 응답할 방법을 제공해줍니다. NSEC 레코드는 각 이름에 존재하는 리소스 레코드 유형을 나열하기도 합니다.

정적으로 서명된 영역의 경우 정의에 따라 수가 고정된 레코드가 있습니다. 각각의 NSEC 레코드가 다음 레코드를 가리키므로, 결국 모든 하위 도메인을 포함한 NSEC 레코드로 이루어진 유한한 '고리'가 만들어집니다. 누구든지, NSEC 레코드 하나를 따라서 하위 도메인을 모두 확인할 때까지 영역을 '살펴볼' 수 있습니다. 이러한 방법으로 영역의 이름을 모두 나타낼 수 있으며, 내부 정보가 노출될 가능성이 생기는 것입니다.

example.com이라는 DNSSEC 사용 영역이 있는데, 이 영역이 public.example.com과 secret.example.com을 하위 도메인으로 두었다고 가정합시다. NSEC 레코드를 추가하면 하위 도메인의 존재 여부가 모두 드러납니다.

example.com의 NSEC 레코드를 요청하면 다음 내용이 제공됩니다.

example.com. NSEC public.example.com. A NS SOA TXT AAAA RRSIG NSEC DNSKEY

public.example.com을 요청하면 다음과 같은 NSEC 레코드가 제공됩니다.

public.example.com. NSEC secret.example.com. A TXT AAAA RRSIG NSEC

secret.example.com을 요청하면 다음과 같은 NSEC 레코드가 제공됩니다.

secret.example.com. NSEC example.com. A TXT AAAA RRSIG NSEC 

첫 번째는 상위/에이펙스 도메인에 해당하며, "example.com" 이름이 존재하고 다음 이름은 "public.example.com"이라는 점을 알려줍니다. public.example.com 레코드는 "secret.example.com"을 다음 이름이라고 밝히면서 비공개 하위 도메인의 존재를 드러냅니다. "secret.example.com"은 다음 레코드 "example.com"을 보여주며 하위 도메인으로 이루어진 체인을 마무리 짓습니다. 그러니 몇 번의 쿼리만으로 모두가 영역 내 전체 레코드 집합을 알 수 있는 것입니다.

기술적으로 DNS 레코드는 비밀이 아닌 것으로 여겨지지만, 실제로는 비밀처럼 취급될 때도 있습니다. 한동안 하위 도메인은 기업 로그인 페이지 등 비공개로 두는 데 사용되었으니, 영역 파일 콘텐츠가 갑자기 드러나는 상황은 예상치 못한 상황이고, 반길 만한 일이 아닙니다.

DNSSEC 이전에 영역 내 이름 컨텐츠를 찾아볼 유일한 방법은 이러한 이름을 쿼리하거나, 권한 있는 서버 한 곳에서 영역 전송을 시도해보는 것이었습니다. 영역 전송(AXFR)은 자주 차단됩니다. 영역 열거 문제를 해결하기 위해 NSEC의 대안인 NSEC3를 도입했지만, NSEC3라 해도 하위 도메인의 존재를 드러내는 데 사용할 수 있습니다.

.ch에 해당하는 도메인 대부분은 NSEC3를 사용합니다

NSEC3 레코드는 NSEC 레코드와 비슷하지만, 질문에 대한 응답이 없는 도메인 이름의 서명된 간격이 아니라 도메인 이름 해시의 서명된 간격을 제공해줍니다. 이는 영역 열거를 방지하려는 목적입니다. 따라서 "example.com" 및 "www.example.com" 이 있는 영역의 NSEC3 체인은 다음과 같을 수 있습니다(확실히 보이도록 각 NSEC3 레코드는 3번째 줄에 있음).

231SPNAMH63428R68U7BV359PFPJI2FC.example.com. NSEC3 1 0 3 ABCDEF
NKDO8UKT2STOL6EJRD1EKVD1BQ2688DM
A NS SOA TXT AAAA RRSIG DNSKEY NSEC3PARAM

NKDO8UKT2STOL6EJRD1EKVD1BQ2688DM.example.com. NSEC3 1 0 3 ABCDEF
231SPNAMH63428R68U7BV359PFPJI2FC
A TXT AAAA RRSIG

여기서

231SPNAMH63428R68U7BV359PFPJI2FC

example.com

NKDO8UKT2STOL6EJRD1EKVD1BQ2688DM

www.example.com

NSEC3 레코드의 첫 번째 줄에는 해시가 적용된 다음의 영역 "이름"이 나타나며, 해시 적용 시 사용된 해시 라운드 및 솔트 수는 첫 번째 줄 "3 ABCDEF"의 마지막 두 매개변수입니다. "1 0"은 다이제스트 알고리즘(1은 SHA-1을 의미함) 및 영역이 옵트아웃을 사용하는 경우(0은 아님을 의미함)를 나타냅니다. 두 번째 줄은 "영역의 다음 해시된 이름"이고 세 번째 줄은 이름의 유형을 나열합니다. 첫 번째 NSEC3 레코드의 "다음 이름"이 두 번째 NSEC3 레코드의 이름과 같고, 해당 레코드의 "다음 이름"으로 체인이 마무리되고 있음을 확인할 수 있습니다.

NSEC 열거의 경우, 도메인에서 가능한 이름을 추측하는 것으로 시작해 전체 도메인 목록을 만들어낼 수 있습니다. 영역에 도메인 이름이 100개 가량 있는 경우 전체 영역을 열거하려면 100번 가량 요청해야 합니다. NSEC3 사용 시, 존재하지 않는 레코드를 요청할 경우에는 해시에 따라 알파벳순으로 정렬된 다음 영역과 함께 서명된 NSEC3 레코드가 반환됩니다. 다음 쿼리 이름 후보와 알려진 간격 중 하나가 일치하는지 확인하는 방법으로, 누구든지 100개 가량의 쿼리에서 전체 체인을 알아낼 수 있습니다. nmap에 대한 플러그인 등, 이러한 계산을 수행할 수 있는 도구가 많습니다.

영역 내 유효한 모든 이름에 해당하는 해시를 통해, 실제 이름을 알아내는 데 사전 공격을 이용할 수 있습니다. 짧은 이름은 쉽게 추측할 수 있으며 사전을 사용하면 권위 있는 이름 서버에서 계속 추측하지 않고도 긴 이름의 존재를 밝혀낼 수 있습니다. HashCat과 같은 도구를 사용하면 소프트웨어에서 이 작업을 쉽게 수행할 수 있으며 비트코인이 인기를 끌면서 해싱 관련 하드웨어의 가격은 크게 낮아졌습니다. 암호화 해시를 계산하기 위해 구축된 장치를 다루는 소규모 산업이 급성장하고 있습니다. 이러한 규격품 장치의 한 예시로, Tesla 암호 크래커(아래)가 있습니다.

Tesla 크래커

해싱은 저렴하므로, 설계된 대로 NSEC3를 사용하면 영역 개인 정보 보호가 약간만 개선됩니다. 이름을 추측하기 어려운 정도와 비례한 만큼만 보호 수준이 주어지는 것입니다.

간단히 말해서, NSEC는 일반 텍스트 암호를 공개하는 것과 같고 NSEC3은 Unix 스타일 암호 파일을 공개하는 것과 같습니다. 두 기술 모두 그다지 안전하지 않습니다. NSEC3를 사용하면 하위 도메인은 추측하기 어려운 만큼만 비공개 상태로 남을 수 있습니다.

이 취약점은 RFC 4470 및 4471(https://tools.ietf.org/html/rfc4470 및 https://tools.ietf.org/html/rfc4471)에서 소개한 "DNSSEC 선의의 거짓"이라는 기술로 완화할 수 있습니다. Dan Kaminsky가 시연 목적으로 구현한 기술입니다. 존재하지 않는 도메인에 대한 요청이 들어올 경우, 그 다음 순서인 실제 도메인의 NSEC3 레코드가 제공되는 대신 알파벳순으로 다음 해시의 NSEC3 레코드가 제공됩니다. 이 방식은 NSEC3 응답과 질문 사이에 사전적으로 해시가 맞는 도메인이 없다는 NSEC3 보장을 위반하지 않습니다.

질문에 응하여 실시간으로 서명을 계산할 수 있는 경우에만 NSEC3 또는 NSEC "선의의 거짓"을 구현할 수 있습니다. 전통적으로, DNS 확인을 위한 정적 영역 레코드는 오프라인으로 생성되며 서명이 있는 모든 레코드는 영역 파일에 저장됩니다. 그런 다음 라이브 DNS 서버가 이 파일을 읽고 영역에 대한 질문에 응답할 수 있습니다.

Cloudflare의 DNSSEC 구현은 ECDSA의 효율적인 서명 생성을 활용하여 즉각적으로 DNSSEC 레코드에 서명합니다.

DNSSEC는 다양한 모드에서 작동하도록 설계되었으며, 각각 보안, 성능, 편의성을 조정하여 제공합니다. 라이브 서명은 키 관리 보안이 약한 대신 영역 콘텐츠 노출 문제를 해결합니다.

가장 일반적인 DNSSEC 모드는 정적 영역의 오프라인 서명입니다. 이 방식은 네트워크에 연결되지 않은 시스템에 개인 키를 보관함으로써, 외부 위협으로부터 서명 시스템을 극도로 안전하게 보호할 수 있습니다. 이 운영 모델은 DNS 정보가 자주 변경되지 않을 때 효과가 좋습니다.

일반적으로 사용하는 또 하나의 운영 모드는 중앙 집중식 온라인 서명입니다. 액세스가 제한된 전용 DNS 서명 시스템에서 데이터에 서명하면 DNS 데이터를 빠르게 바꾸어 게시할 수 있습니다. 일부 운영자는 주요 DNS 서버에서 DNS 서명을 실행합니다. 정적 영역의 오프라인 서명과 마찬가지로 이 모드는 중앙 서명 모델을 따릅니다. 즉, 단일한(또는 복제된) 중앙 서명자가 모든 서명을 수행하고, 실제 권한 있는 DNS 서버로 이 데이터를 전파하는 것입니다.

보다 급진적인 모드에서는 실제 권한 있는 DNS 서버가 필요할 때 즉석에서 데이터에 서명할 수 있도록 해줍니다. 이렇게 하면 응답이 생성된 위치에서 서명되는 지리적 종속 정보 등, 여러 가지 새로운 기능을 이용할 수 있습니다. 여기에서의 단점은 인터넷에 직접 액세스할 수 있는 여러 컴퓨터에 키 자료가 있다는 점입니다. 에지에서 라이브 서명을 수행하면 키 배포와 같은 새로운 문제가 발생하고 노드에 추가 컴퓨팅 요건이 생깁니다.

최근에 Heartbleed로 알려진 버그가 발견되어 서버 애플리케이션에 심각한 보안 허점이 생겼습니다. 이 버그는 원격 메모리 공개 취약점을 만든 OpenSSL의 코딩 오류로 인해 발생했습니다. 원격 공격자는 이 버그를 이용해 인터넷 연결 서버에서 암호화 키를 알아낼 수 있습니다. 원격 메모리 노출 버그는 DNSSEC 라이브 서명과 같은 활성 프로세스에서 키를 사용할 때 개인 키 보안에 영향을 미치는 여러 위협 중 하나일 뿐입니다. 인터넷에 컴퓨터가 더 많이 노출될수록, 공격 벡터도 더 많아집니다. 오프라인 서명 시스템은 이와 같은 위협에 노출될 가능성이 훨씬 적습니다.

키를 안전하게 유지하는 한 가지 방법은 HSM(하드웨어 보안 모듈)과 같은 하드웨어 지원 솔루션을 사용하는 것입니다. 이 솔루션의 큰 단점은 비용입니다. HSM은 아주 비쌉니다(느리기도 합니다). 이 점은 고객의 가까이에 위치하기 위해 지리적으로 분산된 DNS 서버를 운영할 때 겪게 되는 까다로운 부분 중 하나입니다. 모든 서버 위치에서 HSM을 실행하려면 비용도 많이 들지만 법적 문제도 발생할 수 있습니다.

원격으로 공개되지 않게 키를 보호할 또 다른 해결 방법은 암호화 작업을 시스템의 신뢰할 수 있는 구성 요소로 오프로드하는 것입니다. 암호화를 오프로드할 수 있는 사용자 지정 DNS 서버가 있는 경우 유용할 수 있습니다.

DNSSEC의 키 관리는 TLS의 키 관리와 유사하며 어려움도 비슷합니다. Cloudflare는 올해 초 TLS의 키 보안을 개선하기 위해 Keyless SSL을 도입했습니다. DNSSEC 라이브 서명 시에도 원격 키 서버의 이점을 이용할 수 있도록 Keyless SSL을 확장하려고 합니다.

권한 있는 DNS 서버를 운영하는 운영자는 이 서버가 악의적인 DDoS(분산 서비스 거부) 공격의 통로로 사용까 봐 걱정하곤 합니다. 이는 DNS가 상태 비저장 프로토콜인 UDP를 사용한다는 점에서 비롯됩니다.

TCP에서는 3방향 핸드셰이크로 각각의 연결이 시작됩니다. 이렇게 하면 연결을 시작하기 전에 양 당사자의 IP 주소가 알려져 정확하게 확인됩니다. UDP에는 이러한 핸드셰이크가 없습니다. 메시지는 확인되지 않은 '보낸 사람' IP 주소를 통해 IP로 직접 전송되기만 합니다. 공격자가 서버에 '안녕하세요, 보낸 사람 IP X'라는 내용의 UDP 패킷을 만들 수 있다면, 일반적으로 서버는 UDP 패킷을 X로 전송해 응답합니다. 보낸 사람의 IP 주소 대신 피해자의 IP 주소로 X를 선택하는 방식을 UDP '스푸핑'이라고 부릅니다. 공격자는 피해자를 스푸핑하여, UDP 요청에 응답하는 서버가 피해자에게 '반사된' 트래픽을 쏟아내도록 만들 수 있습니다. 권한 있는 서버에도 마찬가지로 개방 재귀 확인자에 대해 이 방식을 적용할 수 있습니다.

DNSSEC는 UDP에서도 작동하며 여러 DNSKEY 및 RRSIG 레코드를 포함하면서 DNS 쿼리에 대한 응답이 아주 길어질 수 있습니다. 공격자가 반사 공격을 '증폭'시킬 수 있기 때문에, 이 부분은 공격자에게 매력적인 목표 대상입니다. 소량의 UDP DNSSEC 요청을 스푸핑하여 이름 서버로 전송하면 피해자는 반사 트래픽을 대량으로 받게 됩니다. 이러한 트래픽은 피해자 서버를 마비시켜 서비스 거부를 초래하기에 충분할 때도 있습니다.

루트 서버에 존재하지 않는 TLD를 요청하면 100바이트 가량의 응답이 반환되며, 동일한 질문에 답하는 서명된 응답은 650바이트 가량, 또는 증폭 계수 6.5에 해당합니다. 루트는 1,024비트 RSA 키를 사용하여 서명되며 부정 응답에는 NSEC를 사용합니다. 1,024비트 키로 서명된 NSEC3을 사용하여 TLD에 존재하지 않는 도메인을 요청하면 증폭 계수가 10가량 생겨납니다. 증폭 계수를 더 높게 만들 수 있는 또 다른 쿼리가 있는데, 가장 효과적인 쿼리는 "ANY"입니다.

DNS도 여러 서비스처럼 TCP에서 작동할 수 있습니다. TCP가 요구됨을 나타내기 위해 확인자로 다시 전송할 수 있는 '잘라내기(truncation)' 플래그가 있습니다. 이렇게 하면 DNS 요청은 느려지지만 DNS 반사 문제를 해결할 수 있습니다. 16%의 확인자에서 TCP 잘라내기 플래그가 적용되지 않고 4%의 확인자가 두 번째 서버에 요청을 시도하지 않기 때문에, 현재로서는 실용적인 방법이 아닙니다.

응답 크기를 줄일 또 다른 방법은 기존의 RSA 키 대신 ECDSA(Elliptic Curve Digital Signature Algorithm) 키를 사용하는 것입니다. ECDSA 키는 같은 강도의 RSA 키보다 훨씬 짧으며, 더 짧은 서명을 생성하여 DNSSEC 응답을 훨씬 더 짧게 만들어 증폭 계수를 줄여줍니다. Google Public DNS는 2014년 말에 ECDSA에 대한 지원을 추가했으며, 그 이후로 다른 여러 서비스에서도 이를 따라 지원을 추가했습니다.

TCP 및 ECDSA에 대한 지원은 아직도 일반적인 DNSSEC 지원보다 뒤쳐져 있으므로, 그 대신 기존에 사용하던 남용 방지 방법을 이용할 수 있습니다. 그러한 방법으로는 RRL(Resource Rate Limiting) 및 기타 휴리스틱이 있습니다.

Cloudflare는 반사 공격으로부터 보호를 제공하기 위해 다각적인 접근 방식을 사용하고 있습니다. 첫째, 현재 DNS 서버에서 사용하고 있는 공격 식별 휴리스틱 및 남용 방지 기술을 이용합니다. 둘째, DNSSEC 응답의 증폭 계수를 줄입니다. 최대 증폭 계수를 줄이는 데는 TCP를 통해 "ANY" 요청에만 응답하고, 가능한 경우 더 짧은 ECDSA 키를 사용하고, 키 롤오버 빈도를 줄여볼 수 있습니다.

Cloudflare는 영역 개인정보 보호, 키 관리, 반사/증폭 위험과 관련하여 DNSSEC로 인해 생겨난 복잡성을 알고 있습니다. 엔지니어링 결정을 현명하게 내리고 운영 제어를 마련해 DNSSEC의 위험을 방지할 수 있습니다.