O navegador Chromium, o próspero pai de código aberto do Google Chrome e do novo Microsoft Edge, recebeu atenção negativa significativa por um recurso que foi concebido com boas intenções: ele verifica se o ISP do usuário está “roubando” resultados de consultas de domínio inexistentes .
, que cria consultas falsas para "domínios" aleatórios cuja existência é estatisticamente improvável, é responsável por aproximadamente metade do tráfego total recebido por servidores DNS raiz em todo o mundo. O engenheiro da Verisign, Matt Thomas, escreveu um longo no blog da APNIC descrevendo o problema e avaliando sua escala.
Como a resolução de DNS geralmente é realizada
Esses servidores são a autoridade máxima que você deve contatar para resolver .com, .net, etc., para que eles lhe digam que frglxrtmpuf não é um domínio de nível superior (TLD).
DNS, ou Sistema de Nomes de Domínio, é um sistema pelo qual os computadores podem resolver nomes de domínio memoráveis, como arstechnica.com, em endereços IP muito menos fáceis de usar, como 3.128.236.93. Sem o DNS, a Internet não existiria de uma forma que os humanos pudessem usar, o que significa que a carga desnecessária na infra-estrutura de nível superior é um problema real.
Carregar uma única página da web moderna pode exigir um número incrível de pesquisas de DNS. 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 que a página carregue totalmente!
Para acomodar esse tipo de carga de trabalho para um mecanismo de busca que precisa atender o mundo inteiro, o DNS é projetado como uma hierarquia de vários níveis. No topo desta 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 máxima para cada domínio abaixo deles. Um passo à frente estes servidores são os próprios servidores raiz, de a.root-servers.net para m.root-servers.net.
Com que frequência isso acontece?
Graças à hierarquia de cache multinível 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 de DNS diretamente do seu ISP. Quando o dispositivo de um usuário precisa saber como chegar a um site específico, primeiro uma solicitação é enviada 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 provedor local nem os “servidores de encaminhamento” especificados em sua configuração tiverem uma resposta em cache, a solicitação será enviada diretamente ao servidor de domínio autoritativo. acima aquele que você está tentando converter. Quando домен.com isso significará que a solicitação será enviada aos servidores autorizados do próprio domínio com, que estão localizados em gtld-servers.net.
Sistema gtld-servers, ao qual a solicitação foi feita, responde com uma lista de servidores de nomes autorizados para o domínio domínio.com, bem como pelo menos um registro de link contendo o endereço IP de um desses servidores de nomes. Em seguida, as respostas avançam 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. Todos eles armazenam essa resposta em cache para não perturbar desnecessariamente os sistemas de nível superior.
Na maioria dos casos, os registros do servidor de nomes para domínio.com já estará armazenado em cache em um desses encaminhadores, portanto os servidores raiz não serão perturbados. No entanto, por enquanto estamos falando sobre o tipo de URL com o qual estamos familiarizados - aquele que é convertido em um site normal. As solicitações do Chrome estão no mesmo nível acima isso, na etapa dos próprios clusters root-servers.net.
Verificação de roubo de Chromium e NXDomain
O Chromium verifica “este servidor DNS está me enganando?” respondem por quase metade de todo o tráfego que chega ao cluster de servidores DNS raiz da Verisign.
O navegador Chromium, projeto pai do Google Chrome, do novo Microsoft Edge e de inúmeros navegadores menos conhecidos, deseja fornecer aos usuários a facilidade de pesquisa em uma única caixa, às vezes chamada de “Omnibox”. Em outras palavras, o usuário insere URLs reais e consultas de mecanismos de pesquisa no mesmo campo de texto na parte superior da janela do navegador. Dando mais um passo em direção à simplificação, também não obriga 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 uma URL e o que deve ser considerado uma consulta de pesquisa. Na maioria dos casos isso é bastante óbvio - por exemplo, uma string com espaços não pode ser uma URL. Mas as coisas podem ficar mais complicadas quando você considera as intranets – redes privadas que também podem usar domínios privados de nível superior para resolver sites reais.
Se um usuário na intranet da empresa digitar "marketing" e a intranet da empresa tiver um site interno com o mesmo nome, o Chromium exibirá uma caixa de informações perguntando ao usuário se ele deseja pesquisar por "marketing" ou acessar https://marketing. Pode não ser o caso, mas muitos ISPs e provedores de Wi-Fi públicos “sequestram” cada URL com erro ortográfico, redirecionando o usuário para alguma página cheia de banner.
Geração aleatória
Os desenvolvedores do Chromium não queriam que os usuários em redes normais vissem uma caixa de informações perguntando o que eles queriam dizer sempre que pesquisassem uma única palavra, então implementaram um teste: quando iniciam um navegador ou mudam de rede, o Chromium realiza pesquisas de DNS em três "domínios" de nível superior gerados aleatoriamente, com sete a quinze caracteres. Se duas dessas solicitações retornarem com o mesmo endereço IP, o Chromium assumirá que a rede local está "sequestrando" os erros NXDOMAIN, que deveria receber, portanto, o navegador considera todas as consultas de uma única palavra inseridas como tentativas de pesquisa até novo aviso.
Infelizmente, em redes que não roubar os resultados das consultas DNS, essas três operações geralmente chegam ao topo, até os próprios servidores de nomes raiz: o servidor local não sabe como resolver qwajuixk, então encaminha essa solicitação para seu encaminhador, que faz o mesmo, até que finalmente a.root-servers.net ou um de seus “irmãos” não será forçado a dizer “Desculpe, mas isto não é um domínio”.
Como existem aproximadamente 1,67*10^21 possíveis nomes de domínio falsos com comprimento de sete a quinze caracteres, o mais comum cada a partir desses testes realizados na rede “honesta”, chega ao servidor raiz. Isto equivale a tanto metade da carga total no DNS raiz, de acordo com estatísticas daquela parte dos clusters root-servers.net, que são propriedade da Verisign.
A história se repete
Esta não é a primeira vez que um projeto criado com as melhores intenções ou quase inundou um recurso público com tráfego desnecessário - isso imediatamente nos lembrou da longa e triste história do servidor NTP (Network Time Protocol) da D-Link e Poul-Henning Kamp em meados dos anos 2000.
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 escreveram os endereços dos servidores Stratum 1 NTP, incluindo o servidor Kampa, no firmware da linha de switches, roteadores e pontos de acesso da empresa. Isso aumentou instantaneamente o tráfego do servidor de Kampa em nove vezes, fazendo com que o Danish Internet Exchange (Internet Exchange Point da Dinamarca) alterasse sua tarifa de "Gratuita" para "US$ 9 por ano".
O problema não era que houvesse muitos roteadores D-Link, mas que eles estavam “fora de linha”. Assim como o DNS, o NTP deve operar de forma hierárquica - os servidores Stratum 0 passam informações para os servidores Stratum 1, que passam informações para os servidores Stratum 2 e assim por diante na hierarquia. Um roteador doméstico típico, switch ou ponto de acesso como aquele que a D-Link programou com endereços de servidor NTP enviaria solicitações ao servidor Stratum 2 ou Stratum 3.
O projeto Chromium, provavelmente com a melhor das intenções, replicou o problema do NTP no problema do DNS, carregando os servidores raiz da Internet com solicitações que eles nunca deveriam atender.
Há esperança de uma solução rápida
O projeto Chromium tem código aberto , que requer a desativação do Detector de redirecionamento de intranet por padrão para resolver esse problema. Devemos dar crédito ao projeto Chromium: o bug foi encontrado antes dissocomo Matt Thomas, da Verisign, chamou muita atenção para ele com seu no blog da APNIC. O bug foi descoberto em junho, mas permaneceu esquecido até a postagem de Thomas; Após o jejum, ele começou a ficar sob supervisão rigorosa.
Espera-se que o problema seja resolvido em breve e que os servidores DNS raiz não tenham mais que responder às cerca de 60 bilhões de consultas falsas todos os dias.
Como a publicidade
Servidores épicos - É ou Linux com poderosos processadores da família AMD EPYC e unidades Intel NVMe muito rápidas. Apresse-se para fazer o pedido!
Fonte: habr.com