WHOIS, DNS e IP: investigar um site que não abre

Imagine que a página inicial abre, mas o endereço com www não funciona. Consultar apenas se o domínio está registado não explica a diferença. É preciso seguir o nome exato que falha, ver como o DNS encontra o destino e só depois investigar a ligação e o conteúdo servido.

Se ainda não comparou outro navegador ou outra rede, comece pelo guia O site está em baixo ou é a minha ligação?. Aqui vamos aprofundar as consultas. Não precisa de instalar programas nem de usar comandos: pode acompanhar com as ferramentas do site.

Separe o endereço nas partes certas

Em https://www.example.com/contacto, https é o protocolo, www.example.com é o nome do servidor e /contacto é o caminho da página. Neste exemplo, o domínio registado é example.com. Estes nomes servem apenas para ilustrar o diagnóstico; os resultados descritos abaixo não são consultas reais.

• Para WHOIS: consulte o domínio registado. Noutras extensões, este pode ter mais partes, como num domínio terminado em .com.pt.
• Para DNS: consulte o nome exato que o navegador tenta abrir, incluindo www ou outro subdomínio. Não inclua o protocolo nem o caminho.
• Para testar a página: conserve o endereço completo. Uma falha em /contacto pode existir mesmo quando o nome e a página inicial funcionam.

1. Confirme o registo do domínio

Abra a consulta WHOIS / RDAP, introduza o domínio e veja os dados públicos disponíveis. Registe a entidade de registo, as datas, os estados e os servidores de nomes apresentados. O RDAP fornece dados de registo, não uma medição do funcionamento do site; também não garante que a identidade do titular seja pública.

Se o domínio é seu: compare as datas com a renovação no painel da entidade onde o registou. Uma data isolada não explica todos os estados de um domínio. Os procedimentos e prazos dependem da extensão; não aplique automaticamente a um domínio .pt uma regra descrita para outra extensão.

Nos estados EPP, clientTransferProhibited bloqueia transferências e pode ser uma proteção normal. Já clientHold indica que o domínio não deve ser ativado no DNS. A lista da ICANN ajuda a interpretar o estado exato. Se a consulta não devolver dados, pode haver uma limitação do serviço ou da extensão: não conclua logo que o domínio está disponível para registo.

2. Consulte o nome que falha no DNS

Abra Consultar DNS. Comece por A e AAAA, que procuram endereços IPv4 e IPv6. Consulte depois CNAME se precisar de acompanhar um nome alternativo. Use NS no domínio para investigar os servidores DNS responsáveis. Os registos MX referem-se ao email: a sua ausência, por si só, não impede um site de abrir.

Exemplo: só o endereço com www falha. Consulte separadamente example.com e www.example.com. Compare os destinos e o tipo de resposta. Se um nome tem destino e o outro não, há uma pista para rever a configuração desse subdomínio; ainda é preciso confirmar a resposta e a configuração no fornecedor DNS.

Um resultado pode conter um CNAME que aponta para outro nome. Siga esse destino com uma nova consulta: www.example.com pode apontar para example.com, que por sua vez tem um endereço IP. Compare a cadeia inteira. A ausência de um CNAME também pode ser normal, por exemplo quando o nome tem diretamente um registo A.

Como ler uma resposta vazia ou um erro?

• Sem registos do tipo escolhido: não equivale a «domínio inexistente». Pode não haver AAAA e haver A, ou não existir MX porque o domínio não recebe email.
• NXDOMAIN: o resolvedor respondeu que o nome consultado não existe. Confirme a escrita e o subdomínio, e compare outra rede ou consulta antes de atribuir a causa.
• SERVFAIL: o resolvedor não conseguiu concluir a consulta. Não significa que o domínio esteja livre nem identifica sozinho a causa.

Uma configuração DNSSEC incoerente pode produzir SERVFAIL. O DNSSEC permite verificar a autenticidade das respostas DNS; não é o certificado HTTPS. Após uma mudança de fornecedor DNS, uma diferença entre os dados de assinatura publicados e os esperados é uma hipótese que o responsável técnico deve investigar. A documentação de diagnóstico DNSSEC descreve as verificações; não desative proteções apenas para esconder o erro.

3. Compare respostas e respeite a cache

A ferramenta consulta um resolvedor público da Cloudflare. O navegador pode usar outro resolvedor, definido pelo sistema, pelo router ou pelo próprio navegador. Por isso, uma resposta correta na ferramenta não demonstra que a sua rede já recebe a mesma informação.

Anote o nome, o tipo, o destino, o TTL e a hora. O TTL é a duração de cache indicada para o registo. Por exemplo, 300 segundos correspondem a cinco minutos. Esse número não garante que todas as redes vão apresentar uma mudança ao mesmo instante: existem caches e etapas diferentes. Reduzir agora o TTL também não faz desaparecer uma resposta antiga que já ficou guardada noutro local.

Exemplo: acabou de mudar de alojamento. Uma rede pode ainda devolver o destino antigo, enquanto outra já devolve o novo. Compare os resultados com a configuração esperada no fornecedor, em vez de assumir que qualquer diferença é uma avaria. Se as respostas continuarem incoerentes, reúna os dados para o suporte; esperar indefinidamente não corrige um registo errado.

4. Distinga o seu IP do destino do site

Em Qual é o meu IP?, vê o endereço público da sua ligação. Serve para descrever a origem de um acesso, por exemplo ao investigar um bloqueio com o suporte. Não é o IP do site consultado. Evite publicar esse endereço num fórum quando basta enviá-lo por um canal de suporte apropriado.

Já o IP devolvido por uma consulta DNS identifica um destino associado ao nome. Quando há um proxy ou uma CDN à frente do alojamento, pode ser o endereço desse intermediário. Na configuração com proxy da Cloudflare, os visitantes recebem endereços da rede Cloudflare. Encontrar um IP diferente do servidor contratado pode, portanto, ser esperado.

Consultar esse IP por RDAP pode indicar a entidade a quem o bloco de endereços está atribuído. Não identifica necessariamente o proprietário do conteúdo. Vários sites podem partilhar infraestruturas, e conhecer o destino não confirma que uma aplicação, base de dados ou formulário está a funcionar.

5. Termine pela ligação HTTPS e pela página

Se o DNS encontra o destino esperado, volte ao endereço completo no navegador. Um aviso de certificado pode indicar validade expirada, um nome que não corresponde ou uma cadeia de confiança incompleta. Confirme também o relógio do dispositivo. O certificado e o registo do domínio são elementos diferentes: renovar um não renova automaticamente o outro.

Se aparece uma página de acesso negado ou um desafio de segurança, já existe uma resposta a esse pedido. Investigue a regra de acesso e o contexto. Um verificador automático pode ser recusado enquanto uma pessoa consegue abrir o site; um resultado bloqueado deve manter essa incerteza, sem declarar uma falha geral.

Que informação devo enviar ao suporte?

Prepare o endereço completo, a hora com fuso horário, a mensagem exata, as redes testadas e as respostas DNS com nome e tipo. Diga o que mudou recentemente, como alojamento, servidores DNS ou certificado. Esta sequência ajuda a encaminhar o caso para a entidade do registo, o fornecedor DNS ou o alojamento. Não envie palavras-passe, códigos de acesso ou cookies de sessão.

Preciso de alterar o DNS para investigar?

Não. Consultar registos e comparar resultados não exige mudar a configuração do domínio. Se gere o site e encontrar uma diferença, confirme primeiro qual é o valor correto e qual é o fornecedor responsável. Uma alteração feita por tentativa pode afetar outros serviços, incluindo email, que não tinham qualquer problema.