comentários do leitor
230
com 104 pôsteres participantes, incluindo o autor da história
Compartilhe esta história
Compartilhar no Facebook
Compartilhar no Twitter
Compartilhe no Reddit
O navegador Chromium - código aberto, pai upstream tanto do Google Chrome quanto do novo Microsoft Edge - está recebendo muita atenção negativa por um recurso bem-intencionado que verifica se o ISP de um usuário está "sequestrando" resultados de domínio inexistentes.
o
Detector de redirecionamento de intranet
, que torna estatisticamente improvável a existência de consultas espúrias para "domínios" aleatórios, é responsável por cerca de metade do tráfego total que os servidores DNS raiz do mundo recebem. O engenheiro da Verisign Matt Thomas escreveu um longo blog sobre APNIC
publicar
delineando o problema e definindo seu escopo.
Como a resolução DNS normalmente funciona
Prolongar
/
Esses servidores são a autoridade final que deve ser consultada para resolver .com, .net e assim por diante - e para dizer a você que 'frglxrtmpuf' não é um verdadeiro TLD.
Jim Salter
DNS, ou Sistema de Nomes de Domínio, é como os computadores traduzem nomes de domínio relativamente memoráveis como arstechnica.com em endereços IP muito menos memoráveis, como 3.128.236.93. Sem o DNS, a Internet não poderia existir em uma forma utilizável por humanos - o que significa que a carga desnecessária em sua infraestrutura de nível superior é um problema real.
Carregar uma única página da Web moderna pode exigir um número estonteante de pesquisas de DNS. Quando analisamos a página inicial da ESPN, contamos 93 nomes de domínio separados - de a.espncdn.com a z.motads.com - que precisavam ser executados para carregar totalmente a página!
A fim de manter a carga gerenciável para um sistema de pesquisa que deve atender a todo o mundo, o DNS foi projetado como uma hierarquia de vários estágios. 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 dele. Um passo acima
Essa
são os servidores raiz reais,
a.root-servers.net
Através dos
m.root-servers.net
.
Com que frequência isso acontece?
Uma porcentagem muito pequena das consultas de DNS do mundo chega realmente aos servidores raiz, devido à hierarquia de cache multinível da infraestrutura de DNS. A maioria das pessoas obterá as informações do resolvedor de DNS diretamente do ISP. Quando seu dispositivo precisa saber como alcançar
arstechnica.com
, a consulta vai primeiro para esse servidor DNS local gerenciado pelo ISP. Se o servidor DNS local não souber a resposta, ele encaminhará a consulta para seus próprios "encaminhadores", se houver algum definido.
Se nem o servidor DNS local do ISP nem qualquer "encaminhador" definido em sua configuração tiver a resposta em cache, a consulta eventualmente irá subir diretamente para os servidores autoritativos do domínio
acima de
aquele que você está tentando resolver - para
arstechnica.com
, isso significaria consultar os servidores autorizados para
com
em si, em
gtld-servers.net
.
Propaganda
o
servidores gtld
sistema consultado responde com uma lista de servidores de nomes autorizados para o
arstechnica.com
domínio, junto com pelo menos um registro "cola" contendo o endereço IP de um desses servidores de nomes. Agora, as respostas percolam de volta na cadeia - cada encaminhador passa essas respostas para o servidor que as consultou até que a resposta finalmente alcance o servidor ISP local e o computador do usuário - e todos eles ao longo do cache de linha que respondem para evitar incomodar quaisquer sistemas "upstream" desnecessariamente.
Para a grande maioria dessas consultas, os registros NS para
arstechnica.com
já estará armazenado em cache em um desses servidores de encaminhamento, portanto, os servidores raiz não precisam ser incomodados. Até agora, porém, estamos falando de um tipo mais familiar de URL - aquele que remete a um site normal. As consultas do Chrome atingiram um nível acima
naquela
, no real
root-servers.net
os próprios clusters.
Chromium e o teste de sequestro NXDomain
Prolongar
/
Chromium's "este servidor DNS está errado comigo?" probes representam cerca de metade de todo o tráfego que chega ao cluster de servidor raiz DNS da Verisign.
Matthew Thomas
O navegador Chromium - projeto pai do Google Chrome, o novo Microsoft Edge e inúmeros outros navegadores menos conhecidos - quer oferecer aos usuários a simplicidade de uma pesquisa de caixa única, às vezes conhecida como "Omnibox". Em outras palavras, você digita URLs reais e consultas de mecanismo de pesquisa na mesma caixa de texto na parte superior do navegador. Levando a facilidade de uso um passo adiante, isso
não o força a realmente digitar ohttp: //
ou
https: //
parte do URL também.
Por mais conveniente que seja, essa abordagem requer que o navegador entenda o que deve ser tratado como um URL e o que deve ser tratado como uma consulta de pesquisa. Para a maior parte, isso é bastante óbvio - qualquer coisa com espaços não será uma URL, por exemplo. Mas fica complicado quando você considera as intranets - redes privadas, que podem usar TLDs igualmente privados que resolvem para sites reais.
Se um usuário na intranet de uma empresa digitar "marketing" e a intranet dessa empresa tiver um site interno com o mesmo nome, o Chromium exibe uma barra de informações perguntando ao usuário se ele pretendia pesquisar por "marketing" ou navegar até
https: // marketing
. Até agora, tudo bem - mas muitos ISPs e provedores de Wi-Fi compartilhados sequestram todos os URLs digitados incorretamente, redirecionando o usuário para uma página de destino carregada de anúncios de algum tipo.
Gerar aleatoriamente
Os autores do Chromium não queriam ver "você quis dizer" infobars em cada pesquisa de palavra única nesses ambientes comuns, então eles implementaram um teste: na inicialização ou mudança de rede, o Chromium emite pesquisas DNS para três sete gerados aleatoriamente. até "domínios" de nível superior de 15 caracteres. Se duas dessas solicitações voltarem com o mesmo endereço IP, o Chromium presume que a rede local está sequestrando o
NXDOMAIN
erros que deveria estar recebendo - portanto, trata apenas todas as entradas de uma única palavra como tentativas de pesquisa até novo aviso.
Propaganda
Infelizmente, em redes que
não são
sequestrando os resultados da consulta DNS, essas três pesquisas tendem a se propagar até os servidores de nomes raiz: o servidor local não sabe como resolver
qwajuixk
, então ele devolve essa consulta para seu encaminhador, que retorna o favor, até que eventualmente
a.root-servers.net
ou um de seus irmãos tem que dizer "Desculpe, isso não é um domínio."
Uma vez que existem cerca de 1,67 * 10 ^ 21 possíveis nomes de domínio falsos de sete a 15 caracteres, em sua maioria
cada
uma dessas sondagens emitidas em uma rede honesta eventualmente incomoda um servidor raiz. Isso resulta em um enorme
metade
a carga total nos servidores DNS raiz, se formos pelas estatísticas da parte da Verisign do
root-servers.net
clusters.
A história se repete
Esta não é a primeira vez que um projeto bem-intencionado tem
inundado
ou quase inundou um recurso público com tráfego desnecessário - fomos imediatamente lembrados da longa e triste história do servidor NTP (Network Time Protocol) de D-Link e Poul-Henning Kamp, de meados dos anos 2000.
Em 2005, Poul-Henning Kamp - um desenvolvedor FreeBSD, que também executou o único servidor Stratum 1 Network Time Protocol da Dinamarca - recebeu uma conta enorme e inesperada de largura de banda. Para encurtar a história, os desenvolvedores da D-Link codificaram os endereços do servidor NTP Stratum 1, incluindo Kamp, em firmware para a linha de switches, roteadores e pontos de acesso da empresa. Isso aumentou imediatamente o uso de largura de banda do servidor de Kamp em nove vezes, fazendo com que o Danish Internet Exchange mudasse sua conta de "Grátis" para "Isso custará $ 9.000 por ano, por favor".
O problema não era que havia muitos roteadores D-Link - era que eles estavam "pulando a cadeia de comando". Muito parecido com o DNS, o NTP deve operar de forma hierárquica - os servidores Stratum 0 alimentam os servidores Stratum 1, que alimentam os servidores Stratum 2, e assim por diante. Um roteador doméstico simples, switch ou ponto de acesso como aqueles em que a D-Link codificou esses servidores NTP deve consultar um servidor Stratum 2 ou Stratum 3.
O projeto Chromium, presumivelmente com as melhores intenções em mente, traduziu o problema do NTP em um problema de DNS ao carregar os servidores raiz da Internet com consultas que eles nunca deveriam ter que processar.
Resolução esperançosamente à vista
Há um aberto
erro
no projeto Chromium, solicitando que o Detector de redirecionamento da intranet seja desativado por padrão para resolver esse problema. Para ser justo com o projeto Chromium, o bug foi realmente aberto
antes
Matt Thomas, da Verisign, desenhou um círculo vermelho gigante em torno do problema em seu blog APNIC
publicar
. O bug foi aberto em junho, mas definhou até a postagem de Thomas; desde a postagem de Thomas, tem recebido atenção diária.
Esperançosamente, o problema será resolvido em breve - e os servidores DNS raiz do mundo não precisarão mais responder a cerca de 60 bilhões de consultas falsas todos os dias.
Listando imagem por
Matthew Thomas
