Rede

Como consultar DNS: registros, TTL e erros

ToolMellow · Atualizado em 6 de outubro de 2026

Uma consulta DNS pede a um resolvedor um tipo específico de registro para um nome específico. Use o verificador de DNS do ToolMellow para examinar endereços, aliases, rotas de e-mail ou registros de texto retornados, comparar os provedores selecionados e guardar uma observação datada. Comece pelo nome DNS exato e pelo tipo adequado à tarefa.

A ferramenta consulta Cloudflare e Google Public DNS pelas localidades de consulta disponíveis no ToolMellow. Os resultados descrevem essas solicitações; não estabelecem o que cada usuário, dispositivo ou resolvedor vê. Este guia explica os controles, a leitura dos resultados e o que investigar quando um registro difere do valor esperado. Todos os nomes, endereços e valores abaixo são exemplos ilustrativos, não medições ao vivo.

Consultar DNS

Como fazer uma consulta DNS

Abra o verificador de DNS e espere a configuração da conexão carregar. Informe um nome como www.example.com, selecione o tipo, escolha um ou ambos os provedores e as localidades disponíveis. Clique em Verificar DNS para enviar a solicitação. Abrir a página ou editar o nome não consulta seus registros automaticamente.

Antes de interpretar os valores, leia o provedor, a localidade, o status e o horário. Se souber o valor necessário, informe-o no campo opcional de valor esperado e escolha Correspondência exata ou Contém. Baixar relatório de DNS salva a observação atual em dns-results.json; guarde o arquivo para comparar antes e depois.

Cada consulta usa um nome DNS e um tipo de registro. Consulte A e AAAA separadamente para investigar as duas famílias de endereços.
O padrão seleciona A, ambos os provedores e a localidade principal do ToolMellow. As localidades disponíveis vêm da configuração atual do serviço.
Alterar nome, tipo, provedor ou localidade apaga o resultado anterior. Editar o valor esperado ou o modo apenas compara o resultado atual novamente, de forma local.

Escolha o tipo de registro DNS para a tarefa

Registros DNS respondem a perguntas diferentes. Uma consulta A não pede todos os registros de um domínio, e uma consulta MX não envia e-mail de teste. O seletor oferece nove tipos. A comparação de valores esperados aceita os oito tipos de consulta direta abaixo; resultados PTR podem ser examinados e baixados, mas sua comparação de valor esperado não está disponível.

Escolha o tipo de registro DNS para a tarefa
Tipo	O que contém	Interpretação prática
A	Dados de endereço IPv4	Confira o IPv4 retornado para o nome solicitado; isso não testa o site nesse endereço.
AAAA	Dados de endereço IPv6	Confira IPv6 separadamente de A; um destino IPv4 funcionando não estabelece que IPv6 funciona.
CNAME	Nome de destino de um alias	Examine o alias e a grafia retornada. Um alias DNS não cria por si só um redirecionamento HTTP.
MX	Preferência do servidor de e-mail e nome de destino	Leia a preferência e o nome de host. A presença do registro não comprova a entrega do e-mail.
TXT	Texto transportado no DNS	Examine dados de verificação ou de e-mail no nome exato indicado pelo provedor.
NS	Nomes dos servidores de nomes	Examine os nomes retornados; eles são distintos do provedor recursivo selecionado para a consulta.
SOA	Metadados de autoridade da zona	Examine os metadados e o contexto de respostas negativas; o horário da consulta não é o horário de edição do registro.
CAA	Dados de autorização de autoridades certificadoras	Examine a autorização publicada; isso não testa a validade de um certificado ou de HTTPS.
PTR	Um ponteiro de nome DNS reverso	Informe o nome completo do registro DNS reverso. Aqui não são aceitos um IP literal nem a comparação de valor esperado.

RFC 1035: implementação DNS e formatos de registros RFC 3596: extensões DNS para IPv6 RFC 8659: autorização de autoridades certificadoras

Informe o nome DNS correto, incluindo nomes TXT e IDNs

Use o nome ao qual o registro DNS pertence, sem esquema de URL, caminho, endereço de e-mail ou porta. O domínio raiz e seu nome www são entradas distintas. As instruções de verificação podem exigir um subdomínio ou um nome com prefixo de sublinhado; consultar TXT na raiz não encontra automaticamente TXT nesses outros nomes.

O verificador remove espaços nas extremidades, reconhece variantes Unicode de ponto aceitas, retira um ponto raiz final, converte nomes internacionalizados aceitos para ASCII com domainToASCII do Node e transforma o nome em minúsculas. Exige pelo menos dois rótulos, cada um com até 63 caracteres ASCII após a conversão e um total de até 253. Rótulos comuns aceitam letras, algarismos e hífens internos. Os rótulos de serviço aceitos com prefixo de sublinhado são permitidos, mas não sublinhados internos arbitrários.

Informe o nome DNS correto, incluindo nomes TXT e IDNs
Entrada ilustrativa	Uso	Detalhe da entrada
`example.com`	Registros do domínio raiz	Selecione o tipo necessário; isso não lista todos os tipos ou subdomínios.
`www.example.com.`	Registros do nome www	O ponto raiz final é aceito e removido do nome normalizado da consulta.
`_dmarc.example.com`	Observação TXT relacionada ao DMARC	Escolha TXT. Esta consulta não avalia toda a descoberta de política DMARC nem o alinhamento da mensagem.
`selector._domainkey.example.com`	Observação TXT relacionada ao DKIM	Substitua selector pelo seletor fornecido pelo serviço de e-mail.
`bücher.example`	Entrada de nome internacionalizado	IDNs aceitos são convertidos para um nome compatível com ASCII; confira o nome normalizado no resultado.
`10.113.0.203.in-addr.arpa`	Entrada de nome de registro PTR	Os octetos IPv4 aparecem em ordem inversa neste exemplo de nome DNS reverso; a comparação esperada não está disponível.
`https://example.com/path`, `203.0.113.10`, `*.example.com`	Formatos de entrada rejeitados	Use um nome DNS. Para um IP literal, use a ferramenta separada de consulta IP ou DNS reverso.

RFC 5891: nomes de domínio internacionalizados Node.js: conversão URL domainToASCII RFC 1035: implementação DNS e formatos de registros RFC 6376: assinaturas DKIM e busca de chave por seletor RFC 9989: descoberta de políticas e alinhamento DMARC

Provedores recursivos e servidores autoritativos têm funções diferentes

Um servidor de nomes autoritativo publica os dados de uma zona DNS. Um resolvedor recursivo obtém respostas para seus clientes e pode reutilizar informações em cache. Selecionar Google Public DNS ou Cloudflare escolhe o serviço recursivo desta observação; não significa que ele hospede sua zona ou seja o servidor autoritativo do domínio.

O ToolMellow envia solicitações do servidor ou de uma sonda configurada aos endpoints HTTPS fixos do provedor e lê suas respostas JSON. Esse formato JSON definido pelo provedor difere das mensagens binárias DNS padronizadas para DNS sobre HTTPS. A consulta não muda o DNS do dispositivo, não consulta um servidor arbitrário que você informe nem rastreia cada delegação desde a raiz.

RFC 1034: nomes de domínio, resolução e cache RFC 8484: consultas DNS sobre HTTPS Google Public DNS: API JSON para DNS sobre HTTPS Cloudflare 1.1.1.1: solicitações DNS sobre HTTPS com JSON

Leia nomes de registros, TTLs e detalhes da observação em conjunto

Cada linha de resposta inclui o nome do registro, o tipo, o TTL retornado em segundos e os dados textuais. Leia o nome junto com o valor: uma resposta recursiva pode conter uma cadeia de aliases e um endereço do destino do alias. Um CNAME auxiliar ou outro tipo não substitui o tipo solicitado. Expanda Registros de autoridade para entender o contexto de uma resposta negativa ou de uma referência a outros servidores.

Cada resultado de provedor e localidade tem um horário de observação e uma duração. O horário descreve esta consulta, não quando o administrador alterou o DNS pela última vez. A duração inclui o percurso da solicitação e o trabalho HTTP e de processamento; não é uma medição exclusiva de DNS na sua conexão. Se uma falha impedir o retorno de registros ou indicadores, considere essas informações indisponíveis em vez de inventar seus valores.

RFC 1035: implementação DNS e formatos de registros RFC 2308: cache negativo de consultas DNS

Interprete os status DNS sem confundir ausência e falha

Uma resposta negativa válida e uma solicitação que não pôde ser concluída pedem acompanhamentos diferentes. No ToolMellow, a classificação positiva NOERROR contém uma resposta do tipo solicitado. Outras respostas DNS bem-sucedidas são classificadas pelo contexto SOA, CNAME ou NS. A tabela explica o status visível sem tratar toda resposta vazia como um domínio inexistente.

Uma resposta truncada está incompleta mesmo que um trecho contenha o texto esperado. A ferramenta marca a comparação como inconclusiva diante de truncamento ou falhas operacionais. Um provedor pode responder enquanto outro falha; preserve os dois resultados em vez de tomar a falha como prova de ausência do registro.

Interprete os status DNS sem confundir ausência e falha
Status ou condição	Significado neste verificador	Próximo passo útil
NOERROR	A resposta bem-sucedida contém uma resposta do tipo solicitado	Examine cada valor relevante, seu nome e TTL; o sucesso do DNS não testa o serviço de destino.
NXDOMAIN	O resolvedor informa que o nome DNS consultado não existe	Confira a grafia e o nome previsto. Não é uma consulta de disponibilidade para registro de domínio.
NODATA	Não há resposta do tipo solicitado; a resposta bem-sucedida tem SOA em Authority	Veja se esse nome deveria ter esse tipo. A ausência de AAAA não equivale a um domínio inexistente.
ALIAS_ONLY	Depois da verificação SOA, há CNAME sem resposta do tipo solicitado	Examine o alias e investigue seu destino; uma resposta A com apenas CNAME não fornece o A esperado.
REFERRAL	Após as classificações anteriores, falta a resposta solicitada, mas há NS em Authority	Examine Registros de autoridade; não é uma resposta completa do registro solicitado.
EMPTY_ANSWER	Não há resposta solicitada nem contexto SOA, CNAME ou NS reconhecido	Guarde os detalhes; não mude o status para NXDOMAIN por conta própria.
SERVFAIL ou REFUSED	O servidor DNS informa falha ou recusa	Investigue o provedor e a configuração; o status isolado não identifica uma causa específica.
Erro HTTP, tempo esgotado, resposta malformada ou falha de sonda	A observação não pôde ser concluída de forma confiável	Confira as informações de conexão e repita a consulta quando apropriado; a ausência do registro não foi comprovada.
Truncada / TC	O provedor informa uma resposta incompleta	Trate a comparação como inconclusiva e preserve o indicador de resposta parcial.

RFC 2308: cache negativo de consultas DNS Google Public DNS: API JSON para DNS sobre HTTPS Cloudflare 1.1.1.1: solicitações DNS sobre HTTPS com JSON

O que o TTL significa depois de mudar um registro DNS

O TTL expressa uma duração de cache em segundos. Um resolvedor recursivo pode retornar o tempo restante das informações armazenadas; por isso, respostas com os mesmos dados podem mostrar TTLs diferentes. O número não é uma contagem regressiva até que todos os resolvedores do mundo usem o novo valor.

Respostas positivas, negativas e informações de delegação podem ter históricos de cache separados. Reduzir o TTL agora não encurta retroativamente a duração atribuída a uma cópia já armazenada. Alguns resolvedores também podem servir dados expirados conforme políticas de resiliência especificadas. Uma nova consulta fornece outra observação, não um certificado de que todo cache está atualizado.

Para uma mudança planejada, confirme o nome e os valores com a hospedagem DNS, guarde observações antigas e novas e repita as verificações relevantes em intervalos úteis. Planeje a verificação com as instruções do provedor e o contexto anterior de cache. Uma afirmação geral de 24 ou 48 horas não descreve toda mudança DNS.

RFC 2181, seção 8: tempo de vida RFC 2308: cache negativo de consultas DNS RFC 8767: servir dados DNS expirados

Por que o acordo entre provedores não comprova propagação mundial

Google e Cloudflare podem retornar respostas diferentes por suas observações em cache ou por seu comportamento de resolução. Respostas autoritativas dependentes da localidade também podem influenciar. Primeiro compare o mesmo nome normalizado e tipo nos horários registrados; depois examine status, nomes, valores e TTLs. Uma diferença não identifica automaticamente a resposta correta.

Cada consulta permite selecionar até quatro localidades configuradas, mas somente as listadas na interface estão disponíveis. Se uma aparecer, ambos os provedores são consultados por essa localidade. A região declarada não é geografia confirmada de forma independente quando seu indicador de verificação é false. Não deduza uma rede mundial de sondas do número de provedores nem do limite de seleção.

O acordo demonstra apenas acordo entre essas observações. Seu dispositivo, outra rede ou um resolvedor corporativo privado podem ver outra resposta, especialmente com caches locais ou visões DNS diferentes por rede. Use um serviço de várias localidades com o alcance adequado ou os diagnósticos da sua rede quando precisar dessas perspectivas.

RFC 1034: nomes de domínio, resolução e cache RFC 8767: servir dados DNS expirados

Compare valores literalmente com Correspondência exata ou Contém

A comparação examina os valores de Answer do tipo solicitado e aceito por essa função. Correspondência exata exige que todo o texto retornado seja igual ao esperado; Contém exige que inclua a substring esperada. Os dois distinguem maiúsculas de minúsculas. Um único valor correspondente basta para marcar como correspondente o resultado daquele provedor e localidade, mesmo que outros valores difiram. Isso não estabelece que todo o conjunto de registros seja igual à configuração prevista.

A comparação não remove espaços, aspas nem pontos finais, não normaliza a escrita IPv6 nem analisa a sintaxe das políticas DNS. Não aceita expressões regulares. A comparação de nomes DNS pode ignorar maiúsculas no protocolo, enquanto esta comparação de strings as distingue. Para igualdade literal, use a representação retornada e leia os dados completos antes de tomar uma substring curta como evidência.

NXDOMAIN e NODATA normalmente são comparados como diferentes quando falta o valor solicitado; são observações negativas válidas, não falhas de solicitação.
Resultados falhos ou truncados são inconclusivos. A comparação também é indisponível para texto esperado vazio, acima de 4096 unidades de string JavaScript, ou para PTR.
O texto esperado fica nesta aba e no relatório baixado. Não é enviado com a consulta DNS. Uma correspondência de texto não prova validação DNSSEC nem propriedade do domínio.

Compare valores literalmente com Correspondência exata ou Contém
Dados retornados ilustrativos	Texto esperado	O que a comparação mostra
A: `203.0.113.10`	`203.0.113.10`	Correspondência exata corresponde a esse valor; outras respostas A podem conter outros endereços.
CNAME: `target.example.com.`	`target.example.com`	O ponto final causa diferença exata; Contém encontra a substring.
MX: `10 mail.example.com.`	`mail.example.com`	A preferência e o ponto final causam diferença exata; Contém só verifica um fragmento textual.
TXT: `"verification=sample-token"`	`verification=sample-token`	As aspas incluídas no retorno causam diferença exata; Contém pode achar o fragmento.
CNAME: `Target.example.com.`	`target.example.com.`	A diferença de maiúsculas altera a comparação literal exata, mesmo que a igualdade de nomes DNS tenha outra semântica.
TXT: `"part-one" "part-two"`	`part-onepart-two`	A função não junta trechos entre aspas nem interpreta uma política completa.

RFC 4343: nomes DNS sem distinção de maiúsculas

Leia o indicador de dados autenticados DNSSEC junto com sua fonte

A indicação Autenticado reflete o indicador AD do resolvedor recursivo selecionado. É esse resolvedor que afirma que os dados estão autenticados; o ToolMellow não verifica independentemente as assinaturas DNSSEC nem a cadeia de confiança. Confiar na afirmação também depende de confiar no resolvedor e no canal que transporta sua resposta.

Não autenticado significa que o provedor não afirmou AD. Dados sem assinatura podem produzir esse resultado; o indicador isolado não estabelece um domínio defeituoso ou malicioso. SERVFAIL também exige investigação, não um diagnóstico automático de DNSSEC. O verificador solicita dados de resposta relacionados a DNSSEC com a verificação habilitada no provedor, mas não realiza uma auditoria DNSSEC completa nem um teste de vazamento DNS do navegador.

RFC 4035: DNSSEC e afirmações de dados autenticados Google Public DNS: API JSON para DNS sobre HTTPS Cloudflare 1.1.1.1: solicitações DNS sobre HTTPS com JSON

Confira o DNS do site antes de investigar hospedagem e HTTPS

Se um site aponta para um destino antigo, consulte o nome de host exato usado pelos visitantes. Compare A e AAAA separadamente e examine CNAME para um alias como www. Não suponha que o domínio raiz e www tenham a mesma configuração. Compare o resultado com os registros previstos nas instruções de hospedagem, incluindo o destino de alias necessário.

Um valor DNS aparentemente correto é uma parte do diagnóstico do site. Redirecionamentos HTTP, roteamento do host virtual, validade do certificado e respostas da aplicação precisam de verificações próprias. CNAME é um alias no DNS; levar um visitante a outra URL é comportamento HTTP. CAA trata de autorização de autoridades certificadoras; sua presença não confirma que o site atual sirva um certificado válido.

RFC 1035: implementação DNS e formatos de registros RFC 8659: autorização de autoridades certificadoras

Consulte TXT de verificação, SPF, DKIM e DMARC no nome certo

Para verificar um domínio, copie o nome do registro das instruções do serviço e escolha TXT. Compare o registro retornado completo com o token exigido, considerando as aspas e os trechos exibidos. Encontrar o token é evidência útil, mas o serviço solicitante aplica seu próprio processo de verificação de propriedade.

A política SPF usa TXT no domínio de e-mail pertinente. A consulta de chave DKIM usa um nome específico de seletor, como selector._domainkey.example.com; obtenha o seletor do serviço de e-mail em vez de adivinhar. Uma verificação relacionada a DMARC costuma começar com TXT em _dmarc.example.com. A descoberta moderna de políticas DMARC e o alinhamento de identificadores incluem outras regras que uma observação TXT isolada não avalia.

MX descreve o roteamento de e-mail, enquanto esses mecanismos TXT têm funções diferentes. O verificador não segue todos os include SPF, não valida uma mensagem assinada, não avalia toda a descoberta de políticas DMARC, não analisa relatórios DMARC nem testa a entrega. A presença do registro ou uma correspondência de substring não substitui essas verificações.

RFC 7208, seção 3.1: políticas SPF em TXT RFC 6376: assinaturas DKIM e busca de chave por seletor RFC 9989: descoberta de políticas e alinhamento DMARC

Entenda a privacidade da consulta e compartilhe um relatório útil

O nome e o tipo consultados passam pelo intermediário do ToolMellow ou pela sonda selecionada até o resolvedor público escolhido. O resolvedor vê o endereço de rede da sonda; o ToolMellow não encaminha os cabeçalhos de IP do visitante. A hospedagem ainda recebe os metadados habituais de solicitações. HTTPS não torna toda a atividade anônima nem estabelece uma política de zero logs; o próprio nome pode ser sensível.

O texto esperado é comparado localmente e pode aparecer como expectedComparison em dns-results.json. Antes de compartilhar, examine o nome consultado, os dados retornados e o texto esperado, principalmente tokens de verificação. Envie a observação relevante ao destinatário previsto em vez de assumir que todo valor exportado serve para publicação.

Ao pedir suporte, inclua nome e tipo exatos, configuração prevista, provedor e localidade, horário da observação, status, dados relevantes de Answer e Authority e qualquer resultado truncado ou falho. O relatório baixado é uma fotografia da consulta; a ferramenta não mantém histórico de registros no servidor nem exporta toda sua zona DNS.

Investigue passo a passo uma resposta DNS ausente ou inesperada

Comece por conferir o nome normalizado do registro e o tipo selecionado nas instruções da hospedagem DNS. Depois distinga uma resposta negativa de uma solicitação falha, leia aliases e detalhes de Authority e compare ambas as observações dos provedores. Se usou um valor esperado, confira o texto completo e o modo de comparação antes de concluir que a configuração difere.

Depois de uma mudança, guarde um relatório e faça verificações posteriores deliberadas. A ferramenta não repete consultas automaticamente, e repetir solicitações não esvazia todos os caches. Use Tentar conectar novamente quando oferecido para problemas de configuração, respeite os avisos de limite e faça uma nova consulta quando apropriado. Cancelar interrompe o trabalho pendente no cliente e transmite o cancelamento aos serviços que processam a consulta, mas não desfaz uma consulta já enviada.

Use as ferramentas separadas de consulta IP ou DNS reverso quando partir de um endereço, e os diagnósticos DNS locais do sistema operacional para investigar o percurso do resolvedor desse dispositivo. Este verificador não enumera todos os subdomínios, não oferece SRV, DS, DNSKEY ou ANY, não transfere uma zona nem avalia disponibilidade de registro de domínio. Escolha o diagnóstico de acordo com a pergunta antes de atribuir um resultado mais amplo a uma resposta bem-sucedida.

Perguntas frequentes

Como consultar todos os registros DNS de um domínio?

Faça consultas separadas para os nomes e tipos aceitos relevantes para sua tarefa. O ToolMellow usa um nome e tipo por solicitação; não enumera todos os subdomínios, não transfere a zona nem oferece um inventário completo de todos os registros.

Por que Google e Cloudflare mostram resultados DNS diferentes?

Seus históricos de cache e seu comportamento de resolução podem diferir, e respostas autoritativas podem depender da localidade. Compare o mesmo nome normalizado e tipo, horários, status, nomes de registros, valores e TTLs. A diferença isolada não identifica a resposta correta.

O TTL informa quando a propagação DNS termina?

Não. O TTL retornado informa a duração de cache do dado observado. Caches positivos e negativos, delegações e políticas de dados expirados podem afetar outras observações. Ele não estabelece um horário de conclusão mundial.

Qual a diferença entre NXDOMAIN e NODATA?

NXDOMAIN informa que o nome consultado não existe. NODATA significa ausência de resposta do tipo solicitado; o verificador identifica isso por SOA em Authority com resposta bem-sucedida. Um nome pode ter A sem retornar dados AAAA.

Por que Correspondência exata falha no meu TXT ou CNAME?

A função compara todo o texto retornado e distingue maiúsculas de minúsculas. Aspas, espaços, pontos finais, preferência MX e apresentação podem influenciar. Examine o valor completo; Contém verifica apenas uma substring e não valida um registro ou uma política inteira.

Uma correspondência significa que todos os registros estão corretos?

Não. Um valor correspondente em Answer do tipo solicitado e aceito basta para marcar o resultado daquele provedor e localidade como correspondente. Outros valores podem diferir. O texto literal não comprova propriedade, validação DNSSEC, entrega de e-mail nem acordo mundial.

Posso informar um IP para consultar PTR?

Para um endereço literal, use as ferramentas separadas de consulta IP ou DNS reverso. Este verificador exige um nome completo de registro reverso, como o exemplo 10.113.0.203.in-addr.arpa. A comparação de valor esperado para PTR não está disponível.

Como consultar SPF, DKIM e DMARC?

Escolha TXT no domínio SPF pertinente, no nome de seletor DKIM fornecido pelo provedor sob _domainkey ou no nome _dmarc adequado. Essas consultas examinam texto publicado; não avaliam todas as dependências SPF, a assinatura DKIM de uma mensagem nem toda a descoberta e o alinhamento DMARC.

Não autenticado significa que meu domínio é inseguro?

Não autenticado significa que o provedor selecionado não afirmou o indicador AD. Dados sem assinatura também podem produzir esse resultado. O ToolMellow não valida DNSSEC independentemente, e essa indicação isolada não estabelece que um domínio seja inseguro.

Este verificador testa o servidor DNS do meu dispositivo?

Consulta os provedores públicos escolhidos pelas localidades disponíveis do ToolMellow. Esse percurso pode diferir do resolvedor e dos caches do dispositivo, navegador ou rede privada. Use diagnósticos locais para essa pergunta.

O acordo entre dois provedores comprova propagação mundial?

Demonstra apenas acordo entre as observações concluídas. Dois provedores consultados por uma localidade listada não formam uma rede mundial de sondas. As localidades disponíveis e os detalhes de confiança da região definem o alcance do relatório.

Meu valor esperado é enviado aos provedores DNS?

Não. O texto esperado fica na aba e pode aparecer no relatório baixado. O nome DNS e o tipo reais passam pelo serviço até o resolvedor selecionado. Confira tokens e outros dados do relatório antes de compartilhar.