Complexidades e Considerações sobre o 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.

O DNSSEC foi projetado para operar em vários modos, cada um oferecendo diferentes compensações de segurança, desempenho e conveniência. A assinatura ao vivo resolve o problema de exposição do conteúdo da zona em troca de um gerenciamento de chaves menos seguro.

O modo DNSSEC mais comum é a assinatura off-line de zonas estáticas. Isso permite que o sistema de assinatura seja altamente protegido contra ameaças externas, mantendo as chaves privadas em uma máquina que não esteja conectada à rede. Esse modelo operacional funciona bem quando as informações de DNS não mudam com frequência.

Outro modo de operação comum é a assinatura on-line centralizada. Se você assinar dados em acesso restrito, sistemas de assinatura de DNS dedicados, isso permitirá que os dados de DNS sejam alterados e publicados rapidamente. Alguns operadores executam a assinatura de DNS em seus principais servidores DNS. Assim como a assinatura off-line de zonas estáticas, esse modo segue o modelo de assinatura central, ou seja, um assinante central único (ou replicado) faz toda a assinatura e os dados são propagados a partir dele para os servidores DNS autoritativos reais.

Um modo mais radical é permitir que os servidores DNS autoritativos reais assinem dados em tempo real quando necessário, isso permite uma série de novos recursos, incluindo informações geograficamente dependentes assinadas onde a resposta é gerada. A desvantagem é que agora o material de digitação está em muitas máquinas diferentes que têm acesso direto à internet. A assinatura ao vivo na borda apresenta novos problemas, como distribuição de chaves e impõe requisitos extras de computação nos nós.

Recentemente, foi encontrado um bug conhecido como Heartbleed que abriu uma grande falha de segurança em aplicativos de servidor. Foi causado por um erro de codificação no OpenSSL que criou uma vulnerabilidade de divulgação de memória remota. Esse bug permitiu que invasores remotos extraíssem chaves criptográficas de servidores voltados para a internet. O bug de exposição de memória remota é apenas uma das muitas ameaças à segurança de chave privada quando a chave está sendo usada em um processo ativo, como assinatura dinâmica de DNSSEC. Quanto mais uma máquina é exposta à internet, mais vetores de ataque existem. As máquinas de assinatura off-line têm uma janela muito menor de exposição a essas ameaças.

Uma maneira de manter as chaves seguras é usar uma solução com suporte de hardware, como um Módulo de Segurança de Hardware (HSM). A principal desvantagem disso é o custo – os HSMs são muito caros (e lentos). Este é um dos pontos mais difíceis para a execução de servidores DNS que estão espalhados geograficamente para estarem próximos de seus clientes. A execução de um HSM em cada local de servidor pode não apenas ser cara, mas também pode haver complicações legais.

Outra solução para proteger as chaves da divulgação remota é descarregar as operações criptográficas em um componente confiável do sistema. É aqui que pode ser útil ter um servidor DNS personalizado que possa descarregar a criptografia.

O gerenciamento de chaves para DNSSEC é semelhante ao gerenciamento de chaves para TLS e apresenta desafios semelhantes. No início deste ano, introduzimos o Keyless SSL para ajudar a melhorar a segurança de chaves para TLS. Estamos procurando estender o Keyless SSL para fornecer as vantagens de servidores de chave remotos para assinatura ao vivo de DNSSEC.

Os operadores que executam um servidor DNS autoritativo geralmente ficam nervosos com o fato de que seu servidor será usado como um canal para ataques de negação de serviço distribuída (DDoS) maliciosos. Isso decorre do fato de que o DNS usa UDP, um protocolo sem estado.

No TCP, cada conexão começa com um handshake de três vias. Isso garante que o endereço de IP de ambas as partes seja conhecido e correto antes de iniciar uma conexão. No UDP, não existe esse handshake: as mensagens são apenas enviadas diretamente para um IP com um endereço de IP "de" não verificado. Se um invasor puder criar um pacote UDP que diga "oi, do IP X" para um servidor, o servidor normalmente responderá enviando um pacote UDP para X. Escolher X como o endereço de IP da vítima em vez do remetente é chamado de "falsificação" de UDP. Ao falsificar uma vítima, um invasor pode fazer com que um servidor que responde a solicitações UDP inunde a vítima com tráfego "refletido". Isso se aplica tanto a servidores autoritativos quanto a resolvedores recursivos abertos.

O DNSSEC também funciona sobre UDP e as respostas às consultas de DNS podem ser muito longas, contendo vários registros DNSKEY e RRSIG. Este é um alvo atraente para os invasores, pois permite que eles "amplifiquem" seus ataques de reflexão. Se um pequeno volume de solicitações de DNSSEC UDP falsificadas for enviado para nameservers, a vítima receberá um grande volume de tráfego refletido. Às vezes, isso é suficiente para sobrecarregar o servidor da vítima e causar uma negação de serviço.

A solicitação de um TLD que não existe de um servidor raiz retorna uma resposta de cerca de 100 bytes, a resposta assinada para a mesma pergunta é de cerca de 650 bytes ou um fator de amplificação de 6,5. A raiz é assinada usando uma chave RSA de 1.024 bits e usa NSEC para respostas negativas. Solicitar um domínio que não existe em um TLD usando NSEC3 assinado com chave de 1.024 bits resultará em um fator de amplificação em torno de 10. Existem outras consultas que podem gerar fatores de amplificação ainda maiores, sendo a mais eficaz a consulta “ANY”.

Como muitos serviços, o DNS também pode funcionar sobre TCP. Há um sinalizador de "truncamento" que pode ser enviado de volta a um resolvedor para indicar que o TCP é necessário. Isso resolveria o problema de reflexão de DNS ao custo de solicitações de DNS mais lentas. Esta solução não é prática no momento, pois 16% dos resolvedores não respeitam o sinalizador de truncamento TCP e 4% não tentam um segundo servidor.

Outra opção para reduzir o tamanho das respostas é usar chaves Elliptic Curve Digital Signature Algorithm (ECDSA) em vez de chaves RSA tradicionais. As chaves ECDSA são muito menores que as chaves RSA de força equivalente e produzem assinaturas menores tornando as respostas DNSSEC muito menores, reduzindo o fator de amplificação. O DNS público do Google adicionou suporte ao ECDSA no final de 2014 e vários outros seguiram o exemplo desde então.

O suporte para TCP e ECDSA ainda está atrasado em relação ao suporte geral ao DNSSEC, portanto, métodos antiabuso tradicionais podem ser usados. Isso inclui Limitação de Taxa de Recursos (RRL) e outras heurísticas.

Para se proteger contra ataques de reflexão, a Cloudflare está trabalhando em uma abordagem multifacetada. Primeiro, usando heurísticas de identificação de ataques e técnicas antiabuso que estamos usando atualmente em nosso servidor DNS e, segundo, reduzindo o fator de amplificação das respostas DNSSEC. As formas de reduzir o fator de amplificação máximo incluem apenas responder a solicitações “ANY” sobre TCP, usando chaves ECDSA menores quando possível e reduzindo a frequência de key rollovers.

A Cloudflare está ciente da complexidade introduzida pelo DNSSEC em relação à privacidade da zona, gerenciamento de chaves e risco de reflexão/amplificação. Com decisões inteligentes de engenharia e controles operacionais implementados, os perigos do DNSSEC podem ser evitados.