Um dos recursos do Chromium sobrecarrega os servidores DNS raiz.





O navegador Chromium, o pai de código aberto em rápida expansão do Google Chrome e do novo Microsoft Edge, recebeu muita atenção negativa por um recurso bem-intencionado que verifica se o ISP do usuário está roubando resultados de consulta de domínio inexistentes.



O Intranet Redirect Detector , que cria consultas falsas para "domínios" aleatórios cuja existência é estatisticamente improvável, é responsável por cerca de metade do tráfego total recebido pelos servidores DNS raiz em todo o mundo. O engenheiro da Verisign Matt Thomas escreveu uma longa postagem no blog do APNIC descrevendo o problema e avaliando sua escala.





Como as pesquisas de DNS geralmente são feitas





Esses servidores são a autoridade máxima a ser contatada para resolver .com, .net e assim por diante, para que digam que frglxrtmpuf não é um domínio de nível superior (TLD).



DNS, ou Domain Name System, é um sistema pelo qual os computadores podem traduzir nomes de domínio memoráveis ​​como arstechnica.com em endereços IP muito menos convenientes, como 3.128.236.93. Sem o DNS, a Internet não poderia existir em uma forma amigável para humanos, o que significa que a carga desnecessária na infraestrutura de nível superior é um problema real.



Pode levar uma quantidade inimaginável de pesquisas de DNS para carregar uma única página da web moderna. Por exemplo, quando analisamos a página inicial da ESPN, contamos 93 nomes de domínio separados, variando de a.espncdn.com a z.motads.com. Todos eles são necessários para um carregamento de página completo!



O DNS foi projetado como uma hierarquia de vários níveis para lidar com esse tipo de carga de trabalho que precisa servir ao mundo inteiro. No topo dessa pirâmide estão os servidores raiz - cada domínio de nível superior, como .com, tem sua própria família de servidores, que são a autoridade final para cada domínio abaixo deles. Um degrau acima desses servidores estão os próprios servidores raiz, de a.root-servers.neta m.root-servers.net.



Com que frequência isso acontece?



Devido à hierarquia de cache em camadas da infraestrutura DNS, uma porcentagem muito pequena das consultas DNS do mundo chega aos servidores raiz. A maioria das pessoas obtém as informações do resolvedor DNS diretamente do ISP. Quando o dispositivo de um usuário precisa saber como chegar a um site específico, uma solicitação é enviada primeiro a um servidor DNS gerenciado por esse provedor local. Se o servidor DNS local não souber a resposta, ele encaminhará a solicitação para seus próprios "encaminhadores" (se especificado).



Se nem o servidor DNS do ISP local nem seus “encaminhadores” configurados tiverem uma resposta em cache, a solicitação será roteada diretamente para o servidor autoritativo no domínio acima daquele que você está tentando resolver . Quando.comisso significa que a solicitação é enviada aos servidores autorizados do próprio domínio com, que estão localizados no endereço gtld-servers.net.



O sistema gtld-serverspara o qual a solicitação foi feita responde com uma lista de servidores de nomes autorizados para o domínio domain.com, bem como pelo menos um registro de cola contendo o endereço IP de um desses servidores de nomes. Em seguida, as respostas descem na cadeia - cada encaminhador passa essas respostas para o servidor que as solicitou, até que a resposta finalmente chegue ao servidor do provedor local e ao computador do usuário. Ao mesmo tempo, todos eles armazenam em cache essa resposta para não perturbar desnecessariamente os sistemas de nível superior.



Na maioria dos casos, os registros do servidor de nomes para dominio.comjá estará em cache em um desses encaminhadores, para que os servidores raiz não sejam perturbados. No entanto, por enquanto, estamos falando sobre a forma usual de um URL - aquele que é convertido em um site normal. As consultas do Chrome estão em um nível acima disso, na linha dos próprios clusters root-servers.net.



Verificação de roubo de cromo e NXDomain





O Chromium verifica "Este servidor DNS está me enganando?" responsável por quase metade de todo o tráfego que chega ao cluster de servidores raiz DNS da Verisign.



O navegador Chromium, o projeto pai do Google Chrome, o novo Microsoft Edge e inúmeros navegadores menos conhecidos, deseja fornecer aos usuários a facilidade de pesquisa em um único campo, às vezes referido como "Omnibox". Em outras palavras, o usuário insere URLs reais e consultas de mecanismo de pesquisa na mesma caixa de texto na parte superior da janela do navegador. Indo um passo adiante em direção à simplificação, também não força o usuário a inserir parte da URL com http://ou https://.



Por mais conveniente que seja, essa abordagem exige que o navegador entenda o que deve ser considerado um URL e o que é uma consulta de pesquisa. Na maioria dos casos, isso é bastante óbvio - por exemplo, uma string com espaços não pode ser um URL. Mas as coisas podem ficar mais complicadas quando você considera as intranets - redes privadas que também podem usar domínios de nível superior privados para resolver sites reais.



Se um usuário inserir "marketing" na intranet da empresa e a intranet da empresa tiver um site interno com o mesmo nome, o Chromium exibe uma caixa de informações perguntando ao usuário se deseja pesquisar "marketing" ou ir parahttps://marketing... Está tudo bem, mas muitos ISPs e provedores públicos de Wi-Fi “sequestram” cada URL com erros ortográficos, redirecionando o usuário para uma página cheia de anúncios em banner.



Geração aleatória



Os desenvolvedores do Chromium não queriam que os usuários em redes comuns vissem uma janela de informações cada vez que pesquisassem por uma palavra, perguntando o que significavam, então implementaram um teste: ao iniciar um navegador ou alterar uma rede, o Chromium realiza pesquisas DNS de três "domínios" gerados aleatoriamente nível superior, de sete a quinze caracteres. Se duas dessas solicitações retornarem com o mesmo endereço IP, o Chromium presumirá que a rede local está "roubando" os erros NXDOMAINque deveria receber, de modo que o navegador considera todas as consultas inseridas na mesma palavra como tentativas de pesquisa até novo aviso.



Infelizmente, em redes que não sãoroubar os resultados das consultas de DNS, essas três operações costumam ir para o topo, para os próprios servidores de nomes raiz: o servidor local não sabe como qwajuixkresolver, então ele encaminha essa solicitação para seu encaminhador, que faz o mesmo, até que finalmente, a.root-servers.netou um dos seus "irmãos" não serão forçados a dizer "Desculpe, mas este não é um domínio."



Como existem aproximadamente 1,67 * 10 ^ 21 possíveis nomes de domínio falsos com sete a quinze caracteres, é comum que cada um desses testes, realizados em uma rede "justa", chegue ao servidor raiz. Isso equivale à metade da carga total no DNS raiz, de acordo com estatísticas da parte dos clusters root-servers.netque pertencem à Verisign.



A história se repete



Esta não é a primeira vez que um projeto bem-intencionado inundou ou quase inundou um recurso público com tráfego desnecessário - imediatamente nos lembrou da longa e triste história da D-Link e do servidor NTP Pole-Henning Camp em meados dos anos 2000. x.



Em 2005, o desenvolvedor do FreeBSD Poul-Henning, que também possuía o único servidor Stratum 1 Network Time Protocol da Dinamarca, recebeu uma conta inesperada e grande pelo tráfego transmitido. Resumindo, o motivo foi que os desenvolvedores da D-Link cadastraram os endereços dos servidores NTP Stratum 1, incluindo o servidor Campa, no firmware da linha de switches, roteadores e pontos de acesso da empresa. Isso aumentou instantaneamente o tráfego do servidor Kampa em nove vezes, o que fez com que o Danish Internet Exchange (ponto de troca da Internet da Dinamarca) mudasse sua tarifa de "Grátis" para "9.000 dólares por ano".



O problema não era que havia muitos roteadores D-Link, mas que eles "violavam a cadeia de comando". Muito parecido com o DNS, o NTP deve funcionar de maneira hierárquica - os servidores Stratum 0 retransmitem informações para os servidores Stratum 1, que retransmitem informações para os servidores Stratum 2 e assim por diante na hierarquia. Um roteador doméstico, switch ou ponto de acesso típico, como aquele que a D-Link solicitou endereços de servidor NTP, teve que enviar solicitações ao Stratum 2 ou Stratum 3.



O projeto Chromium, provavelmente com as melhores intenções, repetiu o problema com NTP no problema com DNS carregando os servidores raiz da Internet com consultas que eles nunca deveriam ter que lidar.



Há esperança de uma solução rápida



Há um bug aberto no projeto Chromium que requer que o Detector de redirecionamento de intranet padrão seja desativado para corrigir este problema. Devemos prestar homenagem ao projeto Chromium: um bug foi encontrado antes , Matt Thomas da Verisign atraiu a sua grande atenção para seu post no blog APNIC. O bug foi descoberto em junho, mas permaneceu no esquecimento até a postagem de Thomas; após o jejum, ele começou a ser vigiado de perto.



Espera-se que o problema seja resolvido em breve e que os servidores DNS raiz não precisem mais responder a aproximadamente 60 bilhões de consultas falsas todos os dias.






Publicidade



Os servidores Epic são VPSs do Windows ou Linux com poderosos processadores AMD EPYC e drives Intel NVMe muito rápidos. Corra para fazer o pedido!






All Articles