Recentemente, alterei o endereço IP de um domínio específico, chame-o de example.com
. Eu sei que leva tempo para a mudança de DNS se propagar e ainda é cedo o suficiente para que a propagação não seja concluída.
Percebi que a execução de uma consulta ANY fornece resultados diferentes da execução de uma consulta de registro A. Por exemplo ...
% host -t a example.com
example.com has address THE.OLD.IP.ADDRESS
% host -t any example.com
example.com has address THE.NEW.IP.ADDRESS
Eu sei que, eventualmente, o DNS será totalmente propagado e a consulta do registro A retornará THE.NEW.IP.ADDRESS. Mas gostaria de saber se alguém poderia explicar por que uma consulta ANY retorna o novo endereço IP, enquanto a consulta de registro A ainda retorna o endereço IP antigo, até que a propagação seja concluída.
Isso é importante para mim porque o software aplicativo que resolve nomes de domínio parece fazer o equivalente à consulta de registro A e não a consulta QUALQUER e, portanto, esses aplicativos ainda resolvem o endereço IP para o valor antigo até que a propagação do DNS seja concluída.
Estou apenas procurando uma explicação de por que QUALQUER resultado parece se propagar mais rapidamente do que os resultados do registro A ... isso é para minha própria compreensão e edificação.
Muito obrigado.
Parece que a consulta de registro 'ANY' está sendo respondida pelo servidor DNS autoritativo que tem o novo IP enquanto a consulta de registro 'A' está sendo respondida por outros servidores DNS recursivos onde a propagação do novo endereço IP ainda está pendente e portanto, retorna o endereço IP antigo porque essa é a informação que ele tem em seu cache.
dig
não usehost
para depuração. E sempre especifique explicitamente qual servidor de nomes você consultaE agora, pelo menos desde 2019-01-10 com RFC 8482 "Fornecendo respostas de tamanho mínimo para consultas DNS que têm QTYPE=ANY" , os servidores de nomes são livres para "desarmar"
ANY
solicitações e responder com dados mínimos (qualquer subconjunto de registros que considerem apropriado, ou com apenas um registro HINFO).Veja este belo exemplo da Cloudflare:
A saída de dig ajuda em circunstâncias como essa, pois estamos perdendo outros detalhes, como o TTL associado a ambas as consultas.
Acho improvável que isso
ANY
esteja resultando em um comportamento diferente. Independentemente do tipo de consulta usado, os registros individuais em cache terão diferentes TTLs associados a eles e não há diferença nas duas consultas que solicitarão ao servidor que atualize seu valor em cache. Se alguma coisa,ANY
normalmente resultará em respostas para tipos de registro específicos sendo omitidos se não estiverem no cache no momento. (ou seja, expirado)Muito provavelmente suas consultas estão sendo direcionadas para um cluster DNS com balanceamento de carga e algumas de suas consultas estão chegando em um servidor onde o TTL da resposta antiga expirou e outras estão chegando em servidores que ainda têm o registro em cache. Uma maneira fácil de verificar isso no futuro é prestar atenção ao TTL retornado pelo servidor remoto. Se não estiver diminuindo consistentemente em segundos com base no tempo do mundo real, você está vendo valores de TTL vindos de diferentes servidores.