Cuidamos de implementar as mudanças que você sugeriu sip.teltel.ionas perguntas anteriores, mas não melhorou.
O subdomínio hospedado na AWS às vezes não resolve para 8.8.8.8
8.8.8.8 Falha ao resolver nossos subdomínios aleatoriamente
8.8.8.8 retorna NXDOMAIN aleatoriamente para todos os nossos subdomínios
ATUALIZAR:
- Até criamos um subdomínio de teste
xip.teltel.ioque é configurado exatamente da mesma maneirasip.teltel.ioe ao resolver esse domínio para 8.8.8.8 ele funciona bem sempre. A única diferença entre sip.teltel.io e xip.teltel.io é a carga: tragorecebe o tráfego de nossos clientes exipapenas nossas solicitações de teste.
Como você pode explicar isso?
- Aqui está o que também notamos: Ao resolver para 8.8.8.8 a partir de um wi-fi local ou de um hotspot pessoal, etc., às vezes falha. As respostas são recebidas destes endereços IP do Google:
74.125.46.10
74.125.112.1
74.125.112.9
74.125.x.x
74.125.z.z
74.125.w.w
Mas ao resolver para 8.8.8.8 a partir de um servidor na AWS ou DO, sempre é bem-sucedido. As respostas são recebidas de diferentes endereços IP do Google:
172.253.199.4
172.253.1.194
172.217.33.132
O Google dá maior prioridade para grandes clientes como AWS ou DO versus o público...? Ou existe uma explicação diferente?
- Capturamos o tráfego executando um tcpdump (tcpdump udp e porta 53) e percebemos que quando o Google não consegue resolver, nossos servidores de nomes nunca recebem uma solicitação do Google.
- Aqui você mesmo pode testar os loops:
Isso às vezes falha com "trago" -while true; do dig A 42894078.sip.teltel.io @8.8.8.8; done;
Isso é sempre bom com "xip"-while true; do dig A 42894078.xip.teltel.io @8.8.8.8; done;
Você pode nos ajudar a resolver isso? Tudo parece bastante misterioso para nós.
Obrigado!