Um registro de glue de DNS é mais benéfico para um site pequeno?

1

Ok, diga que você é proprietário do someSmallSite.com. Seu servidor de nomes NS é, digamos, ns1.hostgator.com . O servidor NS do Hostgator é ns1.p13.dynect.net . O registro NS de que é ns0.dynamicnetworkservices.net , que tem um mesmo registro (cola) do mesmo domínio.

Digamos que alguém tente resolver someSmallSite.com. Como é um site pequeno, a maioria dos servidores DNS provavelmente não tem caches de nada disso. Portanto, três viagens de ida e volta teriam que ser feitas para encontrar o servidor DNS autoritativo real para someSmallSite.com. (resolvendo ns1.hostgator.com e, em seguida, ns1.p13.dynect.net e, no final, ns0.dynamicnetworkservices.net , que conterá o endereço IP real do servidor DNS).

Se você, em vez disso, fizer registros de cola para someSmallSite vs. usando o DNS de um host compartilhado (como Hostgator), você não está evitando 3 viagens de ida e volta para resolver o registro NS e depois o NS do NS? gravar etc, até você finalmente obter o endereço IP do servidor DNS?

Se minha lógica estiver correta, isso significaria que adicionar um registro de cola a um site pequeno seria mais benéfico na prática do que, digamos, um site grande, que provavelmente todos esses servidores NS já resolveram no cache? eles são mais propensos a estar em um servidor DNS que tem os registros de cola IP imediatamente vs. apontando para outro servidor DNS que aponta para outro, etc.

    
por daremkd 27.04.2017 / 15:42

2 respostas

2

Você está certo de que adicionar o registro de cola (a ns1.somesmallsite.com , por exemplo) salvaria algumas pesquisas ao resolver o endereço do seu site.

No entanto, devido ao cache do DNS, a diferença deve ser insignificante.

Seu próprio registro de cola

Se for um site com pouco tráfego, não é provável que o registro de cola seja armazenado em cache em um determinado servidor DNS, o que, por sua vez, acarretará uma pequena penalidade quando uma solicitação for feita.

Com essa abordagem, há uma grande chance de fazer uma pesquisa para somesmallsite.com NS em relação aos servidores de nomes autorizados com .com .

Registro de cola compartilhado

Por outro lado, quando o registro NS do seu site está apontado para ns1.hostgator.com , é provável que esse endereço seja armazenado em cache pelos servidores DNS em todo o mundo, mesmo para ns1.p13.dynect.net e ns0.dynamicnetworkservices.net , o que significa essas pesquisas não são repetidos sempre que uma consulta é feita para o seu domínio.

O registro NS do seu domínio provavelmente não estará no cache, devido à relativa falta de polaridade.

Ainda há uma grande chance de fazer uma pesquisa por somesmallsite.com NS , além de uma pequena chance de ter que pesquisar ns1.hostgator.com , ns1.p13.dynect.net e ns0.dynamicnetworkservices.net .

    
por 27.04.2017 / 16:26
1

Teoricamente pode haver uma pequena diferença, mas na prática isso não tem grande impacto, porque

  • Você poderia facilmente afetar isso usando mais TTL . Compare o 84600 com DR 300 .
  • As consultas DNS são armazenadas em todos os níveis em servidores DNS recursivos , & mesmo localmente : apenas um conjunto de consultas para o DNS autoritativo servidores ocorre, mesmo que haja mais algumas rodadas.
  • Os pacotes DNS são pequenos: max. carga útil de < 512 bytes (+ 20 bytes IPv4 e 8 bytes UDP cabeçalho ).
  • Tudo que você faz após as consultas do DNS é em uma escala muito maior em tamanho e repetições.

Então a questão não é verdadeiramente prática. Você pode ganhar muito mais, por exemplo, removendo um elemento de plano de fundo do site.

Para demonstrar como diferentes fatores afetam a velocidade de download da página inicial , testei o carregamento da página inicial do Serverfault.com em um computador sem nenhum cache de navegador de um local sem DNS em cache para o domínio. Analisei a velocidade de carregamento com a do Google Chrome .

  • As consultas DNS levaram um total de 68 ms sem cache (e apenas 4 ms quando já foram armazenadas em cache).
  • Demorou 457 ms para obter a resposta, ou seja, a conexão HTTPS foi iniciada.
  • Carregamento e renderização de página levou um total de 941 ms: 59 ms carregamento , 350 ms script , processamento de 153 ms , 14 ms < em> pintura , 279 ms outro e 86 ms ocioso .

A quantidade de viagens de ida e volta de consultas do DNS só pode ter uma diferença na primeira visita ao domínio. A experiência do usuário neste site do StackExchange (que considero bastante leve) foi que a primeira página levou 1,466 segundos para carregar. Menos de 5% desse atraso estava relacionado ao DNS. Mesmo que a quantidade de tempo de consulta do DNS dobre, isso não faria nenhuma diferença notável no nível de UX, portanto, não é benéfico na prática.

    
por 27.04.2017 / 15:56