Alterar um registro 'A' para um 'CNAME' sem tempo de inatividade

5

Eu tenho um nome de domínio (atualmente hospedado no dyn.com) com um registro A apontando para o nosso endereço IP de produção.

Estamos mudando para o Amazon EC2 e estamos usando um balanceador de carga, com a recomendação de usarmos um registro CNAME em vez de A , pois os balanceadores de carga podem alterar periodicamente o endereço IP.

Infelizmente, não pareço ser capaz de fazer essa transição sem problemas - preciso excluir primeiro o registro A e, em seguida, adicionar o CNAME, o que potencialmente resultará em tempo de inatividade à medida que o novo registro se propaga.

Existe alguma maneira de fazer isso sem problemas com zero (ou muito mínimo) tempo de inatividade?

    
por James Davies 23.12.2014 / 08:07

2 respostas

10

Existe um truque que você pode usar aqui. Dito isto, Wesley é um cara inteligente e você deve ouvi-lo. Eu não sou pago para dizer isso, mas espero mudar isso um dia.

Supondo que você esteja tentando alterar um registro chamado www em uma zona chamada example.com. ...

  • Crie um curinga temporário Um registro ( * ) na zona. Confirme a mudança. Teste-o, verifique se o registro curinga está operando conforme esperado e substituindo as respostas NXDOMAIN.
  • Remova o registro www A. Commit.
  • Adicione seu novo registro CNAME. Commit. Teste novamente.
  • Remova o registro curinga * quando estiver satisfeito.
  • Siga o conselho de Wesley e encontre um provedor de DNS que não force você a pular em aros como esse.

Como essa é sua reputação na linha, convém obter uma atualização rápida sobre o que a Wikipédia tem dizer como os curingas são processados. Verifique se está adicionando um curinga com a mesma contagem de pontos do registro que está sendo removido, pois os registros de curingas não atravessam um ponto. (conhecido como um rótulo, se você quiser o termo RFC adequado)

Além disso, isso deve ser dito, mas todos esses testes devem ser executados diretamente em seus servidores autorizados. ( não contra o resolvedor padrão configurado para o computador do qual você está executando o teste)

    
por 23.12.2014 / 08:52
7

We're moving across to Amazon EC2 and are using a load balancer, with the recommendation that we use a CNAME instead of an A record

Espero sinceramente que você não esteja CNAME no seu domínio do apex. Se o seu host DNS for respeitoso, não será permitido. Se for um anfitrião vergonhoso e viscoso, você poderá, mas perderá um pedaço da sua alma (mas, de qualquer maneira, você está usando o EC2, então parece que a preocupação com a sua alma já é mínima).

Quoth Amazon:

You can't use a CNAME record to associate your zone apex with your Elastic Load Balancing instance. DNS rules prohibit the creation of a CNAME record at the zone apex (e.g., example.com). For example, if you own the example.com domain name, you can use a CNAME record for the foo.example.com subdomain name, but not for the example.com zone apex.

Continuando ...

...since load balancers may periodically change ip address.

Não, os balanceadores de carga não devem alterar periodicamente os endereços IP. Esse é o tipo de ponto deles. Eles permanecem os mesmos e agem como uma camada de abstração entre os consumidores e a infraestrutura de conteúdo. Se alguém lhe disser que o endereço IP do balanceador de carga pode mudar periodicamente, peça clareza.

O Amazon ELB está no lugar, portanto, o objetivo é CNAME seu domínio para o nome do ELB. Eu entendo a situação agora.

Unfortunately I don't appear to be able to seamlessly make this transition - I have to delete the A record first, and then add the CNAME, which will potentially result in downtime as the new record propagates.

Sem algumas peripécias de multicast e talvez até mesmo uma pitada de estranheza do BGP, o DNS em si não tem a intenção de ter nenhuma mudança de tempo de inatividade. Você pode, no entanto, minimizar o potencial de tempo de inatividade, reduzindo os valores de TTL dos seus registros para o menor período de tempo permitido. Normalmente, 60 segundos, mas se o seu host DNS não permitir que ele vá tão baixo, então faça com que seus pitchforks sejam polidos porque isso é horrível. Independentemente disso, solte seus registros para o menor número possível, mas espere o tempo que o valor TTL anterior fosse. Se o seu valor de TTL anterior era de 3600 segundos, espere uma hora após a alteração do seu valor de TTL para 60 segundos.

Depois de esperar tanto tempo, você pode alterar seu registro A para um CNAME e terá aproximadamente 60 segundos de tempo de inatividade, aproximadamente.

Fiz alternações semelhantes que envolveram tempo de inatividade zero, mas a sincronização foi realizada nos armazenamentos de dados para que, durante o período de interrupção obscura, todas as transações filtradas para os sistemas antigo e novo fossem sincronizadas com as magias de back-end. Isso geralmente custa mais tempo e esforço do que se justifica, a menos que você esteja lidando com muitos usuários e dinheiro.

The TTL is already 60 seconds, however the SOA NXDOMAIN TTL is 1800 seconds

... o que só será um problema se o seu domínio tiver algo que retorne uma resposta NXDOMAIN, o que não acontecerá quando você alterar seu registro de A para CNAME.

so removing the existing A record will potentially result in up to 30 minutes down (so far as I can tell)

Não, porque você não está removendo, está mudando, e qualquer host DNS razoável envia a remoção do registro A e a adição do CNAME de uma só vez, para que você não responda com NXDOMAIN a nenhum solicitações.

Se o Dyn fizer todas as alterações na sua zona uma ação atômica que se compromete individualmente com o arquivo de zona, então sim, você poderia estar retornando respostas NXDOMAIN. O que é uma coisa horrível para Dyn fazer, mas não seria totalmente surpreendente.

which I don't appear to be able to change with dyn.com

Minha opinião (que, quando combinada com US $ 5, permite que você tome uma xícara de café na Starbucks): Dyn é um horrível host de DNS.

    
por 23.12.2014 / 08:09