Por trás do seu navegador, por mais que muitas vezes nos esqueçamos, existe uma infraestrutura gigantesca dedicada a fazer com que o site que você acessa apareça corretamente na tela do seu computador ou do seu celular. No entanto, um recurso específico do Chromium, base do Chrome, do novo Edge, Opera e tantos outros menos conhecidos, está causando um stress excessivo em parte desta estrutura, responsável pela resolução de DNS.

O DNS é fundamental para uso da internet por humanos. Ele funciona como um “catálogo” de internet, permitindo traduzir endereços IP difíceis de decorar em URLs amigáveis, como dev.olhardigital.com.br. Este sistema é hierarquizado: a maioria das requisições são resolvidas nos níveis mais básicos do DNS, normalmente oferecidos diretamente pela sua operadora de internet, e pouquíssimas acabam chegando à raiz, o último nível, utilizado apenas quando os anteriores não conseguiram chegar ao resultado.

No entanto, a omnibox do Chrome e dos outros navegadores, tem feito com que essa hierarquia seja rompida. De fato, mais da metade das requisições que chegam até esse núcleo vêm dos browsers que utilizam o Chromium, como relata a Verisign, empresa de segurança de redes que fornece um serviço de servidor raiz de DNS.

Mas o que está acontecendo? A omnibox é a barra de endereços do navegador, mas também é uma barra de buscas, o que cria uma situação nova. O Chrome precisa identificar o que são termos de busca e o que é um endereço de internet, o que é um endereço de intranet e, ainda por cima, evitar que o usuário seja direcionado para uma página de endereço inexistente que tenha sido “sequestrada” por uma operadora para exibição de anúncios.

O que acontece? O Google gera três domínios aleatórios, que deveriam incorrer em exibição de uma página de erro e faz com que sejam verificados com o servidor de DNS. Se dois desses endereços retornarem uma mesma página, significa que o tráfego está sendo “sequestrado” para que outra página seja exibida no lugar da confirmação de endereço incorreto. É uma forma que o navegador tem de descobrir se esse redirecionamento está ocorrendo de forma indevida.

Por exemplo: o Chrome pode checar termos como “kxgdkjxlk”, “pzsjcfmnskhb” e “sjdhcvbndk”. Se dois desses endereços (digitados aleatoriamente de olhos fechados) que obviamente não existem retornarem exatamente o mesmo IP em vez de um erro, significa que o tráfego do usuário está sendo redirecionado.

No entanto, em redes em que não há esse redirecionamento, o navegador acaba gerando sobrecarga sobre o sistema de DNS. Isso porque o servidor de nível mais baixo não sabe o que é “bxalynz” e, devido à hierarquização, passa a requisição para o próximo degrau. Como não existe nenhum endereço “bxalynz”, essa requisição é passada adiante até bater na raiz, que finalmente oferece uma resposta de que não existe nenhum site, gerando a mensagem de erro.

Reprodução

A questão preocupa. Matthew Thomas, engenheiro da Verisign, conta no blog do Centro de Informação Ásia-Pacífico que nos últimos 10 anos, em que este recurso está ativo no Chromium, metade do tráfego em servidores de DNS de raiz já é dedicado a alimentar essa função, que nem é tão importante. A interceptação de DNS “é a exceção, e não a norma”, ele diz, o que faz com que essa carga seja referente a um recurso com pouca utilidade prática.

Os desenvolvedores do Chromium já estão atentos à questão. Na plataforma de discussão já há um chamado aberto para que o recurso de detecção de redirecionamento seja desativado como padrão para evitar que esse tipo de carga seja evitado. O tema foi levantado em junho, antes mesmo de Thomas chamar a atenção publicamente para o caso, mas agora tem recebido atenção diária.