De Olho

dns não resolve

DNS não resolve: o servidor nem chegou a ser chamado.

Um erro de DNS não é um erro do site. É o passo anterior a falhar — a tradução do nome para o endereço — e por isso nada do que fizeres no servidor tem efeito nenhum.

Antes de qualquer pedido a um site, o computador tem de descobrir para que endereço enviar esse pedido. Essa tradução é o DNS, e acontece num sistema distribuído por servidores espalhados pelo mundo, cada um com a sua cópia guardada durante um tempo definido pelo TTL.

Quando o DNS não resolve, o browser mostra uma mensagem sobre não encontrar o endereço IP — nunca um código de estado, porque não houve conversa com servidor nenhum. É a diferença fundamental em relação a um 500 ou a um 503: nesses, o servidor respondeu; aqui não chegou a ser contactado.

A consequência prática é que os sintomas são inconsistentes de propósito. Como cada resolvedor tem a sua cópia, umas pessoas vêem o site e outras não, e a mesma pessoa pode ver os dois estados em minutos diferentes. Isso não é um bug — é como o sistema foi desenhado.

// causas prováveis

Por onde é que isto costuma vir.

Por ordem de frequência e não por ordem de gravidade. A primeira da lista explica mais casos do que as outras todas juntas.

  • Propagação a meio depois de uma mudança

    Os registos foram alterados e os resolvedores ainda têm a versão antiga guardada. Dura o que durar o TTL anterior, e é a razão pela qual se baixa o TTL uns dias antes de migrar.

  • O domínio expirou

    A renovação automática falhou com um cartão caducado e o registo saiu de circulação. O site desaparece por completo, sem erro nenhum do servidor, e resolve-se pagando — depressa, antes do período de resgate.

  • Servidores de nomes errados no registo

    O domínio aponta para os servidores de nomes de um alojamento antigo, onde a zona já não existe. Acontece em migrações em que se mudou a zona sem mudar a delegação, ou o contrário.

  • Um registo apagado ou mal escrito

    Um registo A que ficou com o IP antigo, um CNAME em `www` sem o registo na raiz, um espaço a mais colado ao valor. São erros de edição e são invisíveis até alguém tentar entrar.

  • DNSSEC mal configurado

    Se o DNSSEC está activo e as chaves não batem certo depois de uma mudança de fornecedor, os resolvedores que o validam recusam a resposta — e o site fica em baixo para uns e de pé para outros, o que é dos sintomas mais confusos que há.

// diagnóstico

Passo a passo, do que custa menos ao que custa mais.

Cada passo elimina hipóteses. Saltar um passo poupa dois minutos e costuma custar uma hora — a ordem é a parte que interessa.

  1. 01

    Confirma que o DNS não resolve mesmo

    "Não foi possível encontrar o endereço IP do servidor" é DNS. "A ligação não é privada" é certificado. "Este site está inacessível" com um código de estado é o servidor. As três parecem a mesma coisa a quem se queixa e são problemas diferentes.

  2. 02

    Pergunta directamente a um resolvedor público

    Um `nslookup exemplo.pt 1.1.1.1` ou `dig exemplo.pt @8.8.8.8` salta a cache da tua rede e diz o que o mundo vê. Se o resolvedor público responder com o IP certo e tu não vires o site, o problema é local.

  3. 03

    Limpa a cache local

    `ipconfig /flushdns` no Windows, `sudo dscacheutil -flushcache` no macOS. Reinicia o router se puderes — ele também guarda. É obrigatório sempre que tenha havido mudança nas últimas 48 horas.

  4. 04

    Verifica os servidores de nomes no registo do domínio

    Um `whois` ao domínio diz para onde a delegação aponta e até quando o registo está pago. Se apontar para o alojamento antigo, encontraste a causa — e é uma alteração que se faz no registrar e não no painel de alojamento.

  5. 05

    Confirma os registos A, AAAA e CNAME um a um

    A raiz e o `www` têm de estar os dois definidos, e um deles é quase sempre o que falta. Compara o IP que aparece com o IP do servidor onde o site está mesmo alojado.

  6. 06

    Se tudo bate certo, é propagação — e espera-se

    Nada acelera a propagação do lado de fora. Baixar o TTL agora só ajuda a próxima mudança. O que dá para fazer é confirmar de hora a hora se o resolvedor público já mudou, e avisar o cliente com uma estimativa honesta em vez de silêncio.

O primeiro passo é sempre o mesmo — ver de fora o que o servidor responde de facto. Faz isso aqui, a partir de um servidor em Portugal. Sem conta, sem custo, e não guardamos o que verificares.

verificar_site servidor: PT

// que não volte

Como evitar que volte a acontecer sem dares por isso.

Resolver o incidente é metade do trabalho. A outra metade é a parte que ninguém factura e é a que decide se há um terceiro.

  • Baixa o TTL antes de migrar, não depois

    Pôr o TTL a cinco minutos uns dias antes da mudança transforma uma propagação de horas numa de minutos. Feito depois, não serve de nada — o valor antigo é o que está guardado.

  • Renova o domínio com antecedência e sem depender de um cartão

    É a falha mais evitável de todas e a mais completa: leva o site, o email e tudo o resto. Vale a pena ter os domínios dos clientes numa lista com a data, e não confiar num email automático.

  • Guarda a zona antes de mexer nela

    Uma exportação dos registos antes de qualquer alteração é a diferença entre reverter em dois minutos e reconstruir de memória.

  • Verifica depois de migrar, e continua a verificar

    Uma migração que parece ter corrido bem pode partir para uma parte dos visitantes. Uma verificação automática de fora apanha isso; olhar uma vez no próprio dia não apanha.

// limites

Onde é que esta página encalha.

Uma página de diagnóstico que não diz onde acaba manda-te dar voltas até desistires. Estes são os casos em que não chega.

  • Não verificamos registos DNS. A nossa verificação faz um pedido HTTP e reporta se ele falhou — para inspeccionar a zona, as ferramentas certas são o `dig` e os verificadores de DNS dedicados.
  • Uma falha de DNS parcial é difícil de provar. Se um resolvedor responde bem e outro não, é preciso testar contra vários — e a resposta muda ao longo do dia.
  • Não tratamos de configuração de email. Registos MX, SPF, DKIM e DMARC vivem no mesmo sítio e partem-se nas mesmas migrações, mas o diagnóstico é outro.
  • Se o domínio está em período de resgate, isto é uma questão administrativa e não técnica. Nenhum diagnóstico o resolve — só o pagamento resolve, e cada dia custa mais.

// perguntas

O que nos perguntam a seguir.

Porque é que o site abre para mim e não para o cliente?

Porque estão a usar resolvedores diferentes e um deles ainda tem a resposta antiga guardada. É o comportamento normal durante uma propagação. Um `nslookup` contra um resolvedor público, feito dos dois lados, mostra a diferença em segundos.

Mudar os DNS para a Cloudflare acelera a propagação?

Não acelera a propagação em curso — muda o fornecedor de zona, o que é outra alteração e implica esperar a delegação. Ajuda nas mudanças seguintes, porque as alterações dentro da zona passam a ser quase imediatas.

O que faço enquanto espero pela propagação?

Avisa o cliente com uma estimativa honesta e explica porque é que ele vê uma coisa e outra pessoa vê outra — essa explicação evita metade das mensagens que vêm a seguir. Entretanto, confirma de hora a hora contra um resolvedor público.

// erros vizinhos

Se afinal não era este.

Metade do diagnóstico é perceber que se estava a olhar para o erro errado. Estes três são os que mais se confundem com este.

E se acontecer às três da manhã?

Uma migração de DNS parece correr bem no minuto em que se olha para ela, e parte para uma parte dos visitantes durante horas depois disso. A De Olho vai fazer o pedido a cada minuto a partir de um servidor em Portugal e avisar-te quando ele deixar de chegar ao sítio certo — que é a única forma de apanhar uma propagação que ficou a meio sem ser alguém a queixar-se.

A De Olho abre em 2026 e ainda não dá para usar. Quem estiver na lista de espera fica a saber primeiro e mantém o preço de lançamento enquanto a subscrição durar.

Só te escrevemos sobre o lançamento. Sem spam, e não partilhamos o teu email com ninguém. Como tratamos os teus dados.