Esta é uma forma de distribuição de carga. Ao fornecer servidores de nomes diferentes e presumivelmente aleatórios, os pedidos para esses servidores podem ser bastante equilibrados.
dig NS soundshare.co.uk
;; ANSWER SECTION:
soundshare.co.uk. 168415 IN NS ns-1179.awsdns-19.org.
soundshare.co.uk. 168415 IN NS ns-1909.awsdns-46.co.uk.
soundshare.co.uk. 168415 IN NS ns-311.awsdns-38.com.
soundshare.co.uk. 168415 IN NS ns-972.awsdns-57.net.
alguns segundos depois:
soundshare.co.uk. 167643 IN NS ns-1289.awsdns-33.org.
soundshare.co.uk. 167643 IN NS ns-1581.awsdns-05.co.uk.
soundshare.co.uk. 167643 IN NS ns-41.awsdns-05.com.
soundshare.co.uk. 167643 IN NS ns-806.awsdns-36.net.
Por que isso pode estar ocorrendo?
Estes são todos os valores que defini anteriormente. Devo entrar em contato com o provedor de domínio?
Esta é uma forma de distribuição de carga. Ao fornecer servidores de nomes diferentes e presumivelmente aleatórios, os pedidos para esses servidores podem ser bastante equilibrados.
Todas as outras respostas até hoje perdem esse ponto muito importante: seus resultados de escavação são inúteis ... porque não vemos o que o servidor de nomes respondeu a você. Com base no TTL, parece que você consulta servidores de nomes recursivos, mas quais?
O que você observa não tem nada a ver com anycast, nem alterações na ordem RRset. Você parece observar NS diferentes em cada consulta, o que é estranho, mas, novamente, qual servidor de nomes responde a você?
Aqui está o que poderia ter acontecido com você: em sua configuração, você não atinge o mesmo servidor de nomes recursivo a cada vez. Então você observa o que eles têm em seu cache. Se você olhar para whois, verá que uma atualização foi aplicada a esse domínio ontem. Talvez uma mudança no DNS. Então, um dos servidores de nomes que você consulta tem os dados antes da mudança e o outro logo depois. Suponho que, se você fizer consultas, receberá as mesmas respostas sempre, ou depois de 46 horas, já que os TTLs relatados são enormes. Se é o seu domínio, você provavelmente fez várias alterações no DNS ontem e, portanto, agora os caches não têm mais as mesmas informações. Isso é normal, você só precisa esperar.
As alterações no seu DNS são claramente visíveis: link e captura de tela
Tente fazer suas observações consultando os servidores públicos conhecidos ( 1.1.1.1 , 8.8.8.8 e 9.9.9.9 para começar), bem como os servidores de nomes oficiais para .co.uk . Se você fizer isso, verá que sempre obtém exatamente o mesmo conjunto de servidores de nomes (o que significa que o pedido pode ser alterado, isso é conforme o padrão DNS, mas o conteúdo do conjunto não é alterado). p>
Todos os servidores de nomes oficiais respondem a mesma coisa, como esperado:
$ (for ns in $(dig NS co.uk +short); do dig soundshare.co.uk @$ns +noall +authority | grep NS; done) | sort | uniq -c
8 soundshare.co.uk. 172800 IN NS ns1033.ui-dns.org.
8 soundshare.co.uk. 172800 IN NS ns1039.ui-dns.biz.
8 soundshare.co.uk. 172800 IN NS ns1079.ui-dns.de.
8 soundshare.co.uk. 172800 IN NS ns1089.ui-dns.com.
Apenas 1.1.1.1 não é capaz de resolvê-lo (não sei por que ainda), o outro também responde a mesma coisa:
$ (for ns in 1.1.1.1 8.8.8.8 9.9.9.9; do dig soundshare.co.uk @$ns NS | grep 'IN NS '; done) | awk '{print $5}' | sort | uniq -c
2 ns1033.ui-dns.org.
2 ns1039.ui-dns.biz.
2 ns1079.ui-dns.de.
2 ns1089.ui-dns.com.
Tags dns