Possíveis motivos para domínios ocasionalmente inacessíveis

Question

Estou com sintomas semelhantes aos da outra pergunta . Ou seja, os povos estão reclamando que um nome de domínio está inacessível. E então, de repente, começa a funcionar depois de um tempo. Mas duvido que seja por causa de servidores DNS não confiáveis. Eles são do meu registrador de nomes de domínio, o que é muito popular no meu país.

Poderia haver outras razões para isso? É um subdomínio, como em sub.example.com e eu faço funcionar com o curinga DNS record. Isso poderia ser uma razão? Talvez alguns antigos servidores DNS não entendam esse tipo de coisa? A outra razão que posso pensar são alguns problemas temporários na internet, como alguns hosts não podem acessar os outros? Ou alguns servidores DNS filtrando registros por algum critério?

UPD A configuração é simples, sem balanceadores de carga, sem clusters, sem round-robin DNS servers. E estou falando de servidor publicamente disponível. Os usuários são os usuários da internet. Estou gerenciando os dois example.com e sub.example.com . Eles estão em uma zona DNS .

UPD Ou, talvez, afinal, é por causa do registrador de domínios. Seus servidores respondem com um tempo limite:

>nslookup sub.example.com ns.domain.registrar.com
DNS request timed out.
    timeout was 2 seconds.
Server:  UnKnown
Address:  52.16.198.15

Name:    sub.example.com
Address:  51.59.10.10

Suponho que nem todos os servidores DNS tolerariam tempos limite, você não acha?

    

Answer 1

Dos comentários acima, isso definitivamente soa como um problema de DNS. Eu podia ver isso sendo causado por registros de cache de hosts, os próprios servidores DNS armazenando registros de cache (recursivamente), ou mesmo se você tiver um balanceador de carga como um dispositivo F5 que poderia estar fazendo o cache. Um que me morda mais vezes que eu admito, são os proxies da Web realizando o cache de resultados resolvidos.

Ao visitar um site, você tem duas partes básicas, a viagem e o destino. A jornada é o estágio de pré-conexão e o destino é a conexão real com o servidor. Você precisa isolar a parte de pré-conexão da equação da conexão real.

Depois de resolver o endereço IP do site, tente digitar o endereço IP em vez do nome do domínio no seu navegador. Faça seus testes de ping e traceroutes contra este endereço IP. O endereço IP está respondendo? Ele está respondendo continuamente durante um período de tempo (ping -t x.x.x.x no Windows) ou está subindo e descendo? Se você conseguir o site com o IP e não o nome do host, é o seu DNS. Se você não consegue fazer isso, você tem um problema de conectividade. Se isso for intermitente para o nome de domínio ou o IP, você provavelmente terá um problema de balanceamento de carga intermitente (como servidores DNS round-robin ou clusters configurados incorretamente) ou um problema de conectividade intermitente, como um problema de camada 1 ou 2 .

Outra coisa que você pode adicionar à sua caixa de ferramentas é um site chamado isitdownrightnow.com, especificamente projetado para ajudar a separar um problema do sistema ou um problema mais global.

Algumas dessas informações que forneci estão apenas filmando cegamente no escuro, já que este é um processo contínuo de solução de problemas e as informações são limitadas até o momento. Se você puder postar mais informações como comentários, tenho certeza de que podemos ajudar você a se endireitar.

    

Answer 2

Para o futuro, vou apenas adicionar algumas dicas da minha experiência:

• para diagnosticar corretamente o problema é melhor você ter acesso ao servidor DNS
• os servidores DNS relevantes são os SOA -s e os servidores de nomes de armazenamento em cache que os usuários usam
• ajuda a ter caixas Unix e Windows para diagnósticos.
• O servidor DHCP desempenha um grande papel, se fornecer servidores DNS aos usuários
• Conflitos de IP podem gerar efeitos estranhos (e todos os dispositivos na rede local são suspeitos)

Em caixas Unix você usa

dig SOA example.com @8.8.8.8
dig SOA sub.example.com @my.domain.name.registrar
dig sub.example.com @sub.example.com
...

Nas caixas do Windows, você usa

ipconfig.exe /displaydns >logfile.txt
ipconfig.exe /flushdns         <=WITHOUT THIS YOU GET DISTORTED REALITY 
nslookup sub.example.com
nslookup sub.example.com other.name.server
nslookup.exe -q=soa sub.example.com

Eu não entendi completamente, quem é SOA (Source Of Authority) para example.com e para o seu sub.example.com , e se eles são diferentes de o DNS (-es) de cache que seus usuários usam - se não, todos os três ou mais devem ser dig -ged. O DHCP pode fornecer vários DNS-es para seus usuários e eles podem ter opiniões diferentes sobre os registros (caches).

No unix e no Windows, você pode criar tarefas agendadas / agendar tarefas para registrar dig resultados uma vez por minuto em algum arquivo de log e, em seguida, grep através dele coletar algumas anomalias difíceis de capturar. (Isso me ajudou a provar em um caso que nossos servidores, de fato, às vezes não podem pingar uns aos outros na rede local!)