Interpretação errônea generalizada das regras do DNS na resolução de curingas

Question

[EDITADO para adicionar: esse problema desapareceu sozinho. Eu acredito que a resolução de nomes da Cloudflare pode ter sido a culpa. Veja minha própria resposta abaixo]

Aqui está um trecho do meu arquivo de zona

*.example.com.      300 IN  CNAME   proxy.herokuapp.com.
foo.example.com.    300 IN  A       111.111.111.111

Se eu dig @8.8.8.8 foo.example.com obtiver a resposta que espero:

;; ANSWER SECTION:
foo.example.com.    30  IN  A   111.111.111.111

O mesmo acontece com todos os outros servidores DNS públicos que eu tentei.

No entanto, quando tento configurar um cheque com Pingdom para um URL em foo.example.com , ele envia o tráfego para o meu aplicativo Heroku, referenciado pelo *.example.com RR.

O mesmo acontece com as verificações configuradas em New Relic , Errplane e no tráfego gerado pelo próprio Heroku app.

Portanto, de um lado, todos os servidores DNS públicos interpretam o arquivo de zona de uma maneira. No entanto, quatro prestadores de serviços interpretam de forma diferente, um que difere do padrão sugerido pela RFC 4592.

Minha pergunta é: esses fornecedores de serviços confiáveis e maduros estão errados? Ou é pouco eu?

    

Answer 1

Do ponto de vista do protocolo, o servidor de nomes autoritativo sintetiza as respostas às consultas que se enquadram dentro de um curinga, não os servidores que o consultam. Se você está recebendo respostas diferentes, um dos seguintes itens deve ser o caso:

1. Eles não estão falando com o mesmo servidor. Você tem vários servidores de nome de autenticação e eles estão enviando respostas diferentes, ou um conjunto diferente de servidores de autenticação está sendo consultado completamente. (sua empresa executa uma configuração DNS dividida?)
2. Alguns dos servidores de armazenamento em cache possuem um registro mais antigo no cache.
3. O DNS está sendo ignorado completamente, isto é, uma entrada no arquivo de hosts.

Answer 2

Após cerca de 10 dias, o problema desapareceu por conta própria. Meu melhor palpite é que a Cloudflare (que executa os servidores de nomes para este domínio) mudou seu código de resolução de DNS.

Mais algumas informações:

1. A resposta de Andrew B (2) é uma candidata: o nome estava sendo resolvido por servidores de cache que não tinham sido atualizados desde que eu adicionei o registro A. O problema persistiu por mais de uma semana, então não acredito que isso seja provável.

2. Eu levantei o problema com o Cloudflare e ele foi escalado para a equipe de engenharia. Recentemente, eles lançaram um código de resolução de nome atualizado ( link )

Acho que entendo como a resolução de nomes funciona um pouco melhor do que quando fiz a pergunta. Parece mais provável que houvesse uma causa única (bug Cloudflare) do que várias causas (bugs separados em Heroku, NewRelic, Pingdom e Errplane).