Protective DNS explicado: como funciona e por que é importante
Published
Um visitante no saguão de um hotel toca em um link e a página começa a carregar. Antes que o navegador possa se conectar ao site, o dispositivo do visitante precisa descobrir onde esse site está localizado na internet. Essa consulta silenciosa é uma oportunidade para verificar se o destino deve ser permitido.
O DNS de proteção adiciona uma decisão de segurança a esta etapa rotineira. Ele pode ajudar as organizações a proteger pessoas e dispositivos em redes compartilhadas, mas funciona apenas quando o tráfego usa o resolvedor gerenciado. Entender essa distinção facilita o planejamento para desempenho, exceções, rotas de desvio e privacidade.
Índice
- Por que toda visita a um site começa com uma busca DNS
- O que o DNS protetivo faz na etapa de resolução de nomes
- Como funciona a aplicação de políticas em toda a rede
- Impacto no desempenho e ganhos mensuráveis no carregamento de páginas
- Casos de uso no mundo real em locais de grande circulação e empresas
- Escolhendo a abordagem certa para a sua rede
- Medindo o valor do DNS protetivo além das contagens de bloqueios
- Próximos passos para planejar a implantação do seu DNS protetivo
Por que toda visita a um site começa com uma consulta de DNS
O nome de um site é fácil de ser lembrado pelas pessoas. Já os computadores precisam de um endereço de rede para se conectar. O Domain Name System (DNS) faz essa tradução, de forma muito parecida com uma agenda telefônica que transforma o nome de uma pessoa em um número para o qual você pode ligar.
Quando o visitante toca no link, o navegador pede a um resolvedor DNS o endereço associado ao nome do site. O resolvedor consulta a resposta e a envia de volta. O navegador pode então tentar se conectar ao destino. O DNS não transporta a página em si, mas ajuda o dispositivo a encontrar onde solicitá-la.
Essa sequência cria um ponto de verificação de segurança útil. Se o resolvedor reconhecer um domínio solicitado como uma ameaça conhecida, ele poderá se recusar a fornecer uma resposta útil antes que o navegador se conecte. Um serviço de DNS de proteção aplica políticas de segurança nesta etapa de consulta, em vez de esperar por um arquivo baixado ou uma ação suspeita no endpoint.
A distinção prática: O DNS ajuda um dispositivo a encontrar um destino. O DNS Protegido adiciona uma decisão sobre se a busca deve ser bem-sucedida.
Isso é importante especialmente em locais onde muitas pessoas e dispositivos compartilham a infraestrutura de rede. Um hotel pode ter telefones de hóspedes, laptops de funcionários, terminais de pagamento e equipamentos prediais conectados usando diferentes partes da mesma rede geral. Um escritório, propriedade residencial ou local público enfrenta um desafio semelhante, embora os usuários e dispositivos sejam diferentes.
O DNS de proteção pode fornecer um ponto de verificação comum para essas consultas, mas não é um programa de segurança completo. Ele não protegerá um dispositivo que evite o resolvedor gerenciado e não substitui a proteção de endpoint, os controles de acesso ou um projeto de rede cuidadoso. As perguntas úteis são como o resolvedor toma sua decisão, como uma organização mantém os dispositivos no caminho pretendido e quais evidências mostram que o serviço está ajudando sem causar interrupções.
O que o DNS protetivo faz na etapa de resolução de nomes
O DNS de proteção é um resolvedor recursivo com aplicação de políticas. Um resolvedor recursivo lida com solicitações 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. Ele não é apenas um DNS mais rápido ou criptografado.
Acompanhe uma busca do início ao fim:
- O dispositivo solicita um nome de domínio. Um navegador, aplicativo ou outro processo precisa de um endereço antes de tentar se conectar a um destino nomeado.
- O resolvedor verifica a solicitação. Ele compara o domínio com as políticas configuradas e com 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.
- O resolvedor retorna um resultado. Se a política permitir a solicitação, o resolvedor fornece uma resposta. Se não permitir, o serviço pode bloquear a resolução, retornar 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 por domínios gerados algoritmicamente, ou DGAs, que malwares podem usar para encontrar infraestruturas de comando e controle. Padrões incomuns nos caracteres de um domínio, incluindo alta entropia, podem atuar como um sinal para uma avaliação adicional da política. Esse tipo de análise pode complementar os feeds de inteligência contra ameaças, mas as organizações ainda precisam validar como o serviço escolhido lida com detecção e exceções.
Criptografia e autenticidade não são a mesma coisa que uma decisão de segurança
O DNSSEC ajuda a verificar a integridade e a autenticidade dos dados de DNS assinados. O DNS over HTTPS (DoH) e o DNS over TLS (DoT) protegem as consultas de 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 equipes que estão revisando os controles em torno do acesso à web e serviços em nuvem, essa distinção pode andar lado a lado com orientações mais amplas sobre como proteger ambientes corporativos do Microsoft 365. O ponto principal é evitar tratar o transporte criptografado ou os dados autenticados como um substituto para uma decisão sobre o risco do destino.
Como funciona a aplicação de políticas em uma rede
Um resolvedor pode tomar uma decisão correta para uma única solicitação e ainda assim falhar em proteger uma rede se os dispositivos puderem desviar o DNS em torno dele. A implantação em toda a infraestrutura envolve duas coisas conectadas: uma política consistente e um caminho confiável até o resolvedor.
Um design centralizado envia solicitações de DNS de vários locais para um serviço gerenciado. Isso facilita a aplicação de regras compartilhadas e a revisão da atividade entre os locais. 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 do DNS podem falhar, mesmo quando o restante da rede estiver funcionando.
O serviço de DNS Protetivo do governo dos EUA tornou-se disponível para agências do Poder Executivo Civil Federal em setembro de 2022. Até agosto de 2024, mais de 104 agências haviam sido integradas, gerando uma média de 1,6 bilhão de consultas DNS seguras diariamente; o programa relatou 99,999% de tempo de atividade do resolvedor (folha informativa de DNS Protetivo da CISA). A lição operacional é que a qualidade da filtragem e a disponibilidade do serviço precisam ser avaliadas juntas.
Alique identidade sem multiplicar 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 prediais. O objetivo é adaptar a política ao usuário ou dispositivo, mantendo a administração gerenciável.
Os controles de acesso ajudam a estabelecer essa separação, enquanto o monitoramento do tráfego de rede pode ajudar as equipes a investigar atividades incomuns na rede. Para uma visão relacionada de como o controle de acesso à rede se encaixa em um ambiente gerenciado, consulte estas soluções de controle de acesso à rede.
Feche as rotas de desvio deliberadamente
Se um dispositivo puder enviar DNS comum diretamente para um resolvedor externo, o serviço de proteção pode nunca ver a solicitação. DoH e DoT criam outro desafio: a criptografia pode proteger as consultas em trânsito, mas um resolvedor não gerenciado também pode removê-las da política e da visibilidade organizacional.
Onde a aplicação for necessária, as equipes devem identificar caminhos diretos de DNS e destinos não autorizados de DNS criptografado, e então decidir como os controles de rede, endpoint e navegador irão lidá-los. Teste as exceções também. Captive Portals, dispositivos móveis, IPv6 e aplicativos com suas próprias configurações de resolvedor podem se comportar de maneira diferente de um notebook gerenciado em uma rede corporativa. A política funciona apenas 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 tornar a navegação perceptivelmente mais lenta. O impacto depende menos do ato de filtrar e mais de escolhas práticas de design: onde o resolvedor está localizado, como ele armazena respostas em cache, como ele mantém as conexões e se os dispositivos o ignoram.
O DNS criptografado pode adicionar tempo de configuração quando uma conexão precisa 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, multiplexação HTTP/2 e QUIC também podem reduzir a sobrecarga de conexão, de acordo com medições independentes de desempenho de DNS criptografado. Em condições de rede saudáveis, a latência de busca bruta pode ser insignificante, mas isso não é garantido para todos os clientes ou caminhos de rede.
Teste a busca, não apenas a impressão
Um resolver próximo e de alta disponibilidade, aliado a um cache em conformidade com os padrões, ajuda a manter as consultas comuns ágeis. Porém, um único número médio de latência pode ocultar experiências lentas para um subconjunto de usuários ou quando o resolver precisa buscar uma resposta que ainda não está em cache.
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 altos revelam casos mais lentos que podem afetar os usuários de forma mais severa. Mantenha a velocidade de consulta distinta do tempo de carregamento completo da página, já que o DNS é apenas uma parte da jornada do navegador.
Inclua as condições que expõem surpresas
Faça testes a partir dos tipos de redes e dispositivos que as pessoas utilizam, incluindo clientes móveis, IPv6 e Captive Portals. Verifique aplicativos e navegadores que possam selecionar seu próprio serviço DoH ou DoT, pois eles podem alterar tanto a rota quanto a visibilidade das solicitações de DNS.
Observou-se em medições distribuídas que o DoQ, DNS over QUIC, se aproxima do desempenho em texto claro e melhora alguns casos de carregamento de páginas em comparação ao DoH. Trate essas descobertas como um motivo para testar as opções de transporte em seu próprio ambiente, não como uma promessa de um resultado específico. O objetivo prático é um resolvedor próximo, cache eficiente, sessões criptografadas reutilizáveis e uma arquitetura que não deixe caminhos não gerenciados abertos.
Casos de uso reais em locais físicos e empresas
Uma implantação nacional mostra o que o DNS protetivo pode fazer quando muitas organizações compartilham uma camada de segurança gerenciada. No Reino Unido, o número de organizações que usam o serviço de Protective Domain Name System subiu de 944 para 1.173 em 2022, um aumento de 24%. Ao longo daquele ano, o serviço processou aproximadamente 0,55 trilhão de consultas DNS e bloqueou 11 bilhões de solicitações associadas a destinos maliciosos, cerca de 2% de todas as consultas (resumo do UK NCSC PDNS).
Essa escala ilustra o valor de tomar uma decisão antes que uma conexão seja tentada. Isso não prova que todas as solicitações bloqueadas teriam se tornado um incidente, nem que o DNS sozinho tenha interrompido todas as rotas para uma ameaça. Para um operador de múltiplos locais, a comparação útil é se o serviço pode aplicar políticas de forma consistente, gerar telemetria acionável e lidar com o volume e as exceções desse ambiente.
Considere como o mesmo ponto de verificação se adapta a diferentes locais:
- Hotéis e propriedades residenciais: Separe o acesso de hóspedes ou residentes dos dispositivos de funcionários e do edifício. Um Captive Portal, um dispositivo mais antigo ou o resolvedor criptografado preferido de um residente podem criar uma exceção que precisa ser planejada.
- Aeroportos e estádios: Aplique uma linha de base comum no acesso público de alta rotatividade, mantendo as redes operacionais e de funcionários distintas. Fique atento a dispositivos não gerenciados e necessidades de conectividade que exijam uma exceção documentada.
- Saúde e educação: Restrinja o acesso a destinos nocivos sem bloquear serviços legítimos usados para atendimento, ensino ou administração. Forneça um caminho de revisão claro quando uma política bloquear algo necessário para o trabalho.
- Varejo e shopping centers: Distinga o tráfego de visitantes de caixas, dispositivos de funcionários e outros equipamentos operacionais. Equipes de varejo que planejam o acesso de visitantes também podem achar estas soluções de WiFi para varejo úteis ao pensar em como o acesso e as políticas se conectam.
Uma breve introdução ao tópico também pode ajudar as equipes a se alinharem sobre o que a camada de DNS faz e o que ela não faz:
Em qualquer cenário, a filtragem de DNS é um controle parcial, não uma garantia de que todas as ameaças serão detidas. Um usuário pode alcançar a infraestrutura por meio de outro resolvedor ou por um endereço IP direto, e um aplicativo pode usar protocolos que não dependem do caminho de DNS da organização. A implantação precisa de tratamento de exceções e monitoramento ao lado da própria política.
Escolhendo a abordagem certa para sua rede
O DNS de proteção funciona no resolvedor. Agentes de endpoint, configurações de navegador e controles de rede operam em pontos diferentes, portanto as equipes geralmente escolhem uma combinação em vez de um único substituto. A combinação ideal depende de quem gerencia o dispositivo, de qual tráfego a rede pode ver e de como as exceções devem ser tratadas.
| Controle | Melhor Adequação | Visibilidade | Limitação Comum |
|---|---|---|---|
| DNS Protegido | Redes compartilhadas, ambientes gerenciados e aplicação de políticas de DNS | Solicitações de DNS que passam pelo resolvedor | Resolvedores não gerenciados e caminhos fora do DNS podem ignorá-lo |
| Agente de endpoint | Laptops e dispositivos móveis gerenciados que precisam de proteção fora da rede | Atividade visível para o agente instalado | A cobertura depende da instalação, integridade e gerenciamento do agente |
| Política de navegador | Navegadores gerenciados onde as configurações de resolvedor e navegação podem ser governadas | Configuração do navegador e atividades selecionadas no navegador | Não governa todos os aplicativos ou navegadores não gerenciados |
| Controles em nível de rede | Redes segmentadas e tráfego que passa por infraestrutura gerenciada | Fluxos de rede dentro da cobertura do controle | Tráfego criptografado ou fora da rede pode limitar a inspeção |
| Controles de identidade e acesso | Funcionários, convidados, residentes e grupos de dispositivos com necessidades de acesso distintas | Decisões de conexão e acesso vinculadas à identidade ou segmento | Uma conexão permitida não julga, por si só, cada destino |
Para laptops gerenciados, os controles de endpoint e do navegador podem complementar a política do resolvedor, principalmente quando os funcionários trabalham fora do escritório. O WiFi para convidados e o BYOD são mais difíceis de gerenciar com agentes, tornando os controles no nível da rede mais práticos, desde que a organização possa direcionar o DNS para o serviço escolhido. Dispositivos IoT e residenciais geralmente precisam de segmentação e de uma política que considere as opções limitadas de gerenciamento de dispositivos.
Para equipes que comparam identidade de rede, filtragem e verificações voltadas ao usuário, as verificações gratuitas de DNS e e-mail da mailX podem ser um recurso relevante, juntamente com uma análise mais ampla dos controles de acesso. Se ambientes de pagamento fizerem parte da infraestrutura, considere também como o projeto 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 baseada em identidade. O Purple Shield adiciona DNS protetivo e filtragem de conteúdo com controles por política. Esses recursos podem funcionar junto com controles de endpoint e navegador, mas não eliminam a necessidade de definir imposição de resolvedor, exceções e monitoramento. Escolha as ferramentas de acordo com os caminhos e dispositivos que você precisa proteger e, em seguida, verifique se suas políticas funcionam juntas.
Medindo o valor do DNS protetivo além da contagem de bloqueios
O total de consultas bloqueadas indica que o resolver agiu. Por si só, ele não informa se foram capturadas as solicitações corretas, se o trabalho útil foi interrompido ou se passou tráfego que tomou outra rota. Conte a decisão, mas meça o controle.
O workshop de DNS da European Internet Industry Association relatou 2,3 milhões de relatórios de abuso cobrindo 780.000 domínios exclusivos durante os seis meses anteriores, com relatórios mensais subindo de 220.000 para 380.000 (relatório do workshop). Esses números mostram a escala do abuso relatado. Eles não estabelecem quantos incidentes um resolvedor evitou, se um bloqueio foi correto ou se o tráfego afetado atingiu um destino por meio de uma VPN, um resolvedor alternativo, um endereço IP codificado ou um protocolo de aplicação criptografado.
Crie um scorecard baseado em resultados e exceções
Uma análise útil combina segurança, qualidade de serviço e resposta operacional. Acompanhe se o resolvedor detectou domínios maliciosos conhecidos, a rapidez com que as equipes lidam com recursos de falsos positivos e se as alterações de política chegam aos locais pretendidos prontamente. Combine essas medidas com a disponibilidade do resolvedor e a latência de consulta mediana e de cauda.
Também meça as tentativas de bypass. Um número baixo de solicitações bloqueadas pode significar que o ambiente tem pouca atividade maliciosa, ou pode significar que os dispositivos não estão usando o resolvedor de proteção. Correlacione eventos relevantes com a identidade da rede, como um SSID, VLAN, local ou grupo de usuários, para que os investigadores possam ver onde uma política se aplica e onde uma exceção pode estar oculta. Compare a atividade de DNS com dados de endpoint ou de incidentes em vez de alegar que cada consulta bloqueada representa um incidente evitado.
Trate os logs de DNS como dados operacionais sensíveis
Os logs de DNS podem revelar padrões de navegação, o que exige cuidado em ambientes de saúde, educação, hospitalidade 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 quais dados precisa antes de coletar logs em escala.
Próximos passos para planejar a implantação do seu Protective DNS
Comece pelo caminho, não pelo painel. Mapeie quais dispositivos usam o resolvedor gerenciado, identifique onde o DNS direto ou o DNS criptografado não autorizado poderiam desviá-lo e decida como a aplicação funcionará para dispositivos que a organização não gerencia. Inclua um processo de exceção para serviços legítimos que uma política bloqueie.
Antes da implementação, defina como a equipe avaliará tanto a segurança quanto a qualidade do serviço:
- Confirme o uso do resolvedor: Verifique dispositivos gerenciados, redes de convidados e dispositivos menos previsíveis, como IoT.
- Teste o caminho de rede: Onde a aplicação for necessária, revise rotas diretas de DNS e rotas não autorizadas de DNS criptografado.
- Meça o desempenho: Compare a latência de busca em cache frio e quente, incluindo percentis mais lentos.
- Defina o scorecard: Acompanhe a gestão de falsos positivos, disponibilidade, propagação de políticas, tentativas de bypass e resultados de incidentes.
- Defina regras de privacidade: Estabeleça limites de acesso a logs e retenção antes do início da coleta ampla.
Para uma implantação em múltiplos locais, reúna as equipes de rede e segurança para mapear identidades, segmentos de rede, rotas de resolvedores e as exceções que cada local precisa. A Purple oferece sessões de design lideradas por engenheiros de rede para moldar e validar planos de implantação. O DNS de proteção pode tornar os destinos nocivos mais difíceis de alcançar por meio do caminho de consulta gerenciado, mas não substituirá a segurança de endpoint, a segmentação de rede ou a governança de privacidade.
O Purple Access oferece suporte a redes WiFi abertas, seguras e xPSK, com atribuição de rede baseada em identidade e integração de visitantes ou BYOD nos pontos de acesso existentes. Para planejar como esses controles de acesso podem funcionar junto com o DNS de proteção em todos os seus locais, visite Purple Access.
