Como funciona o DNSSEC
O DNS (sistema de nomes de domínio) costuma ser considerado como a lista telefônica da internet, dizendo aos computadores para onde enviar e onde recuperar informações. Infelizmente, também aceita qualquer endereço que lhe for oferecido, sem questionar.
Os servidores de e-mail usam o DNS para rotear suas mensagens, o que significa que ficam vulneráveis a problemas de segurança na infraestrutura do DNS. Em setembro de 2014, pesquisadores da CMU encontraram e-mails supostamente enviados pelos servidores do Yahoo!, Hotmail e Gmail que, na verdade, estavam vindo de servidores de e-mail não autorizados. Os invasores estavam explorando uma vulnerabilidade muito antiga do DNS (Sistema de Nomes de Domínio): o sistema não verifica as credenciais antes de aceitar uma resposta.
A solução é um protocolo chamado DNSSEC, que adiciona uma camada de confiança ao DNS ao fornecer autenticação. Quando um resolvedor de DNS está procurando o subdomínio blog.cloudflare.com, os nameservers .com ajudam o resolvedor a verificar os registros retornados para a Cloudflare, enquanto a Cloudflare ajuda a verificar os registros retornados para o blog. Os nameservers do DNS raiz ajudam a verificar o domínio .com e as informações publicadas pelo raiz são confirmadas por um procedimento de segurança minucioso, incluindo a Cerimônia de Assinatura da Zona Raiz.
O DNSSEC cria um sistema de nomes de domínio seguro ao adicionar assinaturas criptográficas aos registros de DNS existentes. Essas assinaturas digitais são armazenadas nos nameservers do DNS juntamente com tipos comuns de registros, como o A, o AAAA, o MX, o CNAME etc. Ao verificar a assinatura associada, é possível verificar se um registro de DNS solicitado vem do nameserver autoritativo e não foi alterado pelo caminho, ao invés de um registro falso injetado em um ataque man-in-the-middle.
Para facilitar a validação da assinatura, o DNSSEC adiciona alguns novos tipos de registro de DNS:
- RRSIG — contém uma assinatura criptográfica
- DNSKEY — contém uma chave de assinatura pública
- DS — contém o hash de um registro DNSKEY
- NSEC e NSEC3 — para uma negação de existência explícita de um registro de DNS
- CDNSKEY e CDS — para uma zona filha solicitando atualizações de registros DS na zona mãe.
Neste artigo, falaremos sobre a interação entre os registros DS, DNSKEY e RRSIG e também como adicionam uma camada de confiança ao DNS.
O primeiro passo para proteger uma zona com DNSSEC é agrupar todos os registros de mesmo tipo em um conjunto de registros de recursos (RRSet). Por exemplo, se você tivesse três registros AAAA em sua zona no mesmo rótulo (por exemplo, rótulo.exemplo.com), todos seriam agrupados em um único RRSet AAAA.
Na verdade, é esse RRSet completo que é assinado digitalmente, e não os registros de DNS individuais. Evidentemente, isso também significa que você deve solicitar e validar todos os registros AAAA de uma zona com o mesmo rótulo, ao invés de validar apenas um deles.
Cada zona no DNSSEC tem um par de chaves de assinatura de zona (ZSK): a parte privada da chave assina digitalmente cada RRSet na zona, enquanto a parte pública verifica a assinatura. Para habilitar o DNSSEC, um operador de zona cria assinaturas digitais para cada RRSet usando a ZSK privada e as armazena em seu nameserver como registros RRSIG. É como dizer o seguinte: “Esses são meus registros de DNS. Eles vêm do meu servidor e devem ter essa aparência”.
No entanto, esses registros RRSIG são inúteis, a menos que os resolvedores de DNS tenham uma maneira de verificar as assinaturas. O operador de zona também precisa disponibilizar sua ZSK pública adicionando-a ao nameserver em um registro DNSKEY.
Quando um resolvedor de DNSSEC solicita um tipo de registro específico (por exemplo, AAAA), o nameserver também retorna o RRSIG correspondente. O resolvedor pode, em seguida, extrair do nameserver o registro DNSKEY que contém a ZSK pública. Juntos, o RRSet, o RRSIG e a ZSK pública podem validar a resposta.
Se confiarmos na chave de assinatura de zona no registro DNSKEY, será possível confiar em todos os registros existentes na zona. Mas, e se a chave de assinatura de zona tiver sido comprometida? Precisamos de uma maneira de validar a ZSK pública.
Além de uma chave de assinatura de zona, os nameservers DNSSEC também têm uma chave de assinatura de chave (KSK). A KSK valida o registro DNSKEY exatamente da mesma maneira que nossa ZSK protegeu o resto de nossos RRSets na seção anterior: ela assina a ZSK pública (que é armazenada em um registro DNSKEY), criando um RRSIG para o DNSKEY.
Assim como a ZSK pública, o nameserver publica a KSK pública em outro registro DNSKEY, o que nos fornece o RRSet do DNSKEY mostrado acima. Tanto a KSK pública quanto a ZSK pública são assinadas pela KSK privada. Os resolvedores podem, em seguida, usar a KSK pública para validar a ZSK pública.
Agora, a validação para os resolvedores tem a seguinte aparência:
- Solicite o RRSet desejado, que também retorna o registro RRSIG correspondente.
- Solicite os registros DNSKEY que contêm a ZSK pública e a KSK pública, que também retornam o RRSIG para o RRSet do DNSKEY.
- Verifique o RRSIG do RRSet solicitado com a ZSK pública.
- Verifique o RRSIG do RRSet do DNSKEY com a KSK pública.
Evidentemente, o RRSet do DNSKEY e os registros RRSIG correspondentes podem ser armazenados em cache, de forma que os nameservers do DNS não sejam constantemente bombardeados por solicitações desnecessárias.
Por que usamos chaves de assinatura de zona e chaves de assinatura de chave separadas? Como discutiremos na próxima seção, é difícil trocar uma KSK antiga ou comprometida. Mudar a ZSK, por outro lado, é muito mais fácil. Isso nos permite usar uma ZSK menor sem comprometer a segurança do servidor, minimizando a quantidade de dados que o servidor precisa enviar com cada resposta.
Agora, estabelecemos confiança dentro da nossa zona. No entanto, o DNS é um sistema hierárquico, e as zonas raramente operam de forma independente. Para complicar ainda mais as coisas, a chave de assinatura de chave é assinada por ela mesma, o que não proporciona nenhuma confiança adicional. Precisamos de uma maneira de conectar a confiança em nossa zona com sua zona mãe.
O DNSSEC apresenta um registro de signatário de delegação (DS) para permitir a transferência de confiança de uma zona mãe para uma zona filha. Um operador de zona faz o hash do registro DNSKEY que contém a KSK pública e o fornece à zona mãe para publicar como um registro DS.
Sempre que um resolvedor é encaminhado a uma zona filha, a zona mãe também fornece um registro DS. É com esse registro DS que os resolvedores sabem que a zona filha está ativada para DNSSEC. Para verificar a validade da KSK pública da zona filha, o resolvedor faz um hash dela e o compara ao registro DS da mãe. Se coincidirem, o resolvedor pode presumir que a KSK pública não foi adulterada, o que significa que pode confiar em todos os registros existentes na zona filha. É assim que uma cadeia de confiança é estabelecida no DNSSEC.
Observe que qualquer alteração na KSK também requer uma alteração no registro DS da zona mãe. Alterar o registro DS é um processo em várias etapas que pode acabar destruindo a zona se for executado incorretamente. Primeiro, a mãe precisa adicionar o novo registro DS. Em seguida, é preciso esperar até que o TTL do registro DS original expire antes de removê-lo. Por essa razão, é muito mais fácil trocar as chaves de assinatura de zona do que as chaves de assinatura de chave.
Negação de existência explícita
Se você pedir ao DNS o endereço de IP de um domínio que não existe, ele retorna uma resposta vazia, já que não há como dizer explicitamente: “Desculpe, a zona solicitada não existe”. Isso constitui um problema se você deseja autenticar a resposta, pois não há nenhuma mensagem para assinar. O DNSSEC corrige isso adicionando os tipos de registro NSEC e NSEC3. Ambos permitem uma negação de existência autenticada.
O NSEC funciona retornando o "próximo registro seguro". Considere, por exemplo, um nameserver que define registros AAAA para uma API, um blog e um endereço www. Se você solicitasse um registro para "store" (loja), ele retornaria um registro NSEC contendo www, o que significa que não há registros AAAA entre store e www quando os registros são classificados em ordem alfabética. Isso informa, efetivamente, que "store" não existe. Como o registro NSEC é assinado, você pode validar seu RRSIG correspondente como faria com qualquer RRSet.
Infelizmente, essa solução permite que qualquer pessoa atravesse a zona e colete todos os registros sem saber quais deles está procurando. Isso poderia ser uma ameaça de segurança em potencial se o administrador da zona estivesse contando com o fato de que o conteúdo da zona fosse privado. Você pode ler mais sobre esse problema no artigo DNSSEC: complexidades e considerações, e também sobre a solução exclusiva da Cloudflare no artigo DNSSEC feito corretamente.
Certo, então temos uma maneira de estabelecer a confiança dentro de uma zona e conectá-la com sua zona mãe. Mas como podemos confiar no registro DS? Bem, o registro DS é assinado exatamente como qualquer outro RRSet. Isso significa que tem um RRSIG correspondente na zona mãe. O processo inteiro de validação se repete até chegarmos à KSK pública da mãe. Para verificar isso, precisamos ir ao registro DS da mãe e assim por diante, à medida que avançamos na cadeia de confiança.
No entanto, quando finalmente chegamos à zona raiz do DNS, temos um problema: não há registro DS mãe frente ao qual validar. É aqui que vemos um lado muito humano da internet global.
Na Cerimônia de Assinatura da Zona Raiz, vários indivíduos selecionados de todo o mundo se reúnem e assinam o RRSet do DNSKEY raiz de uma forma muito pública e altamente auditada. A cerimônia produz um registro RRSIG que pode ser usado para verificar a KSK e a ZSK públicas do nameserver raiz. Ao invés de confiar na KSK pública por conta do registro DS da mãe, presumimos que ela é válida porque confiamos nos procedimentos de segurança em torno do acesso à KSK privada.
A capacidade de estabelecer confiança entre as zonas mãe e filha é uma parte integrante do DNSSEC. Se alguma parte da cadeia for violada, não poderemos confiar nos registros que estamos solicitando porque um man-in-the-middle poderia alterar os registros e nos direcionar para qualquer endereço de IP que quisesse.
Resumo
De modo semelhante ao HTTPS, o DNSSEC adiciona uma camada de segurança, permitindo respostas autenticadas acrescentadas a um protocolo que, caso contrário, seria inseguro. Enquanto o HTTPS criptografa o tráfego para que ninguém na rede possa espionar suas atividades na internet, o DNSSEC apenas assina as respostas para que as falsificações sejam detectáveis. O DNSSEC fornece uma solução para um problema real sem a necessidade de incorporar criptografia.
O objetivo da Cloudflare é facilitar o máximo possível a ativação do DNSSEC. No momento, os clientes com planos pagos da Cloudflare podem adicionar o DNSSEC às suas propriedades da web, alternando um botão de opção para habilitar o DNSSEC e carregando um registro DS (que geraremos automaticamente) no seu registrador registradores. Saiba mais sobre como obter o DNSSEC.
Também publicamos uma versão preliminar da internet que descreve uma maneira automatizada para registros e registrador registradores carregarem registros DS em nome de nossos clientes. Isso permitirá que a Cloudflare habilite automaticamente o DNSSEC para toda a nossa comunidade. Fique atento às atualizações.
É fácil configurar a Cloudflare
Configure um domínio em menos de 5 minutos. Mantenha seu provedor de hospedagem. Não é necessária nenhuma alteração de código.