Há realmente duas perguntas sendo feitas aqui e elas se contradizem diretamente:
- como eu instruo os servidores DNS a continuarem suas consultas para a Amazon como sua autoridade para o domínio, sem alterar os registros DNS no registrador?
- como eu digo aos servidores DNS para buscarem suas consultas nos servidores da Amazon e NÃO para parar no QuickRouteDNS.COM?
Toda delegação na pesquisa de DNS deve ser mais específica que a anterior. Em outras palavras, você pode delegar subdomínios, mas não pode re-delegar exatamente o mesmo nome que foi delegado ao seu servidor. A solução correta é alterar a configuração no nível de registrador, o que você está tentando evitar.
O que você tem agora é uma configuração incorreta comum, conhecida como incompatibilidade de registro NS, que dá uma impressão incorreta de que esse design é viável. Abaixo está uma explicação do que está acontecendo, mas será um desafio seguir sem uma boa compreensão dos conceitos de DNS. Se eu perder você, lembre-se de que corrigir os dados do registrador é a maneira correta de resolver o problema.
Para ilustrar, aqui estão dois exemplos de snippets de zona:
$ORIGIN example.com
@ 2941 IN SOA ns1.example.com. someone.example.com. (
2015071001 ; serial
7200 ; refresh (2 hours)
900 ; retry (15 minutes)
7200000 ; expire (11 weeks 6 days 8 hours)
3600 ; minimum (1 hour)
)
@ IN NS ns1
@ IN NS ns2
sub IN NS ns1.contoso.com.
sub IN NS ns2.contoso.com.
Nos servidores de nomes contoso.com:
$ORIGIN sub.example.com.
@ 2941 IN SOA ns1.sub.example.com. someone.contoso.com. (
2015071001 ; serial
7200 ; refresh (2 hours)
900 ; retry (15 minutes)
7200000 ; expire (11 weeks 6 days 8 hours)
3600 ; minimum (1 hour)
)
@ IN NS bagel.contoso.com.
@ IN NS bacon.contoso.com.
Quais registros NS nas duas zonas acima são autoritativos para sub.example.com ? Se você achou que era ns1 e ns2.contoso.com , estaria enganado. Ao contrário da crença popular, um servidor de nomes que executa uma delegação não é considerado autoritativo para os registros NS usados para definir essa delegação. A definição autoritativa é de propriedade da zona na extremidade de recebimento da delegação.
Estabelecemos que bacon e bagel são autoritativos. O que não é tão óbvio aqui é que os namesevers não necessariamente perceberão isso imediatamente. As delegações são seguidas de boa fé, e inicialmente será assumido que os servidores que recebem a delegação são autoritativos. É somente quando esses registros NS são atualizados que o dano cerebral ocorre. As atualizações podem ser acionadas por qualquer número de itens, desde o TTL dos registros de NS de delegação que expiram a uma solicitação explícita para o valor desses NS records. Quando os registros NS forem sobrescritos, os novos servidores serão usados.
Juntando tudo, há um período inicial em que os servidores de nomes definidos pelo registrador estão sendo usados, seguido por um período em que o segundo conjunto de servidores de nomes está sendo usado. Durante o primeiro período, todos os registros que existem apenas no segundo conjunto de servidores falharão. Durante o segundo período, qualquer registro que exista apenas no primeiro conjunto de servidores falhará.
Pode parecer que o problema acabará se corrigindo (espere que tudo seja atualizado), mas isso nunca acontecerá. As pessoas reiniciarão seus servidores de nomes, liberarão seu cache ou defenderão novos servidores de nomes. Seu domínio existirá em um estado inconsistente de fluxo até que os registros NS se tornem consistentes. Os gurus de DNS podem fazer algumas coisas interessantes com isso, mas os casos de uso válidos para esse tipo de configuração são poucos e distantes entre si. O usuário médio deve evitar definições conflitantes de servidores de nomes a todo custo.