Propagação e diagnóstico

Compare resolvedores no mundo inteiro e inspecione as respostas devolvidas.

Pesquisa de registo CAA

No modo de rastreamento iterativo, o resolvedor é ignorado.
Consulta vários resolvedores públicos para comparar as respostas.

Como utilizar corretamente as diferentes opções do motor de pesquisa DNS?

O que é a traçado iterativa?

A traçado executa a resolução passo a passo. O resolvedor consulta primeiro os servidores raiz, depois os do TLD (.com, .br, .pt) e, por fim, os servidores autoritativos da zona pretendida. Em cada etapa, a página mostra o servidor consultado, a resposta, o RCODE e a latência.

  1. 1. Raiz

    Descoberta dos servidores do TLD para o nome solicitado.

  2. 2. TLD

    Referência aos NS da zona (delegação).

  3. 3. Autoritativos

    Resposta final (ou erro) com TTL e latência.

Para que serve?

  • Comparar respostas entre resolvedores e regiões
  • Detetar um cache quente, um TTL demasiado longo ou uma delegação incompleta
  • Explicar diferenças de latência ou um RCODE inesperado

Dica: deixe a traçado desativada para verificações rápidas; ative-a durante investigações ou para preparar um ticket/post-mortem.

O que é a traçado clássica?

A traçado clássica consulta apenas o resolvedor selecionado (UDP ou DoH) e mostra a resposta tal como é percecionada a partir desse ponto da rede. Obtém o RCODE, as secções da resposta e a latência do percurso cliente → resolvedor.

  1. 1. Resolvedor escolhido

    Use o preset ou a configuração personalizada para lançar a consulta exatamente como o seu serviço faria.

  2. 2. Protocolo preservado

    Respeita o transporte selecionado (UDP, TCP ou DoH) para reproduzir o comportamento real.

  3. 3. Resposta detalhada

    Mostra as secções question, answer e authority/additional quando existirem, com TTL e metadados úteis.

Porque utilizá-la?

  • Verificar a visão de um resolvedor específico antes de suspeitar de delegação
  • Confirmar valores em cache e o impacto de um TTL ou de um flush
  • Documentar uma resolução tal como a vê um cliente ou microserviço

Dica: mantenha a traçado iterativa desativada quando auditar um resolvedor específico; ative-a depois para comparar com o percurso raiz → TLD → autoritativo.

Como funciona o teste de propagação?

O teste consulta em paralelo um conjunto de resolvedores públicos (Google, Cloudflare, Quad9, OpenDNS, ISP…) e agrupa as respostas por conteúdo e RCODE. Vê imediatamente quem já aplicou a atualização.

  1. 1. Resolvedores multiponto

    Ative os presets de propagação para consultar vários atores distribuídos pelo mundo.

  2. 2. Comparação automática

    Agrupa respostas idênticas e assinala divergências ou erros específicos de cada resolvedor.

  3. 3. Resumo acionável

    Apresenta um resumo claro, a lista de resolvedores, latências e estado de cada grupo.

Quando usar?

  • Acompanhar a difusão de uma alteração DNS à escala global
  • Identificar caches ainda antigos e decidir um flush direcionado
  • Partilhar um estado de propagação num ticket ou post-mortem

Dica: durante o teste de propagação, a seleção de resolvedor fica bloqueada. Desative o modo para voltar ao diagnóstico unitário.

Informação adicional sobre registos DNS tipo CAA

Um registo CAA define quais autoridades de certificação (CA) estão autorizadas a emitir certificados para um domínio. Funciona como salvaguarda: uma CA não listada deve recusar a emissão. As regras herdam-se: na ausência de CAA num subdomínio, aplica-se o do ápice.
Um registo CAA contém nome, tipo, flag, tag, valor e TTL. O TTL indica quanto tempo a resposta permanece em cache no resolvedor local.

Exemplo de registo DNS tipo CAA

NomeTipoFlagTagValorTTL (s)
@CAA0issue"letsencrypt.org"3600

A zona autoriza Let's Encrypt a emitir certificados. Flag 0 serve para a maioria dos casos. TTL de 3600 corresponde a uma hora.

Exemplos comuns

NomeTipoFlagTagValorFunção
@CAA0issue"digicert.com"Autorizar uma CA
@CAA0issuewild"letsencrypt.org"Autorizar wildcard
@CAA0iodef"mailto:security@exemplo.com"Receber relatórios
@CAA0issue";"Proibir emissão

A tag issue autoriza certificados normais; issuewild aplica-se a wildcard; iodef indica o destino dos relatórios de tentativa não autorizada.

Regras essenciais

Publique CAA no ápice para cobrir todo o domínio. Crie exceções em subdomínios apenas quando necessário.
O destino de MX ou outros serviços não altera o CAA: a decisão depende do nome para o qual o certificado é solicitado.
A flag crítica (128) é para usos avançados: obriga a CA a compreender a tag, caso contrário deve recusar.

TTL em linguagem simples

TTL curto acelera ajustes, útil ao trocar de CA.
TTL médio ou longo reduz consultas aos autoritativos — adequado para política estável.
Reduza o TTL antes da alteração e aumente após validação.

Importante
A herança é chave. Uma regra específica em loja.exemplo.com substitui a do ápice nesse subdomínio; sem regra local aplica-se a regra pai.

Onde usar um registo CAA

No ápice, para definir a política geral. Em subdomínios, para exceções controladas (por exemplo, serviço gerido por terceiros). Teste em seguida a emissão na CA visada.

Evite
Omitir iodef, que facilita notificações.
Autorizar demasiadas CAs, dificultando o controlo.
Deixar CAA antigo ativo após trocar de fornecedor.

Verificar online

Um lookup DNS fornece as tags CAA e o TTL observado na Internet. Depois faça teste local.

Windows

nslookup
set q=caa
exemplo.com
nslookup
set q=caa
server 1.1.1.1
exemplo.com

Linux/macOS

dig caa exemplo.com
dig caa exemplo.com @1.1.1.1

Leitura rápida

A presença de issue/issuewild indica a CA autorizada. Valor ";" impede emissão. TTL elevado explica atraso pós-alteração. Ausência total de CAA significa ausência de restrições.

Procedimento simples

  1. Listar a CA pretendida e eventual necessidade de wildcard.
  2. Publicar CAA no ápice com TTL reduzido.
  3. Adicionar iodef para receber alertas.
  4. Testar a emissão na CA.
  5. Aumentar o TTL após validação.

Dica prática
Mantenha registo dos CAA publicados: data, TTL, motivo e provas de emissão bem-sucedida.

Casos frequentes

Restringir a um fornecedor

Publicar apenas uma tag issue. Certifique-se de que todos os serviços usam essa CA.

Autorizar wildcard

Adicionar issuewild para a mesma CA, mantendo issue para certificados comuns.

Receber alertas

Adicionar iodef com caixa dedicada ou endpoint HTTPS.

Resolução rápida

  1. Se a emissão falhar, confirme que issue/issuewild referem a CA correta.
  2. Se a CA pedir ajuste, verifique herança até ao ápice.
  3. Se a mudança não surtir efeito, aguarde o TTL expirar e limpe caches.

Em resumo, um registo CAA define quem pode emitir certificados. As tags issue, issuewild e iodef cobrem necessidades comuns. A herança orienta a decisão. Um TTL ajustado facilita transições. Verifique via ferramentas online e com nslookup/dig. Assim a política permanece clara e os certificados seguem as regras definidas.