DNSSEC 복잡성 및 고려 사항

DNS is split into smaller pieces called zones. A zone typically starts at a domain name, and contains all records pertaining to the subdomains. Each zone is managed by a single manager. For example, cloudflare.com is a zone containing all DNS records for cloudflare.com and its subdomains (e.g. www.cloudflare.com, api.cloudflare.com).

There is no directory service for subdomains in DNS so if you want to know if api.cloudflare.com exists, you have to ask a DNS server and that DNS server will end up asking cloudflare.com whether api.cloudflare.com exists. This is not true with DNSSEC. In some cases, enabling DNSSEC may expose otherwise obscured zone content. Not everyone cares about the secrecy of subdomains, and zone content may already be easily guessable because most sites have a ‘www’ subdomain; however, subdomains are sometimes used as login portals or other services that the site owner wants to keep private. A site owner may not want to reveal that “secretbackdoor.example.com” exists in order to protect that site from attackers.

The reason DNSSEC can expose subdomains has to do with how zones are signed. Historically, DNSSEC is used to sign static zones. A static zone is a complete set of records for a given domain. The DNSSEC signature records are created using the Key Signing Key (KSK) and Zone Signing Key (ZSK) in a central location and sent to the authoritative server to be published. This set of records allows an authoritative server to answer any question it is asked, including questions about subdomains that don’t exist.

Unlike standard DNS, where the server returns an unsigned NXDOMAIN (Non-Existent Domain) response when a subdomain does not exist, DNSSEC guarantees that every answer is signed. This is done with a special record that serves as a proof of non-existence called the NextSECure (NSEC) record. An NSEC record can be used to say: “there are no subdomains between subdomains X and subdomain Y.” By filling the gap between every domain in the zone, NSEC provides a way to answer any query with a static record. The NSEC record also lists what Resource Record types exist at each name.

For statically signed zones, there are, by definition, a fixed number of records. Since each NSEC record points to the next, this results in a finite ‘ring’ of NSEC records that covers all the subdomains. Anyone can ‘walk’ a zone by following one NSEC record to the next until they know all subdomains. This method can be used to reveal all of the names in that zone---possibly exposing internal information.

Suppose there is a DNSSEC-enabled zone called example.com, with subdomains public.example.com and secret.example.com. Adding NSEC records will reveal the existence of all subdomains.

Asking for the NSEC record of example.com gives the following:

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

Asking for public.example.com gives the following NSEC record:

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

Asking for secret.example.com gives the following NSEC record:

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

The first one is for the zone top/apex, and says that the name “example.com” exists and the next name is “public.example.com”. The public.example.com record says that the next name is “secret.example.com” revealing the existence of a private subdomain. The “secret.example.com” says the next record is “example.com” completing the chain of subdomains. Therefore, with a few queries anybody can know the complete set of records in the zone.

Technically, DNS records are not supposed to be secret, but in practice they are sometimes considered so. Subdomains have been used to keep things (such as a corporate login page) private for a while, and suddenly revealing the contents of the zone file may be unexpected and unappreciated.

Before DNSSEC the only way to discover the contents of names in a zone was to either query for them, or attempt to perform a transfer of the zone from one of the authoritative servers. Zone Transfers (AXFR) are frequently blocked. NSEC’s alternatative, NSEC3, was introduced to fight zone enumeration concerns, but even NSEC3 can be used to reveal the existence of subdomains.

Most domains under .ch use NSEC3

The NSEC3 record is like an NSEC record, but, rather than a signed gap of domain names for which there are no answers to the question, NSEC3 provides a signed gap of hashes of domain names. This was intended to prevent zone enumeration. Thus, the NSEC3 chain for a zone containing “example.com” and “www.example.com” could be (each NSEC3 record is on 3 lines for clarity):

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

Where

231SPNAMH63428R68U7BV359PFPJI2FC

example.com

NKDO8UKT2STOL6EJRD1EKVD1BQ2688DM

www.example.com

The first line of the NSEC3 record contains the “name” of the zone after it has been hashed, the number of hash rounds and salt used in the hashing are the two last parameters on the first line “3 ABCDEF”. The “1 0” stands for digest algorithm (1 means SHA-1) and if the zone uses Opt-out (0 means no). The second line is the “next hashed name in the zone”, the third line lists the types at the name. You can see the “next name” at the first NSEC3 record matches the name on the second NSEC3 record and the “next name” on that one completes the chain.

For NSEC enumeration, you can create the full list of domains by starting to guess at possible names in the domain. If the zone has around 100 domain names, it will take around 100 requests to enumerate the entire zone. With NSEC3, when you request a record that does not exist, a signed NSEC3 record is returned with the next zone present ordered alphabetically by hash. Checking if the next query name candidate fits in one of the known gaps allows anyone to discover the full chain in around 100 queries. There are many tools that can do this computation for you, including a plug-in to nmap

With the hashes that correspond to all the valid names in the zone, a dictionary attack can be used to figure out the real names. Short names are easily guessed, and by using a dictionary, longer names can be revealed as existing without having to flood the authoritative nameservers with guesses. Tools like HashCat make this easy to do in software, and the popularity of bitcoin has dramatically lowered the price of hashing-specific hardware. There is a burgeoning cottage industry of devices built to compute cryptographic hashes. The Tesla Password cracker (below) is just one example of these off-the shelf devices.

The Teslsa Cracker

Because hashing is cheap, zone privacy is only slightly improved when using NSEC3 as designed; the amount of protection a name gets is proportional to its unguessability.

In short, NSEC is like revealing plaintext passwords, and NSEC3 is like revealing a Unix-style passwords file. Neither technique is very secure. With NSEC3 a subdomain is only as private as it is hard to guess.

This vulnerability can be mitigated by a techniques introduced in RFCs 4470 and 4471 (https://tools.ietf.org/html/rfc4470 and https://tools.ietf.org/html/rfc4471) called “DNSSEC white lies”; this was implemented by Dan Kaminsky for demonstration purposes. When a request comes in for a domain that is not present, instead of providing an NSEC3 record of the next real domain, an NSEC3 record of the next hash alphabetically is presented. This does not break the NSEC3 guarantee that there are no domains whose hash fits lexicographically between the NSEC3 response and the question.

You can only implement NSEC3 or NSEC “white lies” if signatures can be computed in real-time in response to questions. Traditionally, static zone records for DNS resolution are created offline, and all the records with signatures stored in a zone file. This file is then read by a live DNS server allowing it to answer questions about the zone.

Cloudflare’s DNSSEC implementation leverages ECDSA’s efficient signature generation to sign DNSSEC records on-the-fly.

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의 위험을 방지할 수 있습니다.