Nosso site está fora do ar porque nosso provedor de hospedagem faliu e um nome de domínio usado nos bastidores para provisionar servidores de produção e desenvolvimento na AWS expirou. Não temos acesso a esse nome de domínio e não conseguimos falar com ninguém no antigo provedor. A configuração atual do DNS é mais ou menos assim:
companyname.com [CNAME www is an alias of prod.company-deadhost.com] ->
companyname-deadhost.com [NS ns-2048.awsdns-64.com, ns-2049.awsdns-65.net, ns-2050.awsdns-66.org, ns-2051.awsdns-67.co.uk] ->
[IP we don't know] The website server
Temos acesso total a companyname.com, mas não a companyname-deadhost.com, e não podemos verificar se costumava haver algum registro A ou outro. Vi a documentação do AWS/Route 53 que diz que configurar um nome de domínio e usar os registros NS do Route 53 é tudo o que é necessário para conectar o servidor web ao nome de domínio (ou seja, você não precisa de um endereço IP nem nada). Err, não, não vi - parece que precisaremos do endereço IP também.
Não podemos acessar companyname-deadhost.com, mas posso configurar um novo domínio "do meio" com esses registros NS (não os acima, encontramos um registro dos originais), como:
companyname.com [CNAME www is an alias of prod.newmiddledomain.com] ->
newmiddledomain.com [NS ns-2048.awsdns-64.com, ns-2049.awsdns-65.net etc etc] ->
[IP we don't know] The website server
O tráfego no servidor web ainda estará vindo de 'companyname.com', e o servidor web deve ser configurado para permitir isso - então ele deve funcionar? Ou ele falhará apesar disso, porque está vindo via newmiddledomain.com, não companyname-deadhost.com.
Preciso fazer algo sobre o domínio o mais rápido possível e prefiro não perder tempo tentando isso e esperando que os registros DNS se propaguem se isso não funcionar... Parece que estamos perdidos sem o IP da instância EC2, então isso é mais uma hipótese...
A cadeia CNAME e/ou NS inteira não importa¹, e não existe isso de "está chegando via..." – suas solicitações HTTP em si não passam pelo DNS, mas diretamente para o servidor que foi resolvido.
Portanto, o navegador web do cliente só se importa com o resultado final A/AAAA (para fazer a conexão TCP com algum endereço IP), enquanto o servidor web só se importa com o domínio da URL original (que vai para o cabeçalho do Host para HTTP) e permanece basicamente alheio ao DNS em geral – pode nem haver uma entrada DNS para o bem do servidor.
Além disso, os registros DNS não se "propagam" exatamente globalmente (fora da propagação quase instantânea entre seus próprios servidores de nomes); mais precisamente, eles são armazenados em cache (no sentido de que é um modelo de "pull sob demanda" em vez de um "push proativo"). Isso significa que o tempo que leva para todos verem as alterações não é fixado pela infraestrutura de DNS do mundo, mas está sob seu controle - o parâmetro TTL que foi definido nos dados antigos limita por quanto tempo esses dados podem ser armazenados em cache antes que os clientes e servidores DNS tenham que consultá-los novamente.
O que significa que você pode fazer mudanças rápidas se preparando antecipadamente: reduza o TTL do registro antigo para algo como 5 minutos, espere que essa mudança se "propague" (ou seja, os caches anteriores expirem), e agora a próxima mudança será visível após apenas 5 minutos no máximo – e pode ser desfeita em mais 5, no pior dos casos. Quando estiver satisfeito com os resultados, aumente os TTLs de volta para 30 ou 60 minutos.
¹ Existem algumas coisas que seguem manualmente a cadeia CNAME até o seu fim (CNAME especificamente; o NS não desempenha nenhum papel nisso) para determinar o nome "canônico" de um servidor – como Kerberos no Linux – mas HTTP não é uma delas.