No momento, estou migrando uma zona DNS de um provedor de servidor DNS para outro. Estou tentando estimar quanto tempo levará para a alteração se propagar e entender qual pode ser o atraso se eu optar por reverter no meio do fluxo.
Anteriormente, pensei que poderia fazer:
dig example.com ns
Para ver qual era o TTL restante no registro NS, mas agora entendo que esse registro NS é o registro NS para subdomínios na zona, e não o registro NS que emana dos servidores raiz, que é o que determina em última instância qual servidor de nomes a consulta será enviada.
Eu testei isso configurando um registro de teste na zona em cada um dos provedores:
Provider1 test.example.com 10.0.0.1
Provider2 test.example.com 192.168.0.1
Para ambos os provedores, o TTL nos registros NS em 0, enquanto os registros NS no nível TLD Registrar apontam para os servidores de nomes do Provider1.
Quando altero os registros NS na zona em Provider1, posso ver isso refletido nas consultas NS quase imediatamente (usando 'dig example.com ns').
No entanto, quando envio uma consulta para um registro A, ou seja,
test.example.com
sempre volta
10.0.0.1
independentemente de como os registros NS na zona do Provedor 1 estão configurados.
Com base nisso, concluí que os registros NS dentro do arquivo de zona são irrelevantes para a migração e que apenas os registros dos servidores de nomes no nível TLD são importantes.
No entanto, não consigo ler quanto tempo é provável que uma alteração ali se propague, seja para frente ou para trás.
É possível consultar com que TTL estou trabalhando para registros provenientes dos servidores raiz do TLD?
Esta é uma hipótese incorreta, mas um erro fácil de cometer. Você pode ler um pouco mais sobre o assunto dos registros NS do ápice aqui . A versão curta é que ambos importam, e o que está sendo usado será diferente dependendo se um servidor DNS de cache já consultou seu domínio anteriormente ou não.
Lembre-se de que a maioria dos servidores DNS recursivos impõe um TTL mínimo, portanto, quaisquer conclusões tiradas de experimentos com um TTL de zero são quase certamente imprecisas. O único caso em que isso não ocorre é quando você controla a política de TTL mínima usada pelo servidor que está consultando.
Vou me concentrar neste tópico, pois você teve alguns falsos começos no restante de sua pergunta. Primeiro, é importante lembrar que os TTLs são armazenados em cache em servidores DNS recursivos. Como todos na Internet estão usando diferentes servidores DNS recursivos, a única suposição que você pode fazer é que levará até n segundos, sendo n o valor dos TTLs.
Isso nos leva a quais TTLs são relevantes aqui:
NSregistros expirem, as solicitações de registros individuais que estão no cache não expirarão automaticamente. Exemplo: Setest.example.com IN Aexpira daqui a dez minutos, masexample.com IN NSexpira daqui a cinco minutos,test.example.compermanecerá no cache mesmo após aNSalteração dos registros. Quaisquer problemas relacionados ao valor desse registro nos novos servidores não se tornarão evidentes até que o registro tenha expirado e seja atualizado.NSregistros cola servidos pelos servidores TLD DNS. Eles são usados por servidores recursivos que precisam obter informações sobre seu domínio quando solicitado pela primeira vez. Esses TTLs influenciam quanto tempo leva até que os servidores DNS listados em seu arquivo de zona sejam usados para a próxima atualização. (consulte as perguntas e respostas acima para esclarecimentos sobre isso)NSregistros listados na parte superior do arquivo de zona. Depois que os TTLs do registro cola expirarem, esses TTLs poderão ser usados. As implementações variam neste detalhe. Como você está lidando com uma Internet inteira de diferentes implementações, a única suposição segura é que alguns servidores o estão usando.Você não pode presumir que todos os
NSTTLs de registro em cache na Internet são de uma fonte ou de outra. Isso o força a planejar o mais alto dos dois, a menos que você realmente não esteja preocupado com servidores DNS recursivos que você não opera.Juntando tudo isso, chegamos às seguintes conclusões:
NSregistros na cola e osNSregistros na zona.NSalteração final do registro. Você não apenas precisa de todos os servidores disponíveis para clientes que não receberam a última alteração, mas qualquer inconsistência nos dados de registro entre os dois pode servir para tornar as coisas ainda mais confusas.Você pode fazer isso facilmente com nslookup no Windows, presumo que você possa fazer o mesmo com dig. Com o nslookup, você simplesmente consulta um dos servidores de nomes GTLD para os registros do servidor de nomes do seu domínio usando depuração para obter uma lista de servidores de nomes para o seu domínio com o TTL desses registros do servidor de nomes.
A sintaxe para executar uma consulta semelhante usando
digé:Costumava ser possível consultar o registro SOA do domínio para obter os valores TTL padrão:
Mas isso foi preterido em favor da diretiva $TTL.
Se você tiver registros específicos nos quais esteja interessado, poderá adicionar o sinalizador +ttlid para cavar:
Para obter o TTL exato restante:
(o segundo campo é TTL - neste caso 604800)