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.

Ícone do DNSSEC

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.

Uma apresentação suave do DNSSEC

O DNSSEC cria um sistema de nomes de domínio seguro ao adicionar assinaturas criptográficas aos registros 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 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 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 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.

RRsets

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.

diagrama de rrsets

Na verdade, é esse RRSet completo que é assinado digitalmente, e não os registros 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.

Chaves de assinatura de zona

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 DNS. Eles vêm do meu servidor e devem ter essa aparência”.

diagrama de chaves de assinatura de zona 1

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.

diagrama de chaves de assinatura de zona 2

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.

Chaves de assinatura de chave

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.

diagrama de chaves de assinatura de chave 1

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.
diagrama de chaves de assinatura de chave 2

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.

Registros de signatários de delegação

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.

diagrama de registros de signatário de delegação

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 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 a loja em questão 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.

A cadeia de confiança

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.

diagrama da 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 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 bisbilhotar 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 registrar. Saiba mais sobre como obter o DNSSEC.

Também publicamos uma versão preliminar da internet que descreve uma maneira automatizada para registros e registrars 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 é preciso alterações no código.

Preços da Cloudflare

O aplicativo de Internet de todos pode se beneficiar com o uso da Cloudflare.
Escolha o melhor plano para suas necessidades.

Free US$ 0 /mês, por site
Expandir para ver mais Ocultar
Para sites pessoais, blogs e quem quiser explorar a Cloudflare.

Saiba mais

O Free Plan oferece todas estas funcionalidades:
  • Mitigação ilimitada de DDoS
  • CDN global
  • Certificado SSL compartilhado
  • Acesso aos registros de auditoria da conta
  • 3 Page Rules
Compare todas as funcionalidades
Pro US$ 20 /mês por site
Expandir para ver mais Ocultar
Para sites profissionais, blogs e portfólios que precisam de segurança e desempenho básicos.

Saiba mais

O Pro Plan inclui tudo que há no Free e:
  • Web application firewall (WAF) com conjuntos de regras da Cloudflare
  • Otimizações de imagens com Polish™
  • Otimizações de dispositivos móveis com Mirage™
  • Modo I'm Under Attack™
  • Acesso aos registros de auditoria da conta
  • 20 Page Rules
Compare todas as funcionalidades
Business US$ 200 /mês por site
Expandir para ver mais Ocultar
Para pequenos sites e empresas de comércio eletrônico que precisam de segurança e desempenho avançados, conformidade com os padrões PCI e prioridade no suporte por e-mail.

Saiba mais

O Business Plan inclui tudo que há no Pro e:
  • Web application firewall (WAF) com 25 conjuntos de regras personalizadas
  • Carregamento de certificado SSL personalizado
  • Conformidade com os padrões PCI graças ao modo Modern TLS Only e WAF
  • Bypass Cache on Cookie
  • Veiculação acelerada de conteúdo dinâmico com Railgun™
  • Suporte prioritário por e-mail
  • Acesso aos registros de auditoria da conta
  • 50 Page Rules
Compare todas as funcionalidades
Enterprise Fale conosco
Expandir para ver mais Ocultar
Para empresas que requerem segurança e desempenho de nível empresarial, suporte priorizado e ininterrupto por telefone, e-mail ou chat, e tempo de atividade garantido.

Saiba mais

O Enterprise Plan inclui tudo que há no Business e:
  • Suporte ininterrupto de nível empresarial por telefone, chat e e-mail
  • Garantia de 100% de tempo de atividade com SLA que prevê reembolso de 25 vezes o valor pago
  • Proteção contra DDoS de nível empresarial com priorização de rede
  • Web application firewall (WAF) avançado com conjuntos de regras personalizadas ilimitados
  • Acesso a contas multiusuário com base na função
  • Carregamentos de vários certificados SSL personalizados
  • Acesso a logs brutos
  • Acesso aos registros de auditoria da conta
  • Engenheiros de solução e Customer Success designados
  • Acesso a data centers da rede de distribuição de conteúdo da China (custo adicional)
  • 100 Page Rules
Compare todas as funcionalidades

Free

US$ 0 / mês
 
Para sites pessoais, blogs e quem quiser explorar a Cloudflare.

Pro

US$ 20 / mês
por domínio
Para sites profissionais, blogs e portfólios que precisam de segurança e desempenho básicos.

Business

US$ 200 / mês
por domínio
Para pequenos sites e empresas de comércio eletrônico que precisam de segurança e desempenho avançados, conformidade com os padrões PCI e prioridade no suporte por e-mail.

Enterprise

Fale conosco
 
Para empresas que requerem segurança e desempenho de nível empresarial, suporte priorizado e ininterrupto por telefone, e-mail ou chat e tempo de atividade garantido.

Contamos com a confiança de

Mais de 25.000.000 ativos da internet

trustedby crunchbase black
trustedby ao com black
trustedby zendesk black
logo sofi gray 32px wrapper
trustedby log me in black
trustedby digital ocean black
trustedby okcupid black
trustedby montecito black
trustedby discord black
trustedby library of congress black
trustedby udacity black
trustedby marketo black