Diagnóstico de DNS

Um diagnóstico de DNS inspeciona como um domínio está delegado e configurado de ponta a ponta, não apenas um tipo de registro. Ele pergunta aos servidores do pai (o TLD) o que publicam sobre seu domínio, depois pergunta diretamente aos seus próprios servidores de nomes e compara os dois. As divergências entre o pai e seus servidores — glue ausente, listas de NS que não coincidem, seriais SOA fora de sincronia, servidores lame ou com recursão aberta — são exatamente os problemas que causam um DNS lento, intermitente ou silenciosamente quebrado. O IPeek executa cada verificação e diz, em linguagem clara, por que cada uma importa e como corrigi-la.

Cada consulta ao seu domínio começa na zona pai — o registro do TLD (por exemplo .br ou .com) — que guarda os registros NS que apontam os resolvedores para seus servidores de nomes. Se esses servidores ficam dentro do seu próprio domínio, o pai também precisa publicar seus endereços IP como "glue", caso contrário os resolvedores enfrentam um impasse do ovo e da galinha. Uma delegação saudável tem o pai e seus próprios servidores concordando no mesmo conjunto de NS, com glue presente onde for necessário. Quando divergem, alguns resolvedores seguem informações desatualizadas e suas alterações parecem funcionar para alguns usuários, mas não para outros.

A RFC 2182 recomenda múltiplos servidores de nomes em redes diferentes para que uma única queda nunca tire seu domínio do ar. Cada um deve responder de forma autoritativa pela sua zona — um servidor "lame" que não faz isso é uma falha de confiabilidade silenciosa. Seus servidores autoritativos também devem recusar recursão a estranhos: um servidor recursivo aberto pode ser abusado para envenenamento de cache e amplificação de DDoS. O IPeek consulta cada um dos seus servidores de nomes diretamente para confirmar que respondem, que respondem de forma autoritativa, que concordam entre si, que suportam TCP e que mantêm a recursão fechada.

O registro SOA carrega o número de série da sua zona e seus valores de temporização; cada servidor de nomes deve reportar o mesmo serial, ou sua zona está fora de sincronia e as alterações se propagam de forma desigual. O serial deve seguir a convenção YYYYMMDDnn, e os temporizadores refresh/retry/expire/minimum devem ficar dentro das faixas recomendadas pelas RFCs. Do lado do correio, os registros MX devem ser nomes de host (nunca IPs avulsas ou CNAMEs) que resolvam para endereços públicos. Por fim, o domínio raiz (seu domínio sem prefixo) deve publicar um endereço, mas não um CNAME, que a RFC 1912 proíbe ao lado de outros registros.