AWS lança Route 53 Resolved IP Validation para o Network Firewall e permite filtrar tráfego não web por domínio

O problema que a AWS ataca é de visibilidade. Em HTTP e HTTPS, as regras de domínio do Network Firewall comparam o nome que o cliente coloca na requisição, e é o próprio cliente quem escolhe esse nome. Em SSH e SFTP, o nome só aparece na consulta DNS, e a conexão seguinte vai direto ao IP. Por isso as regras desses protocolos viviam de listas de IP, que mudam. Até agora o firewall também não via o que o resolvedor DNS respondia.

Com o Route 53 Resolved IP Validation, lançado em 21 de outubro de 2026 sem custo adicional, o Route 53 Resolver mantém um resolved IP cache com os IPs devolvidos para cada domínio. No primeiro pacote de cada nova conexão, antes das regras stateful, o firewall confere se o destino está nesse cache. Se não estiver, aplica Alert, Drop ou Reject. Isso permite filtrar tráfego não web por domínio e barrar manipulação de SNI em TLS sem ativar a inspeção de TLS.

Há pontos operacionais que pesam. A checagem vale para todas as conexões, não só web. Um IP fixo no código, que nenhum cliente resolveu via Route 53 Resolver, falha na verificação e precisa entrar em Bypass destination validation IP ranges, porque uma regra pass não o isenta. A verificação é por endereço: se qualquer cliente de uma VPC associada resolve um nome, os IPs passam para todos os clientes no escopo da mesma Availability Zone. Se o roteamento mandar o cliente para um endpoint de outra zona, a conexão falha. O recurso funciona em implantações distribuídas e em centralizadas com o firewall anexado nativamente ao Transit Gateway.

A recomendação da AWS é começar em modo alerta e esperar cerca de 24 horas, porque clientes guardam respostas DNS em cache e falham até renovar o registro. No modo alerta nada é bloqueado e o resultado vai para o campo route53_resolved_ip dos flow logs. As métricas DnsUnresolvedFlows e DnsAzUnavailableFlows no CloudWatch ajudam a medir o impacto antes de aplicar Drop ou Reject. Depois do enforcement, os bloqueios aparecem nos flow logs com o campo em false, não nos alert logs.

Um detalhe sobre o SNI: a regra pass confere o IP de destino, não o nome na requisição TLS. Se os mesmos IPs servem outros domínios, como atrás de uma CDN, esses nomes também passam. Para exigir o nome do parceiro, a AWS sugere somar um match exato de SNI, com startswith e endswith. O cache também guarda respostas antigas por mais tempo que o TTL do DNS, então um IP antigo pode continuar passando por um tempo.

Para quem opera egress em AWS, isso pode trocar listas de IP de parceiros, difíceis de manter, por regras por domínio em SFTP e SSH. Também oferece uma defesa contra SNI spoofing mais barata que decriptar tráfego. A leitura prática é que o risco maior está na migração: IPs hardcoded e clientes com DNS em cache podem gerar bloqueios inesperados. O modo alerta existe para isso.