Protective DNS Explicado: Como Funciona e Por Que É Importante

Um convidado no átrio de um hotel toca num link e a página começa a carregar. Antes que o navegador se consiga ligar ao site, o dispositivo do convidado precisa de descobrir onde esse site se encontra na internet. Essa consulta silenciosa é uma oportunidade para verificar se o destino deve ser permitido.

DNS de proteção adiciona uma decisão de segurança a este passo de rotina. Pode ajudar as organizações a proteger pessoas e dispositivos em redes partilhadas, mas só funciona quando o tráfego utiliza o resolvedor gerido. Compreender essa distinção facilita o planeamento de desempenho, exceções, rotas de desvio e privacidade.

Índice

• Por que razão cada visita a um site começa com uma pesquisa de DNS
• O que o DNS de proteção faz na fase de resolução de nomes
  • A encriptação e a autenticidade não são o mesmo que uma decisão de segurança
• Como funciona a aplicação de políticas numa rede
  • Aplicar a identidade sem multiplicar as políticas
  • Fechar as rotas de contorno deliberadamente
• Impacto no desempenho e ganhos mensuráveis no carregamento de páginas
  • Testar a pesquisa, não apenas a impressão
  • Incluir as condições que expõem surpresas
• Casos de uso reais em edifícios, recintos e empresas
• Escolher a abordagem certa para a sua rede
• Medir o valor do DNS de proteção para além da contagem de bloqueios
  • Criar um scorecard focado em resultados e exceções
  • Tratar os registos de DNS como dados operacionais sensíveis
• Próximos passos para planejar a implementação do seu DNS de proteção

Por que razão cada visita a um website começa com uma consulta DNS

O nome de um website é fácil de memorizar pelas pessoas. Os computadores precisam de um endereço de rede para se conetarem. O Domain Name System (DNS) fornece a tradução, funcionando como uma lista telefónica que converte o nome de uma pessoa num número para o qual pode ligar.

Quando o convidado toca no link, o navegador pede a um resolvedor DNS o endereço associado ao nome do site. O resolvedor procura a resposta e envia-a de volta. O navegador pode então tentar ligar-se ao destino. O DNS não transporta a página em si, mas ajuda o dispositivo a encontrar onde deve solicitá-la.

Esta sequência cria um ponto de controlo de segurança útil. Se o resolvedor reconhecer um domínio solicitado como uma ameaça conhecida, pode recusar-se a fornecer uma resposta útil antes de o navegador se ligar. Um serviço de DNS de proteção aplica políticas de segurança nesta fase de consulta, em vez de esperar por um ficheiro descarregado ou por uma ação suspeita no dispositivo final.

A distinção prática: O DNS ajuda um dispositivo a encontrar um destino. O DNS de Proteção adiciona uma decisão sobre se a procura deve ter sucesso.

Isto é especialmente importante em locais onde muitas pessoas e dispositivos partilham a infraestrutura de rede. Um hotel pode ter telefones de hóspedes, portáteis de funcionários, terminais de pagamento e equipamentos de edifícios conectados a utilizar diferentes partes da mesma rede global. Um escritório, uma propriedade residencial ou um local público enfrentam um desafio semelhante, embora os utilizadores e os dispositivos sejam diferentes.

O DNS de proteção pode fornecer um ponto de controlo comum para essas pesquisas, mas não constitui um programa de segurança completo. Não protegerá um dispositivo que evite o resolvedor gerido, e não substitui a proteção do ponto final, os controlos de acesso ou uma conceção de rede cuidada. As questões úteis são saber como o resolvedor toma as suas decisões, como uma organização mantém os dispositivos no caminho pretendido e que evidências mostram que o serviço está a ajudar sem causar perturbações.

O que o DNS protetor faz na fase de resolução de nomes

O DNS de proteção é um resolvedor recursivo de aplicação de políticas. Um resolvedor recursivo lida com pedidos em nome de um dispositivo, enquanto o DNS de proteção aplica regras para decidir se um destino solicitado deve receber uma resposta DNS normal. Não se trata apenas de DNS tornado mais rápido ou encriptado.

Siga uma pesquisa do início ao fim:

1. O dispositivo solicita um nome de domínio. Um navegador, aplicação ou outro processo necessita de um endereço antes de poder tentar ligar-se a um destino nomeado.
2. O resolvedor verifica o pedido. Compara o domínio com as políticas configuradas e a inteligência de ameaças. Implementações mais robustas também podem verificar um endereço IP resolvido, o que ajuda a avaliar a infraestrutura por trás de um nome.
3. O resolvedor devolve um resultado. Se a política permitir o pedido, o resolvedor fornece uma resposta. Se não permitir, o serviço pode bloquear a resolução, devolver uma resposta vazia ou redirecionar o cliente para uma página de aviso. O comportamento exato depende do produto e da política.

Algumas implementações procuram domínios gerados algoritmicamente (DGAs), que o malware pode utilizar para encontrar infraestruturas de comando e controlo. Padrões invulgares nos carateres de um domínio, incluindo uma elevada entropia, podem servir de sinal para uma avaliação adicional da política. Esse tipo de análise pode complementar as fontes de informação sobre ameaças, mas as organizações continuam a precisar de validar como o serviço escolhido gere a deteção e as exceções.

Encriptação e autenticidade não são o mesmo que uma decisão de segurança

O DNSSEC ajuda a verificar a integridade e a autenticidade dos dados DNS assinados. O DNS over HTTPS (DoH) e o DNS over TLS (DoT) protegem as consultas DNS em trânsito. Essas propriedades são importantes, mas não determinam por si só se um domínio existente é malicioso. O DNS de proteção toma essa decisão de política no resolvedor.

Para as equipas que analisam os controlos de acesso à web e serviços de nuvem, esta distinção pode surgir ao lado de orientações mais amplas sobre proteger ambientes empresariais do Microsoft 365. O ponto principal é evitar tratar o transporte encriptado ou os dados autenticados como um substituto para uma decisão sobre o risco do destino.

Como funciona a aplicação de políticas numa rede

Um resolvedor pode tomar uma decisão acertada para um único pedido e, ainda assim, falhar na proteção de uma rede se os dispositivos conseguirem encaminhar o DNS à sua volta. A implementação em todo o parque de dispositivos diz respeito, portanto, a duas coisas interligadas: políticas consistentes e um caminho fiável para o resolvedor.

Um design centralizado envia pedidos de DNS de vários locais para um serviço gerido. Isso facilita a aplicação de regras partilhadas e a revisão da atividade em diferentes localizações. Também torna a disponibilidade um requisito de segurança. Se o resolvedor estiver inacessível, o acesso comum à web e os serviços que dependem de DNS podem falhar, mesmo quando o restante da rede está a funcionar.

O serviço de DNS de proteção do governo dos EUA ficou disponível para as agências do Federal Civilian Executive Branch em setembro de 2022. Em agosto de 2024, mais de 104 agências tinham aderido, gerando uma média de 1,6 mil milhões de consultas de DNS seguras diariamente; o programa reportou 99,999% de tempo de atividade do resolver (ficha informativa de DNS de proteção da CISA). A lição operacional é que a qualidade de filtragem e a disponibilidade do serviço precisam de ser avaliadas em conjunto.

Aplique a identidade sem multiplicar as políticas

Funcionários, convidados, residentes e equipamentos conectados não precisam necessariamente das mesmas regras. Uma rede pode atribuir políticas diferentes com base na identidade ou no segmento de rede, como uma rede de funcionários, WiFi de convidados e uma rede isolada para dispositivos do edifício. O objetivo é adaptar a política ao utilizador ou dispositivo, mantendo a administração simples.

Os controlos de acesso ajudam a estabelecer essa separação, enquanto a monitorização do tráfego de rede pode ajudar as equipas a investigar atividades de rede invulgares. Para uma visão relacionada sobre como o controlo de acesso à rede se enquadra num ambiente gerido, consulte estas soluções de controlo de acesso à rede.

Feche as rotas de desvio de forma deliberada

Se um dispositivo conseguir enviar DNS comum diretamente para um resolvedor externo, o serviço de proteção poderá nunca ver o pedido. O DoH e o DoT criam outro desafio: a encriptação pode proteger as consultas em trânsito, mas um resolvedor não gerido também pode removê-las da política e da visibilidade da organização.

Onde a aplicação for necessária, as equipas devem identificar caminhos de DNS diretos e destinos de DNS encriptados não autorizados, e depois decidir como os controlos de rede, de ponto final e de navegador os irão gerir. Teste também as exceções. Portais Captive Portal, dispositivos móveis, IPv6 e aplicações com as suas próprias definições de resolvedor podem comportar-se de forma diferente de um portátil gerido numa rede empresarial. A política só funciona nos caminhos que a organização consegue governar.

Impacto no desempenho e ganhos mensuráveis no carregamento de páginas

Um serviço de DNS de proteção não precisa de tornar a navegação percetivelmente mais lenta. O impacto depende menos do ato de filtragem do que de escolhas práticas de conceção: onde se encontra o resolvedor, como armazena as respostas em cache, como mantém as ligações e se os dispositivos o contornam.

O DNS encriptado pode adicionar tempo de configuração quando uma ligação precisa de estabelecer TCP, TLS ou HTTP antes de enviar uma consulta. Reutilizar uma sessão persistente evita repetir grande parte dessa configuração. TLS 1.3, 0-RTT, multiplexagem HTTP/2 e QUIC também podem reduzir a sobrecarga de ligação, de acordo com medições independentes de desempenho de DNS encriptado. Em condições de rede saudáveis, a latência de pesquisa bruta pode ser insignificante, mas isso não é garantido para todos os clientes ou caminhos de rede.

Teste a pesquisa, não apenas a impressão

Um

Meça a latência de consulta p50, p90 e p99 separadamente para caches frios e quentes. A mediana mostra uma consulta típica; os percentis mais elevados revelam casos mais lentos que podem afetar os utilizadores de forma mais acentuada. Mantenha a velocidade de consulta distinta do tempo total de carregamento da página, uma vez que o DNS é apenas uma parte da jornada de um navegador.

Inclua as condições que revelam surpresas

Teste a partir do tipo de redes e dispositivos que as pessoas utilizam, incluindo clientes móveis, IPv6 e Captive Portals. Verifique aplicações e navegadores que possam selecionar o seu próprio serviço DoH ou DoT, pois estes podem alterar tanto a rota como a visibilidade dos pedidos DNS.

Foi observado em medições distribuídas que o DoQ (DNS over QUIC) se aproxima do desempenho de texto simples e melhora alguns casos de carregamento de páginas em comparação com o DoH. Considere estas descobertas como uma razão para testar opções de transporte no seu próprio ambiente, e não como uma promessa de um resultado específico. O objetivo prático é um resolver próximo, armazenamento em cache eficaz, sessões encriptadas reutilizáveis e uma arquitetura que não deixe caminhos não geridos abertos.

Casos de uso reais em grandes espaços e empresas

Uma implementação nacional mostra o que o DNS de proteção pode fazer quando muitas organizações partilham uma camada de segurança gerida. No Reino Unido, o número de organizações a utilizar o serviço Protective Domain Name System subiu de 944 para 1173 em 2022, um aumento de 24%. Ao longo desse ano, o serviço processou aproximadamente 0,55 biliões de consultas de DNS e bloqueou 11 mil milhões de pedidos associados a destinos maliciosos, cerca de 2% de todas as consultas (resumo do NCSC PDNS do Reino Unido).

Essa escala ilustra o valor de tomar uma decisão antes que uma ligação seja tentada. Não prova que cada pedido bloqueado se teria tornado num incidente, ou que o DNS sozinho tenha travado todas as vias para uma ameaça. Para um operador com múltiplos locais, a comparação útil é determinar se o serviço consegue aplicar a política de forma consistente, produzir telemetria acionável e lidar com o volume e as exceções desse ambiente.

Considere como o mesmo ponto de controlo se adapta a diferentes locais:

• Hotéis e propriedades residenciais: Separar o acesso de hóspedes ou residentes dos dispositivos do pessoal e do edifício. Um Captive Portal, um dispositivo mais antigo ou o resolvedor encriptado preferido de um residente podem criar uma exceção para a qual se deve planejar.
• Aeroportos e estádios: Aplicar uma linha de base comum a todo o acesso público de alta rotatividade, mantendo as redes operacionais e do pessoal distintas. Prestar atenção a dispositivos não geridos e a necessidades de conectividade que exijam uma exceção documentada.
• Saúde e educação: Restringir o acesso a destinos prejudiciais sem bloquear serviços legítimos utilizados para cuidados de saúde, ensino ou administração. Disponibilizar um processo de revisão claro quando uma política bloqueia algo necessário para o trabalho.
• Comércio e centros comerciais: Distinguir o tráfego de visitantes dos terminais de pagamento, dispositivos do pessoal e outros equipamentos operacionais. As equipas de retalho que planeiam o acesso de convidados também podem achar estas soluções de WiFi para retalho úteis ao pensar em como o acesso e as políticas se articulam.

Uma breve introdução ao tema também pode ajudar as equipas a alinhar-se sobre o que a camada de DNS faz e não faz:

Em cada cenário, a filtragem de DNS é um controlo parcial, e não uma garantia de que todas as ameaças serão travadas. Um utilizador pode aceder à infraestrutura através de outro resolver ou de um endereço IP direto, e uma aplicação pode utilizar protocolos que não dependem do caminho de DNS da organização. A implementação necessita de gestão de exceções e monitorização a par da própria política.

Escolher a abordagem certa para a sua rede

O DNS de proteção funciona ao nível do resolvedor. Os agentes de ponto final, as definições do navegador e os controlos de rede operam em pontos diferentes, pelo que as equipas costumam escolher uma combinação em vez de um único substituto. A combinação certa depende de quem gere o dispositivo, de qual o tráfego que a rede consegue ver e de como as exceções devem ser tratadas.

Controlo	Melhor Adequação	Visibilidade	Limitação Comum
DNS de Proteção	Redes partilhadas, edifícios geridos e aplicação de políticas de DNS	Pedidos DNS que passam pelo resolvedor	Resolvedores não geridos e caminhos não-DNS podem contorná-lo
Agente de ponto final	Portáteis e dispositivos móveis geridos que precisam de proteção fora da rede	Atividade visível para o agente instalado	A cobertura depende da instalação, estado e gestão do agente
Política de navegador	Navegadores geridos onde o resolvedor e as definições de navegação podem ser governados	Configuração do navegador e atividade selecionada do navegador	Não governa todas as aplicações ou navegadores não geridos
Controlos ao nível da rede	Redes segmentadas e tráfego que passa por infraestruturas geridas	Fluxos de rede dentro da cobertura do controlo	Tráfego encriptado ou fora da rede pode limitar a inspeção
Controlos de identidade e acesso	Funcionários, convidados, residentes e grupos de dispositivos com necessidades de acesso distintas	Decisões de ligação e acesso vinculadas à identidade ou segmento	Uma ligação permitida não julga, por si só, cada destino

Para portáteis geridos, os controlos de pontos finais e de navegadores podem complementar a política de resolvers, especialmente quando os colaboradores trabalham fora do escritório. O WiFi de convidados e o BYOD são mais difíceis de gerir com agentes, tornando os controlos do lado da rede mais práticos, desde que a organização consiga direcionar o DNS para o serviço escolhido. Os dispositivos IoT e residenciais necessitam frequentemente de segmentação e de uma política que tenha em conta as opções limitadas de gestão de dispositivos.

Para as equipas que comparam a identidade da rede, a filtragem e as verificações focadas no utilizador, os verificadores gratuitos de DNS e e-mail da mailX podem ser um recurso relevante a par de uma análise mais ampla dos controlos de acesso. Se os ambientes de pagamento fizerem parte da infraestrutura, considere também como a conceção de WiFi e os requisitos de conformidade PCI-DSS afetam a separação e a administração da rede.

O Purple Access combina opções de rede abertas, seguras e xPSK em pontos de acesso existentes, com integração via Captive Portal e atribuição de rede orientada pela identidade. O Purple Shield adiciona DNS de proteção e filtragem de conteúdos com controlos por política. Essas capacidades podem funcionar em conjunto com controlos de ponto de extremidade e de navegador, mas não eliminam a necessidade de definir a aplicação de resolvers, exceções e monitorização. Escolha ferramentas de acordo com os caminhos e dispositivos que precisa de proteger e, em seguida, verifique se as suas políticas funcionam em conjunto.

Medir o valor do DNS protetor para além da contagem de bloqueios

Um total de consultas bloqueadas indica que o resolver atuou. Por si só, não informa se identificou os pedidos corretos, se interrompeu trabalho útil ou se perdeu tráfego que seguiu outra rota. Registe a decisão, mas meça o controlo.

O workshop de DNS da European Internet Industry Association reportou 2,3 milhões de relatórios de abusos abrangendo 780 000 domínios únicos durante os seis meses anteriores, com os relatórios mensais a subir de 220 000 para 380 000 (relatório do workshop). Esses números mostram a escala do abuso reportado. Não estabelecem quantos incidentes um resolver evitou, se um bloqueio foi correto ou se o tráfego afetado alcançou um destino através de uma VPN, um resolver alternativo, um endereço IP codificado ou um protocolo de aplicação encriptado.

Crie um scorecard focado em resultados e exceções

Uma análise útil combina segurança, qualidade de serviço e resposta operacional. Acompanhe se o resolvedor detetou domínios maliciosos conhecidos, a rapidez com que as equipas tratam recursos contra falsos positivos e se as alterações de política chegam rapidamente aos locais pretendidos. Combine essas medições com a disponibilidade do resolvedor e a latência de consulta mediana e de cauda.

Meça também as tentativas de desvio. Um número reduzido de pedidos bloqueados pode significar que o ambiente tem pouca atividade maliciosa, ou pode indicar que os dispositivos não estão a utilizar o resolvedor de proteção. Correlacione eventos relevantes com a identidade da rede, como um SSID, VLAN, local ou grupo de utilizadores, para que as equipas de investigação possam ver onde uma política se aplica e onde uma exceção possa estar escondida. Compare a atividade do DNS com os dados de pontos finais ou de incidentes em vez de afirmar que cada pesquisa bloqueada representa um incidente evitado.

Trate os registos de DNS como dados operacionais sensíveis

Os registos de DNS podem revelar padrões de navegação, o que exige cuidado em ambientes de saúde, educação, hotelaria e residenciais. Defina limites de retenção, restrinja o acesso por função e mantenha a telemetria de segurança separada dos dados de marketing de convidados. Decida quem pode investigar um evento de segurança e de que dados precisa antes de recolher registos em grande escala.

Próximos Passos para Planear a Sua Implementação de Protective DNS

Comece pelo caminho, não pelo painel de controlo. Mapeie quais os dispositivos que utilizam o resolvedor gerido, identifique onde o DNS direto ou o DNS encriptado não autorizado poderiam contorná-lo e decida como funcionará a aplicação para dispositivos que a organização não gere. Inclua um processo de exceção para serviços legítimos que uma política bloqueie.

Antes do lançamento, defina como a equipa irá avaliar tanto a segurança como a qualidade do serviço:

• Confirmar a utilização do resolvedor: Verifique dispositivos geridos, redes de convidados e dispositivos menos previsíveis, como IoT.
• Testar o caminho da rede: Onde a aplicação for necessária, reveja o DNS direto e as rotas de DNS encriptado não autorizadas.
• Medir o desempenho: Compare a latência de procura em cache fria e quente, incluindo percentis mais lentos.
• Definir o scorecard: Acompanhe a gestão de falsos positivos, a disponibilidade, a propagação de políticas, as tentativas de bypass e os resultados dos incidentes.
• Definir regras de privacidade: Estabeleça limites de retenção e acesso aos registos antes que a recolha abrangente comece.

Para uma implementação em múltiplos locais, reúna as equipas de rede e de segurança para mapear identidades, segmentos de rede, rotas do resolvedor e as exceções que cada local necessita. A Purple oferece sessões de conceção orientadas por engenheiros de rede para definir e validar os planos de implementação. O DNS de proteção pode tornar os destinos nocivos mais difíceis de alcançar através do caminho de pesquisa gerido, mas não substituirá a segurança dos pontos finais, a segmentação de rede ou a governação de privacidade.

---

O Purple Access suporta redes WiFi abertas, seguras e xPSK, com atribuição de rede orientada pela identidade e integração de convidados ou BYOD nos pontos de acesso existentes. Para planear como esses controlos de acesso podem funcionar em conjunto com o DNS de proteção nos seus locais, visite o Purple Access.