Ir para o conteúdo principal
Capacidade

DNS Firewall & Application Delivery Controller

Acelere o tráfego DNS empresarial e bloqueie consultas maliciosas — em uma única camada.

O DNS é onde toda aplicação moderna começa. Toda sessão, chamada de API e conexão remota começa com uma consulta DNS — e ainda assim, na maioria das empresas, a camada DNS continua sendo um único servidor, sem monitoramento e diretamente exposta ao mundo externo. O TR7 DNS Firewall and Application Delivery Controller fecha essa lacuna nos eixos de desempenho e segurança: as consultas DNS são distribuídas entre múltiplos resolvers de backend com algoritmos inteligentes; servidores não saudáveis são retirados da rotação em segundos por health checks ativos; registros frequentemente solicitados são cacheados próximos ao cliente; os transportes modernos DoT / DoH / DoQ são terminados no gateway. A mesma camada aplica regras de firewall DNS — bloqueando consultas maliciosas, detectando padrões de Domain Generation Algorithm (DGA), mitigando exfiltração via DNS e ataques de amplificação, e aplicando políticas geográficas, por IP e baseadas em taxa a partir de um único motor de regras. Na arquitetura da plataforma TR7, essa camada veste duas identidades ao mesmo tempo: estende a filosofia de balanceamento de carga do TR7 ADC ao protocolo DNS e amplia a abordagem de política de segurança do TR7 WAAP ao fluxo DNS.

5
Algoritmos de balanceamento de carga afinados para cargas DNS
5
Transportes DNS cifrados terminados — DoT, DoH, DoH3, DoQ, DNSCrypt
11+
Tipos de ação de firewall — block, drop, refuse, spoof, route, tag e mais

O DNS é a camada de segurança e desempenho mais negligenciada da empresa.

A maioria das organizações passa anos afinando sua estratégia de balanceamento de HTTP e construindo proteção WAAP profunda para tráfego web, mas ainda trata sua infraestrutura DNS como um único servidor recursivo com um IP estático. Esse único servidor se torna ao mesmo tempo um gargalo de desempenho e um alvo de ataque de alto valor.

Do lado do desempenho, uma camada DNS lenta empurra latência para dentro de toda transação voltada ao usuário. Sem o devido balanceamento de carga, um resolver saturado atrasa toda consulta downstream — e clusters DNS tradicionais baseados em anycast são difíceis de gerenciar em data centers privados onde se exige controle on-prem.

Do lado da segurança, os atacantes sabem que o DNS raramente é inspecionado. Ferramentas de tunelamento DNS extraem gigabytes de dados por meio de registros TXT de aparência inocente; malware com DGA contata milhares de domínios gerados aleatoriamente em busca de comando-e-controle; campanhas de amplificação DNS abusam de resolvers abertos como vetores de reflexão; e clientes stub em redes de convidados consultam qualquer resolver upstream que escolherem, contornando todos os outros controles de segurança que a organização instalou.

O TR7 DNS Firewall and Application Delivery Controller trata o DNS como um protocolo de aplicação de primeira classe que merece o mesmo balanceamento de carga, gerenciamento de saúde, cache e aplicação de política de segurança que os serviços HTTP já recebem.

Nossa abordagem

O TR7 trata o DNS como um protocolo de aplicação de primeira classe: as consultas recebem balanceamento de carga completo e entrega ciente de saúde pelo lado do ADC, e passam por um motor de política pelo lado do WAAP — sem sair do mesmo gateway.

Balanceamento de carga inteligente entre backends DNS

Múltiplos algoritmos — round-robin, least-outstanding, hash consistente, aleatório ponderado e hash ponderado — distribuem consultas DNS entre pools de resolvers ou autoritativos. Cada algoritmo é casado com a carga: round-robin para pools simétricos, least-outstanding para tempos variáveis de resposta de backend, hash consistente para cenários de afinidade de cache.

Monitoramento ativo de saúde mantém o caminho DNS saudável

Health checks configuráveis sondam continuamente os backends DNS — checks de consulta UDP, checks de consulta TCP, checks customizados de resolução de nome. Servidores não saudáveis saem da rotação em segundos; a recuperação os traz de volta automaticamente. O mesmo modelo de saúde que o resto do TR7 usa para pools HTTP se aplica a pools DNS.

Regras de firewall DNS aplicam política de segurança em cada consulta

Casamento por regra em nome de consulta, tipo de consulta, IP de origem, opções EDNS, expressões regulares e combinações destes. As ações incluem block, drop, refuse, truncate, spoof de uma resposta controlada, rota para um pool diferente ou marcar a consulta para inspeção downstream. A política é avaliada antes que a consulta seja enviada a qualquer backend.

Rate limiting no nível DNS e bloqueio dinâmico

Limites de taxa podem ser aplicados por IP de origem, por nome de consulta, por tipo de consulta ou por dimensão combinada. Bloqueios dinâmicos ativam-se automaticamente quando padrões de tráfego cruzam limiares definidos pelo operador — uma única origem inundando o gateway com consultas NXDOMAIN é desacelerada ou temporariamente bloqueada sem intervenção do operador.

Capacidades

O TR7 DNS Firewall and Application Delivery Controller leva toda a filosofia de gerenciamento de tráfego do TR7 — balanceamento, health checks, cache, política e observabilidade — ao protocolo DNS.

Cinco algoritmos de balanceamento de carga afinados para cargas DNS

Round-robin para pools uniformes, least-outstanding para backends com tempo de resposta variável, hash consistente e hash ponderado para cenários de afinidade de cache onde a mesma consulta deve atingir o mesmo backend, e aleatório ponderado para deslocamentos graduais de tráfego. Cada vService escolhe seu próprio algoritmo; algoritmos podem ser alterados ao vivo sem reinício.

Resolução recursiva a partir da raiz, com validação DNSSEC

O resolver percorre a cadeia sozinho e valida as assinaturas do que volta, por isso uma resposta forjada quebra antes de entrar em cache. Regido por lista de acesso; um perfil só-encaminhamento cobre redes sem saída para a internet.

Zonas de política de resposta alimentadas ao vivo por AXFR/IXFR

A threat intelligence chega como zona DNS e atualiza-se em minutos sem reiniciar. Dispara pelo nome consultado, pelo cliente, pelo endereço devolvido ou pelo servidor de nomes por trás da zona — e uma fonte que deixa de atualizar gera alarme em vez de ser servida desatualizada.

Cinco transportes cifrados terminados no equipamento

Do53, DoT, DoH, DoH sobre HTTP/3 e DNS over QUIC, além de DNSCrypt. Uma frase num caderno de encargos — «as consultas devem ser aceites por DNS over QUIC» — e o campo reduz-se a uma única plataforma.

Pools de servidores roteiam diferentes categorias de consulta para diferentes backends

Domínios corporativos internos podem resolver por um pool, domínios públicos por outro, zonas de parceiros por um terceiro. Regras de roteamento por pool direcionam consultas com base em padrões de QName, faixas de IP de origem ou tags de política casadas. O mesmo gateway serve múltiplas arquiteturas DNS de forma limpa.

Health checks ativos com múltiplos tipos de sonda

Sondas DNS de consulta TCP e UDP, sondas customizadas de resolução de nome e checks baseados em tempo de resposta verificam continuamente a saúde do backend. Parâmetros de limiar definem quantos checks falhos disparam a remoção e quantos sucessos reinstauram um backend. Backends lentos podem ser removidos mesmo quando respondem — evitando latência visível ao usuário.

Cache de pacote reduz a carga no backend e acelera a resposta

Registros frequentemente solicitados são cacheados no gateway com invalidação ciente de TTL. O cache respeita DNSSEC quando aplicável e pode ser ignorado seletivamente para zonas sensíveis. A taxa de cache hit é exposta em métricas em tempo real para que os operadores vejam exatamente quanta carga o gateway absorve.

Casamento por regra entre QName, QType, IP de origem e EDNS

As regras de firewall casam por qualquer combinação de nome de consulta (exato, sufixo, regex), tipo de consulta (A, AAAA, TXT, MX, ANY, etc.), IP de origem, EDNS Client Subnet, opções EDNS e flags de requisição. As condições podem ser combinadas com lógica AND/OR. As regras são avaliadas na ordem definida pelo operador com semântica explícita de allow/deny.

Conjunto de ações cobre block, drop, refuse, truncate, spoof e rota

Block retorna um erro controlado; drop descarta silenciosamente; refuse retorna REFUSED; truncate força fallback para TCP (útil contra amplificação); spoof retorna uma resposta controlada (bloquear com NXDOMAIN, redirecionar para um sinkhole, retornar uma alternativa segura); route envia a consulta para um pool diferente. Ações de tag marcam consultas para inspeção downstream sem alterar a resposta.

Detecção de DGA e tunelamento DNS

Detecção baseada em padrões e estatística identifica consultas a domínios gerados algoritmicamente (C2 de malware DGA) e cargas TXT/CNAME incomuns características de exfiltração de dados via DNS. Consultas detectadas podem ser bloqueadas, sinkholed ou somente registradas para revisão do analista.

Mitigação de ataques de amplificação no gateway

Ataques de amplificação DNS abusam de resolvers abertos para inundar alvos com tráfego refletido. O TR7 detecta consultas ANY, padrões de respostas grandes e indicadores de spoofing de origem, aplicando rate limiting de resposta e ações de validação de origem antes que qualquer reflexão chegue à rede. O gateway nunca se torna um vetor de amplificação.

Políticas de controle geográfico, por ASN e acesso

As consultas podem ser avaliadas por país de origem, ASN, faixa de IP ou janela de tempo. Políticas de block-list, allow-list e ação condicional se aplicam na camada DNS da mesma forma que se aplicam na camada HTTP no TR7 WAAP — usando o mesmo editor de política e o mesmo modelo de aplicação.

Suporte a transportes DNS modernos — DoT, DoH, DoQ

DNS over TLS (DoT, RFC 7858), DNS over HTTPS (DoH, RFC 8484) e DNS over QUIC (DoQ, RFC 9250) são terminados no gateway. O gerenciamento de certificados usa o mesmo certificate store do TR7 que os serviços HTTP. Resolvers stub modernos e clientes DoH de navegador conectam nativamente.

Tratamento de EDNS Client Subnet (ECS)

Informações ECS passadas por resolvers downstream podem ser respeitadas, sobrescritas, mascaradas para um prefixo que preserva privacidade ou removidas inteiramente. O comportamento é por política, permitindo conformidade de privacidade para alguns fluxos enquanto preserva precisão geográfica para outros.

Logging estruturado e métricas em tempo real

Toda consulta, decisão e ação é escrita em um stream de log estruturado com formatação compatível com SIEM. Métricas em tempo real expõem taxa de consultas, tempo de resposta, taxa de cache hit, saúde de backend e contadores de match de regra. Os operadores enxergam o tráfego DNS com a mesma profundidade de observabilidade que o resto do TR7 oferece para HTTP.

Métricas de consultas por zona e por registo, com distribuição de RCODE

O DNS é medido, não presumido: contagens de consultas por zona e por registo, distribuições por tipo de consulta e código de resposta (RCODE), visibilidade de acertos e falhas de cache, e histórico de verificações de integridade com registos de eventos de failover. Um aumento de SERVFAIL ou NXDOMAIN passa a ser um número num painel em vez de uma chamada para o suporte.

Profundidade operacional

O DNS Firewall and Application Delivery Controller é operado em conjunto com a ordenação de regras, topologia de pool, ajuste de cache, escolha de protocolo de transporte e retenção de auditoria.

01

Ordem de avaliação das regras e semântica explícita

As regras de firewall são avaliadas de cima para baixo com first-match-wins por padrão. Tags por regra permitem que regras downstream ajam de forma diferente com base em casamentos anteriores. Regras allow explícitas no topo da cadeia fixam tráfego conhecidamente bom antes que regras genéricas de block se apliquem, eliminando falsos positivos em produção.

02

Topologia e seleção de pools

Pools de backend agrupam resolvers por propósito: interno corporativo, recursão pública, zonas de parceiros, pool de sinkhole. Regras de roteamento por pool direcionam consultas com base em QName, IP de origem ou tags casadas. Limiares de failover de pool impedem que um único backend não saudável absorva todo o tráfego.

03

Ajuste do cache de pacote

Tamanho de cache, comportamento de TTL, cache ciente de ECS e bypass seletivo para zonas sensíveis são todos controlados pelo operador. O cache de resposta negativa (NXDOMAIN, NODATA) reduz a carga de backend para cargas com alta taxa de NX típicas de redes infectadas com DGA.

04

Seleção de protocolo de transporte

DNS UDP/TCP simples, DoT, DoH e DoQ podem ser habilitados por listener vService. Clientes modernos negociam seu transporte preferido; clientes mais antigos fazem fallback para UDP. Políticas de certificado e cifra alinham-se ao pool central de perfis TLS do TR7.

05

Retenção de auditoria e streaming para SIEM

Registros de auditoria por consulta podem ser retidos por janelas de compliance; amostragem pode ser aplicada em ambientes de alto volume. Logs JSON estruturados fazem stream diretamente para o SIEM. Os operadores escolhem entre retenção completa, retenção por amostragem e retenção apenas de eventos por pool.

06

Comportamento de alta disponibilidade

As sessões DNS são stateless no nível do protocolo, então o failover entre nós ativos é transparente para a maioria das consultas. Sessões DNS TCP e conexões DoH longas são coordenadas entre o par HA para minimizar a disrupção. O estado de health check e o estado de cache são gerenciados independentemente por nó.

DNS DE PONTA A PONTA

Cinco transportes cifrados, três modos de resolução, um motor de políticas

A consulta chega cifrada, é resolvida no modo que você escolheu e é respondida sob uma política legível. <b>DNS over QUIC é terminado aqui — nenhuma plataforma concorrente de entrega de aplicações o termina.</b>

Transportes cifrados — terminados no equipamento

Do53 — DNS clássico sobre UDP e TCP
DoT — DNS over TLS na 853
DoH — DNS over HTTPS
DoH3 — DNS sobre HTTP/3
DoQ — DNS over QUIC, RFC 9250
DNSCrypt — para ambientes já padronizados nele

Resolução — autoritativa, recursiva, de encaminhamento

Autoritativa — zonas ilimitadas num único endereço de escuta, 35 tipos de registo
Recursiva a partir da raiz — e cada resposta é validada por DNSSEC antes de sair
Regida por lista de acesso — o resolver serve apenas as redes previstas, nunca aberto
Perfil só-encaminhamento — sem saída para a internet, o mesmo serviço encaminha para os upstreams em que já confia
Cache com visibilidade — distribuição de acertos e falhas no ecrã, limpeza num clique
O papel é uma escolha explícita — não um efeito colateral da localização

Política — zonas de política de resposta e ações de firewall

RPZ por AXFR/IXFR — uma fonte comercial ou nacional aplica-se em minutos, sem reiniciar
Cinco tipos de gatilho — o nome consultado, o endereço do cliente, o endereço devolvido, o servidor de nomes por trás da zona e o seu endereço
Desative uma infraestrutura, não um domínio — um gatilho por servidor de nomes cobre todos os domínios por trás, mesmo que rodem
Ações — recusar, devolver vazio, descartar, forçar TCP ou responder com um endereço controlado (walled garden)
Os seus próprios nomes ficam protegidos — uma zona de passagem com prioridade máxima impede que uma fonte externa derrube o seu serviço
Uma fonte desatualizada gera alarme — nunca é servida em silêncio como se estivesse atual

Quando usar

Endurecimento de DNS interno empresarial

Resolvers corporativos que servem a rede interna ganham rate limiting, filtragem de consultas, logging de auditoria e alta disponibilidade. Endpoints não conseguem mais consultar resolvers externos arbitrários; hosts infectados com DGA são detectados e bloqueados no gateway.

Proteção de resolver recursivo voltado ao público

Organizações que operam serviços DNS públicos — ISPs, provedores de hospedagem, portais do setor público — terminam ataques de amplificação no gateway. Rate limiting, validação de origem e checks de padrão de resposta evitam que o resolver seja abusado como vetor de reflexão.

Prevenção de exfiltração de dados via DNS

Redes de saúde, financeiras e governamentais adicionam uma camada de detecção para exfiltração baseada em registros TXT e técnicas de tunelamento. Fluxos suspeitos são sinkholed ou registrados com contexto de sessão completo para revisão do analista.

Front-line autoritativo de DNS para o TR7 GTM

Quando o TR7 GTM serve DNS autoritativo para aplicações multi-região, o DNS Firewall and Application Delivery Controller fica à frente do GTM como camada de rate limiting, cache e firewall. O GTM permanece focado na inteligência de roteamento; o gateway absorve o tráfego hostil.

Perguntas frequentes

Isso é a mesma coisa que o TR7 GTM?
Não. O TR7 GTM é um serviço de DNS autoritativo — você hospeda sua zona nele e ele responde consultas sobre seus próprios domínios com lógica de roteamento inteligente. O TR7 DNS Firewall and Application Delivery Controller é um proxy e gateway de segurança que fica à frente de backends DNS (sejam resolvers recursivos, servidores autoritativos ou o próprio TR7 GTM) e adiciona balanceamento de carga, cache, regras de firewall, rate limiting e suporte a transportes modernos. Os dois se complementam: o GTM fornece inteligência de roteamento autoritativo, o DNS Firewall and Application Delivery Controller fornece entrega e proteção na camada DNS.
Quais transportes DNS são suportados?
DNS simples sobre UDP e TCP (RFC 1035), DNS over TLS (DoT, RFC 7858), DNS over HTTPS (DoH, RFC 8484) e DNS over QUIC (DoQ, RFC 9250). O gerenciamento de certificados para transportes baseados em TLS usa o mesmo certificate store do TR7 que os serviços HTTP. Resolvers stub modernos e clientes DoH do lado do navegador conectam nativamente.
Como isso protege contra malware DGA?
Algoritmos de geração de domínio produzem milhares de nomes de domínio de aparência aleatória para que o malware possa localizar a infraestrutura de comando-e-controle. Detecção baseada em padrões e estatística identifica essas consultas — labels curtos randomizados, distribuições incomuns de caracteres, altas taxas de NXDOMAIN de uma única origem. As consultas detectadas são bloqueadas, sinkholed para um host controlado ou somente registradas para revisão do analista conforme a política.
O gateway pode se tornar um vetor de amplificação?
Não. O gateway aplica rate limiting de resposta (por IP de origem e por nome de consulta), validação de origem, throttling de consultas ANY e bloqueio de origens conhecidamente más antes que qualquer resposta grande seja refletida. Os operadores também podem aplicar políticas de tamanho mínimo de resposta e exigir TCP para consultas que historicamente sinalizem padrões de amplificação. O gateway é desenhado para absorver tentativas de amplificação, não para amplificá-las.
Podemos cachear respostas assinadas com DNSSEC?
Sim. O cache de pacote é ciente de DNSSEC e respeita os TTLs de RRSIG. Os operadores podem ignorar seletivamente o cache para zonas onde a atualidade importa mais que o desempenho, ainda cacheando a maior parte das consultas de alto volume para cargas típicas.
Como isso funciona ao lado do TR7 ADC e do TR7 WAAP?
Usa o mesmo modelo de vService, as mesmas definições de pool de backend, a mesma infraestrutura de health check e o mesmo editor de política que o ADC e o WAAP usam. A configuração é consistente em toda a plataforma — os operadores não precisam aprender uma ferramenta separada específica para DNS. Como capacidade, é reconhecido tanto pelo ADC (lado da entrega: balanceamento, cache, transportes modernos) quanto pelo WAAP (lado da segurança: regras de firewall, rate limiting, mitigação de amplificação).

Traga o DNS para a mesma camada de entrega e proteção que seu tráfego HTTP

Balanceamento de carga inteligente, health checks ativos, transportes modernos e um motor completo de regras de firewall — tudo em um único gateway. Vamos mostrar uma configuração ao vivo na sua infraestrutura DNS.