Mudança e propagação do servidor de nomes funciona parcialmente: sucesso para os EUA e falha para a Índia

Question

Nosso domínio está hospedado no Enom. Registros DNS são gerenciados pelo revendedor da Enom para a Índia chamado Pugmarks. No entanto, queremos mudar o serviço de gerenciamento de registros DNS de Enom / Reseller para AWS Route53, mantendo a Enom como registradora de domínios.

O TTL dos registros DNS do domínio é de 300 (5 minutos). Verifiquei o TTL para servidores de nomes e descobri que ele é 3600 (1 hora).

Quando substituímos os servidores de nomes Enom pelos do Route53, o Enom parou de resolver o domínio instantaneamente. Após o que os servidores DNS do ISP seguiram o exemplo após o TTL expirar. O tráfego do nosso website caiu (como observado no Google Analytic). Esse impacto é entendido.

Um pouco mais tarde, ao consultar o registro NS para o domínio através de um Public / Open Name Servers como: 4.2.2.2 - 4.2.2.6 e 8.8.8.8 & 8.8.4.4, obtemos os registros atualizados apontando para Route53: ou seja,

dig NS <domain.com> @8.8.4.4.

O comando acima mostra os registros do servidor de nomes Route53. Da mesma forma, todos os outros registros são exibidos com sucesso (A, CNAME etc.) indicando que a alteração do Servidor de Nomes foi adquirida com êxito por esses servidores DNS. Neste ponto, observamos o escalonamento de tráfego dos EUA no Google Analytics.

Mas, o tráfego indiano ainda permanece zero. Eu tenho consultado alguns servidores DNS de dois ISPs indianos diferentes (não abertos a públicos / restritos a ISPs). Estes não retornam nenhum registro. Esperamos por 4 horas para o ISP acompanhar a mudança de registros, mas em vão.

É estranho que a região dos EUA tenha conseguido novos recordes, enquanto nenhum dos provedores indianos que tentamos (pelo menos 5 deles) puderam escolher a mudança. Todas as outras ferramentas de teste de DNS na Web foram capazes de escolher a alteração, exceto o ISP aqui. Resultando em um grande mergulho no tráfego, que é uma grande preocupação, já que é o público alvo do site.

Depois de 4 horas de espera e relógio, trocamos as entradas de volta para os Servidores de nomes da Enom. Em questão de segundos, o ISP indiano foi capaz de resolver registros, como se estivesse sempre consultando os servidores da Enom por registros, mesmo que o TTL seja por 1 hora. (O Route53 continuaria a resolver, portanto o tráfego dos EUA permaneceu inalterado)

Eu tenho duas dúvidas:

1. O ISP indiano está armazenando em cache o NS do domínio por mais de 1 hora, provavelmente por 48 horas
2. Algum problema relacionado à região indiana sobre o qual não tenho idéia.

O ponto 1 é o principal suspeito no que me diz respeito. Aqui está um link que fornece detalhes sobre o domínio. Ele mostra o servidor de nomes pai como TTL de 48 horas, enquanto o servidor de nomes local é de 1 hora TTL. Isso poderia estar causando o problema?

Eu quero mover o gerenciamento de DNS para o Route53 e não posso ter um tempo de inatividade por mais de 6 horas. Nós tentamos até 4 horas em vão.

Por que isso está acontecendo e qual é a saída?

Uma alternativa, talvez, é manter todos os registros DNS para 49hrs TTL (TTL maior que TTL para o registro NS no pai) e depois mudar os Servidores de Nomes após a propagação do registro desta alteração TTL. No entanto, não é infalível, mas pode ser tentado.

    

Answer 1

(Esta é uma pergunta antiga, mas ainda merece uma resposta)

Aparentemente, o que você fez foi isto: Você preparou os novos servidores de nomes para responder de forma autoritativa aos seus domínios. Em seguida, você alterou o registro (ou seja, alterou as entradas do NS para dnsindia.com nos servidores DNS pai responsáveis por com para apontar para os novos servidores DNS); no mesmo momento, os servidores de nomes antigos pararam de responder a consultas sobre dnsindia.com (ou responderam com NXDOMAIN ou algo assim).

Como consequência, o impacto - especialmente para seu público principal - foi o seguinte: Após uma 1h, todos os dados armazenados em cache em resolvedores de DNS em ISPs da Índia expiraram, mas apenas dados para suas entradas, como registros A para www.india.com . Portanto, os resolvedores tentariam consultar os servidores de nome apropriados para novos dados. No entanto, a info qual servidor para consulta ainda não tinha expirado: essa informação veio da com zone e tinha um TTL de 48hrs (provavelmente ainda até 47hrs, digamos 24hrs em média) ; como isso se refere aos servidores DNS agora extintos no provedor antigo, as falhas ocorrem como você observou. Por outro lado, a consulta de um resolvedor remoto seria bem-sucedida, já que seria improvável que houvesse uma cópia em cache dos registros NS pai.

Como fazê-lo corretamente? As seguintes estratégias são possíveis (em ordem decrescente de preferência):

a) Assegure-se de que os servidores DNS antigos continuem a servir sua zona por pelo menos 48 horas após a transição (o TTL pai), mas não por muito mais tempo. Na verdade, esse é o método que usei na maior parte do tempo; o antigo administrador do servidor só precisa se lembrar de remover as zonas posteriormente.

b) Assegure-se de que os servidores DNS antigos permitam consultas recursivas (pelo menos para sua zona e pelo menos por 48 horas); note que os servidores que são servidores DNS "oficiais" para alguma zona normalmente não permitem consultas recursivas

c) Antes de mover zonas, altere seu TTL local para todos os registros para 96 horas, digamos. Então espere 48 horas antes de fazer o movimento. Dessa forma, os resolvedores normalmente devem ter uma cópia de seus registros DNS no cache que sobreviva mais do que os registros NS obsoletos. Esse método não é perfeito e se torna problemático, especialmente se houver "referências cruzadas" entre domínios ou se houver registros consultados com menos frequência que os registros principais.

d) Como alternativa, antes de mover as zonas, diminua o TTL pai para 1 hora (ou para o tempo de inatividade que você considerar aceitável), aguarde 48 horas e faça o movimento. No entanto, pode não ser possível alterar o TTL para um valor tão baixo na zona pai (eles não querem ser consultados com tanta frequência) e, mesmo assim, você teria que considerar seus horários de atualização de zona