Servidor slave DNS antigo e obsoleto considerado nocivo?

Question

Já faz um tempo desde que eu estava me envolvendo em configurações de DNS, então meu conhecimento pode estar um pouco desatualizado.

Temos um domínio para o qual o servidor mestre é administrado por nossa equipe e o servidor escravo é fornecido pela empresa de hospedagem. Em algum momento decidimos mudar para outra empresa de hospedagem. Além disso, decidimos que os servidores mestre e escravo seriam administrados por nós. Como parte da preparação para esse processo, reduzimos os parâmetros de atualização, repetição e expiração do domínio para fazer com que as alterações se propaguem um pouco mais rápido. Em seguida, movemos o servidor para o novo host, fizemos alterações no arquivo de zona, levantamos o servidor DNS serial e recarregado. O processo de propagação é de alguma forma desequilibrado. A maioria dos servidores DNS tem dados atualizados. No entanto, alguns não, mesmo quando está fora da nossa configuração de expiração e (forçado por alguns administradores de DNS) a configuração de expiração padrão de uma semana.

Enquanto investigávamos possíveis razões para isso, descobrimos que nosso servidor estava configurado incorretamente e estava permitindo consultas apenas de escravo. Assim, durante um longo período de tempo, qualquer consulta externa ao nosso servidor falharia, mas funcionaria com o escravo. Isto foi obviamente corrigido imidiatamente. Também descobrimos que, a empresa de hospedagem anterior ainda tem nossa zona de escravos ativa e responde a consultas manuais (nslookup / host) fornecendo uma visão desatualizada de uma zona.

Então, minhas perguntas são: um antigo servidor dns escravo, de alguma forma, pode ser responsável pela propagação esquisita do DNS? Se alguns acessos do servidor DNS expiram / atualizam o tempo para alguma zona, ele obtém seus dados percorrendo a árvore de DNS até o topo (servidores raiz)? Ou simplesmente verificar com o servidor que recentemente obteve informações de zona?

EDIT: Desculpe por não mencioná-lo claramente, mas naturalmente eu mudei as entradas de DNS para o domínio no nível registar. Se eu fizer consultas não-recursivas com o nslookup / host e passar do TLD para o meu domínio, tudo estará de acordo com o que deve ser. Ainda assim, alguns servidores DNS fornecem dados da zona antiga como resposta não autoritativa.

    

Answer 1

Você simplesmente não pode consertar administradores que se recusam a ouvir a configuração do TTL. Então esqueça esse problema, porque não é um que você possa resolver.

Assumindo que não pode ser resolvido, então se você fez todos os outros passos certos, então não há nada que você possa fazer. Você precisa se esforçar muito para sincronizar os servidores da melhor maneira possível em uma pequena janela, mas mesmo assim há uma janela sempre pequena onde o mestre está à frente dos escravos.

O importante é que se você estiver removendo um escravo, mude os registros NS na zona e altere a noção da zona pai dos registros NS também. Lembre-se de que seu pai tem uma cópia dos registros do NS e da "cola" associada (endereços IP) para associar a esses registros do NS. Se você não mudou a noção de seus pais, isso pode ser a causa dos seus problemas.

    

Answer 2

O DNS não se propaga. A única maneira que o servidor escravo do seu host anterior pode afetar a resolução de nomes para o seu domínio é se ele ainda estiver listado como um servidor de nomes para o seu domínio. Verifique as informações de WHOIS do seu domínio e verifique o registrador de domínios para ver quais servidores de nomes estão listados para o seu domínio. Se o servidor escravo antigo estiver listado, será necessário consertar isso. Uma vez que seus servidores de nomes estão listados como servidores de nome único, então você deve ser bom. No que diz respeito a outros servidores DNS que não honram seus TTLs, não há nada que você possa fazer sobre isso. Quanto ao servidor slave que hospeda uma zona para o seu domínio, não importa, desde que não sejam autoritários para o seu domínio.

Eu posso hospedar zonas DNS para Microsoft e Google se eu quiser, mas isso só é importante para clientes DNS que usam meus servidores DNS para resolução de nomes. Se o servidor escravo for usado por qualquer cliente DNS e se o servidor escravo ainda responder de forma autoritária para o seu domínio, ele afetará a resolução de nomes do seu domínio para esses clientes, mas todos os outros clientes DNS não serão afetados.

    

Answer 3

Execute a execução dig +trace NS your.domain.com e, em seguida, pergunte a cada um dos servidores de nome acima de você qual é a opinião deles sobre os servidores de nomes para seu.domínio.com. Para dar um exemplo com att.com:

$ dig NS +trace att.com

; <<>> DiG 9.7.0-P2-RedHat-9.7.0-5.P2.el6_0.1 <<>> NS +trace att.com
;; global options: +cmd
.           395258  IN  NS  d.root-servers.net.
.           395258  IN  NS  e.root-servers.net.
.           395258  IN  NS  c.root-servers.net.
.           395258  IN  NS  f.root-servers.net.
.           395258  IN  NS  m.root-servers.net.
.           395258  IN  NS  g.root-servers.net.
.           395258  IN  NS  l.root-servers.net.
.           395258  IN  NS  a.root-servers.net.
.           395258  IN  NS  k.root-servers.net.
.           395258  IN  NS  j.root-servers.net.
.           395258  IN  NS  b.root-servers.net.
.           395258  IN  NS  h.root-servers.net.
.           395258  IN  NS  i.root-servers.net.
;; Received 508 bytes from 212.2.96.53#53(212.2.96.53) in 213 ms

com.            172800  IN  NS  k.gtld-servers.net.
com.            172800  IN  NS  e.gtld-servers.net.
com.            172800  IN  NS  d.gtld-servers.net.
com.            172800  IN  NS  m.gtld-servers.net.
com.            172800  IN  NS  c.gtld-servers.net.
com.            172800  IN  NS  l.gtld-servers.net.
com.            172800  IN  NS  h.gtld-servers.net.
com.            172800  IN  NS  j.gtld-servers.net.
com.            172800  IN  NS  g.gtld-servers.net.
com.            172800  IN  NS  b.gtld-servers.net.
com.            172800  IN  NS  f.gtld-servers.net.
com.            172800  IN  NS  i.gtld-servers.net.
com.            172800  IN  NS  a.gtld-servers.net.
;; Received 497 bytes from 192.33.4.12#53(c.root-servers.net) in 190 ms

att.com.        172800  IN  NS  ns3.attdns.com.
att.com.        172800  IN  NS  ns2.attdns.com.
att.com.        172800  IN  NS  ns1.attdns.com.
;; Received 134 bytes from 192.48.79.30#53(j.gtld-servers.net) in 420 ms

att.com.        3600    IN  NS  ns1.attdns.com.
att.com.        3600    IN  NS  ns3.attdns.com.
att.com.        3600    IN  NS  ns2.attdns.com.
att.com.        3600    IN  NS  ns4.attdns.com.
;; Received 168 bytes from 144.160.20.47#53(ns3.attdns.com) in 210 ms

Aqui j.gtld-servers.net diz que os servidores de nomes para att.com são ns [123] .attdns.com, e ns3.attdns.com diz, na verdade existe um quarto. Se você perguntar a todos os servidores de nomes para com. sobre registros NS para att.com. ( dig NS att.com @a.gtld-servers.net. then dig NS att.com @b.gtld-servers.net. etc.) você terá uma imagem completa, o que um cliente configurado adequadamente pode receber quando ele solicitar um servidor de nomes para seu domínio.

Em seguida, pergunte a cada um dos servidores de nomes reais para o seu domínio (ns [1234] .attdns.com. no exemplo) o que eles pensam sobre os registros NS para seu domínio (att.com no exemplo) e você tem completamente quadro completo.

Pode ser um pouco entediante, mas se todas as respostas que você obtiver forem sensatas, sua configuração estará comprovadamente correta. Você fez a sua parte para encurtar a fase de transição e, finalmente, tudo ficará bem, mas você não pode fazer nada sobre ISPs ignorando intencionalmente o TTL para entradas DNS para diminuir a carga em seus servidores.

    

Answer 4

Como mencionado, as outras respostas não são de fato totalmente corretas. Então, respondendo sua pergunta:

Can an old slave dns server, somehow be responsible for flaky DNS propagation?

Sim, pode, aproximadamente pela razão que você mesmo identificou e substituiu "os efeitos que estou vendo" por "propagação escamosa" (que não é o que está acontecendo):

If some DNS server hits expire/refresh time for some zone, does it get his data by walking DNS tree all the way from top (root servers)? Or does it simply check with the server that it recently got zone information from?

Além do fato de que as pessoas que fazem consultas DNS não baixam zonas inteiras, e o fato de que os tempos de expiração / atualização não têm nada a ver com isso, você está pensando nas linhas corretas. As pessoas que já consultaram informações de DNS para seu domínio e seus subdomínios receberão as informações de delegação para esse domínio. Até que o TTL dessas informações seja atingido, elas continuarão falando diretamente com os servidores DNS de conteúdo que eles conhecem; e se eles continuarem conversando com seu antigo serviço de hospedagem DNS, eles continuarão recebendo as informações antigas da delegação com um TTL novo a cada vez.

Este é um loop que pode continuar indefinidamente. É por isso que as instruções para a maneira correta de alternar delegações de um conjunto de servidores DNS de conteúdo para outro, como estas instruções e estas instruções entre outras, enfatize que é importante não omitir a etapa de atualizar as informações de delegação que os servidores antigos - todos deles - publicam .

Você tem para conversar com sua antiga empresa de hospedagem e atualizá-la para publicar o que está sendo publicado.