Consulta ao vivo · registros de um domínio
Digite um domínio e consulte aqui mesmo, em português: registros A, AAAA, MX, TXT, NS, CNAME, CAA e SOA, os valores deles e o TTL com que viajam. É a visão de um resolvedor público neste momento, não a zona completa nem o DNS interno de ninguém.
Consulta DNS
Digite um domínio e escolha o tipo de registro. “ALL” devolve o inventário completo — A, AAAA, CNAME, MX, TXT, NS, CAA, SOA, DS e DNSKEY — e qualquer outra opção limita a resposta a um só tipo. Cada linha chega com o seu TTL.
Escolha “ALL” para ver o inventário completo, ou um tipo específico para limitar a resposta.
Usa a rota /api/dns-lookup do MyIPScan, apoiada em um resolvedor público de DNS sobre HTTPS. É a visão de um resolvedor: o resultado pode mudar conforme a rede, o cache e a propagação.
O formulário acima devolve registros DNS públicos: A (IPv4), AAAA (IPv6), MX (e-mail), TXT (verificação e SPF), NS (servidores de nomes), CNAME (alias) e os demais tipos disponíveis. O resto da página explica o que cada um deles significa.
Não acessa registros DNS privados nem internos. Os resultados dependem da propagação DNS e podem diferir entre resolvedores se houver mudanças recentes.
Uma consulta DNS pergunta a um resolvedor quais registros um domínio publica e devolve os valores tal como estão naquele instante: o A com o IPv4, o AAAA com o IPv6, o MX com os servidores de e-mail, o TXT com SPF, DKIM e tokens de verificação, e o NS com os servidores de nomes. Cada resposta chega com o seu TTL. É a visão de um resolvedor, não a zona completa do domínio.
O seu computador faz isso centenas de vezes por dia sem mostrar a você. Você digita um domínio e, antes de abrir qualquer coisa, o navegador pergunta a um servidor DNS — o resolvedor — a qual endereço IP precisa se conectar. O resolvedor responde, o navegador conecta, a página carrega.
Uma consulta DNS manual faz a mesma pergunta, mas de propósito e mostrando a resposta inteira. A diferença está no ponto de saída: quem faz a pergunta é o servidor do MyIPScan, para um resolvedor público de DNS sobre HTTPS, não o seu computador. Por isso o resultado não traz o cache do seu roteador nem depende do servidor que a sua operadora configurou, e por isso ele serve para comparar: se o seu computador vê uma coisa e esta consulta vê outra, o que falha não é o domínio, e sim o cache que existe entre os dois.
Esta página olha o que um domínio publica. Qual resolvedor responde por você quando você navega é outra pergunta, e quem a responde é o teste de vazamento de DNS.
O formulário tem dois campos e nada mais. O primeiro é o domínio, que se digita puro — exemplo.com.br —, sem protocolo e sem barra final. O segundo é uma lista suspensa com o tipo de registro, em que “ALL” pede o inventário inteiro e qualquer outra opção limita a resposta a um só tipo. Um botão dispara a consulta.
A resposta chega em forma de tabela. Acima dela, um resumo mostra o nome consultado, o tipo ou o modo, o resolvedor de origem e o horário da consulta; cada linha da tabela traz o tipo de registro, o TTL em segundos e a resposta bruta, e no modo “ALL” uma quarta coluna explica por que aquele registro importa. Quando um tipo devolve várias entradas — o normal em MX, NS e TXT —, todas aparecem, uma por linha, sem serem condensadas nem ordenadas por importância.
O que você não vai encontrar ali é um histórico de mudanças, um mapa de subdomínios ou uma nota de segurança. A consulta faz uma pergunta específica e mostra a resposta como ela é; interpretá-la é justamente o que esta página explica.
Tudo o que vem a seguir — o que cada tipo significa, como se lê o TTL, o que fazer quando o resultado não bate — vale igualmente para esta consulta, para o dig em um terminal ou para o painel do seu provedor de DNS. O vocabulário é o mesmo em todo lugar, então o que você aprender aqui não fica preso a uma ferramenta.
“ALL” devolve o inventário de uma vez; pedir um único tipo deixa o resultado mais limpo.
Uma resposta DNS não é uma frase, é uma lista de registros, e cada registro se lê sempre na mesma ordem: nome, tipo, TTL e valor. Com essas quatro colunas se resolve quase tudo.
O nome é o que você perguntou, devolvido como estava. Vale olhá-lo, porque ele denuncia as distrações: se você perguntou por www.exemplo.com.br e a resposta fala de exemplo.com.br, no meio há um alias que mudou você de lugar sem avisar.
O tipo confirma que classe de registro é cada linha, e nem sempre coincide com o que você pediu. Uma consulta do tipo A sobre um nome que na verdade é um alias devolve primeiro o CNAME e depois o A do destino: duas linhas de tipos diferentes para uma única pergunta.
O TTL é o número de segundos durante os quais um resolvedor pode continuar servindo essa resposta sem perguntar de novo. Se você repetir a consulta um minuto depois, verá que ele diminuiu: o que você está lendo é a contagem regressiva da cópia guardada em cache, não um valor fixo do registro. Quando o TTL volta ao número original, essa cópia expirou e o resolvedor perguntou de novo.
O valor muda conforme o tipo. Em um A, é um endereço IPv4; em um MX, um número de prioridade seguido do nome de um servidor; em um NS, o nome de um servidor de nomes; em um TXT, uma string entre aspas que às vezes vem partida em pedaços, porque o protocolo limita cada fragmento a 255 caracteres. Esse fatiamento é normal e não quebra nada: quem lê o registro junta as peças de novo antes de interpretá-lo.
Um detalhe que evita confusão: a ordem em que as linhas chegam não significa nada. Muitos resolvedores alternam as respostas de propósito para distribuir o tráfego, então duas consultas seguidas podem devolver os mesmos endereços em ordem diferente sem que nenhum registro tenha mudado.
exemplo.com.br, sem https:// e sem barra final. O DNS não entende de URL, entende de nomes._dmarc.exemplo.com.br para o DMARC, selector._domainkey.exemplo.com.br para o DKIM, www.exemplo.com.br se você suspeita que o www aponta para um lugar diferente do domínio raiz.O formulário de consulta — domínio e tipo de registro — está no início desta página.
O registro MX diz para quais servidores devem ser entregues as mensagens destinadas ao domínio. Costuma haver vários, com prioridades diferentes: o remetente tenta primeiro o número mais baixo e vai descendo se não obtiver resposta. Um domínio sem MX não recebe e-mail, por mais que o site carregue perfeitamente. Se você acabou de migrar de provedor, comparar os MX antigos com os novos é a primeira verificação a fazer.
O registro TXT é a gaveta onde se guarda quase todo o resto. Ali está o SPF, que começa com v=spf1 e lista quais servidores podem enviar em nome do domínio; a chave pública do DKIM, pendurada em um subdomínio no formato selector._domainkey.exemplo.com.br; e a política DMARC, que não é publicada no domínio raiz, e sim em _dmarc.exemplo.com.br. Esse detalhe explica por que tanta gente supõe que um domínio “não tem DMARC” quando, na verdade, olhou no lugar errado.
Se as mensagens saem mas não chegam, o DNS é só metade da questão: a outra metade é a reputação do endereço de onde você envia, e isso é verificado pelo verificador de lista negra de IP.
Na prática, quase todas as consultas DNS nascem de uma destas três situações. A ordem em que você pergunta importa mais do que a ferramenta com que pergunta.
Comece pelo MX do domínio do destinatário e confirme que ele existe e aponta para os servidores do provedor dele. Siga para o TXT do domínio de onde você envia, para ler o SPF inteiro e conferir se ele inclui o serviço que você realmente usa. Termine em _dmarc.exemplo.com.br, onde vive a política DMARC, e em selector._domainkey.exemplo.com.br, onde está a chave pública do DKIM. Com quatro consultas você saberá se o problema está no DNS ou se é preciso procurá-lo em outro lugar.
Consulte o A e o AAAA atuais e anote os TTL antes de mexer em qualquer coisa. Se forem longos, baixe-os para 300 e espere o valor anterior expirar; só então mude o endereço. Depois da mudança, consulte de novo a cada poucos minutos: a resposta nova vai aparecer antes em alguns resolvedores do que em outros, e é exatamente isso que deve acontecer. Quando o TTL antigo tiver expirado em todo lugar, aumente o valor de novo para não sobrecarregar os seus servidores de nomes com perguntas.
Consulte o CAA do domínio. Se ele publica uma lista de autoridades e a sua não está nela, a emissão é recusada por design e sem mais explicações. Um domínio sem CAA não restringe nada, então a ausência desse registro nunca é a causa. Confira também se o nome exato do certificado resolve: muitas validações falham porque o www não existe como registro, não porque o certificado foi pedido errado.
O TTL, do inglês time to live, é um número em segundos que acompanha cada resposta e diz por quanto tempo um resolvedor pode guardá-la em cache antes de perguntar de novo. Um TTL de 300 equivale a cinco minutos; um de 86400, a um dia inteiro.
Daí vem o que todo mundo chama de “propagação”, que na verdade não propaga nada: é a expiração de caches. Quando você muda um registro, o valor novo fica publicado na zona imediatamente, mas cada resolvedor continua servindo o antigo até expirar o TTL que guardou. Por isso duas pessoas em duas redes diferentes podem ver respostas diferentes, e as duas estarem certas.
A consequência prática é de ordem: antes de uma migração, baixe o TTL para 300, espere o TTL anterior expirar e só então mude o registro. Com registros recém-criados, dê uma margem de até 48 horas.
Há três resultados que confundem e quase nunca significam o que parecem.
Não aparece nenhum registro A. O nome não resolve para nenhum IP e o navegador não tem para onde ir. Pode ser que o registro tenha sido apagado, que nunca tenha sido criado ou que o domínio funcione só por IPv6. Em um domínio novo, aponte o A para o IP do servidor e consulte de novo em quinze ou trinta minutos.
Aparece um CNAME onde você esperava um A. É o normal em subdomínios que apontam para um serviço externo: quem manda é o alias, e o endereço final é publicado pelo nome para o qual ele aponta. Siga a cadeia consultando esse destino.
O IP não é o do seu servidor. Se o domínio passa por uma CDN ou um proxy reverso, o registro A publica o endereço do proxy, e não o da origem. É o comportamento esperado, e o motivo pelo qual uma consulta DNS não localiza o servidor de origem.
Para saber de quem é esse endereço, a consulta ASN traduz o número de rede em uma organização e a geolocalização de IP dá a localização aproximada que as bases de dados publicam. A consulta WHOIS acrescenta registrador, datas e status do domínio: dados do registro, não do DNS.
Quando uma consulta não devolve o que você esperava, a explicação costuma estar no código de resposta. Há três que vale distinguir, porque se parecem na tela e significam coisas muito diferentes.
NXDOMAIN quer dizer que o nome não existe na zona. Não é que falte esse tipo de registro: é que não há nada publicado com esse nome. Em um domínio recém-comprado ou recém-delegado, é o normal por um tempo; em um domínio que funcionava ontem, aponta para um registro apagado ou um domínio expirado, e isso a consulta WHOIS esclarece melhor do que qualquer consulta DNS.
A resposta correta, porém vazia, é a que mais confunde. O nome existe, a pergunta foi respondida sem erro e mesmo assim a lista vem sem registros: significa que esse nome não publica esse tipo específico. Um domínio com site mas sem e-mail devolve exatamente isso quando você pergunta pelo MX, e não há nada quebrado.
SERVFAIL não fala do domínio, fala da resolução. O resolvedor tentou responder e não conseguiu: servidores de nomes que não respondem, uma delegação quebrada entre o registro e a zona, ou uma assinatura DNSSEC que não valida. Se um domínio devolve SERVFAIL em um resolvedor e responde normalmente em outro, a assinatura ou a delegação são os primeiros suspeitos.
Resta um quarto caso, que não tem código próprio: a resposta chega, está correta e o valor é antigo. Aí nada falha. É o cache fazendo o trabalho dele, e se resolve esperando o TTL vencer.
Nada disso é exclusivo de um site. Qualquer sistema operacional traz uma ferramenta que faz a mesma pergunta, e vale a pena conhecê-la porque ela responde a partir da sua rede, e não de um servidor remoto.
No macOS e no Linux, dig exemplo.com.br MX devolve os registros de e-mail com o TTL. Adicionar +short deixa só os valores, sem cabeçalhos nem seções. E para perguntar a um resolvedor específico basta colocar o endereço dele antes: dig @1.1.1.1 exemplo.com.br A pergunta a esse servidor, e não ao que estiver configurado no sistema.
No Windows, nslookup -type=MX exemplo.com.br faz o equivalente, e nslookup -type=TXT _dmarc.exemplo.com.br traz a política DMARC. Ele também aceita um servidor no final da linha, se você quiser pular o resolvedor da sua rede.
A diferença em relação à consulta desta página é justamente o ponto de saída, e por isso vale ter as duas à mão. O seu terminal pergunta pelo resolvedor da sua rede, com o cache da sua rede incluído; uma consulta remota pergunta a partir de outro lugar e com outro cache. Se as duas coincidem, o dado está propagado; se não, você já sabe de que lado está a cópia antiga.
A consulta pergunta pelo nome e pelo tipo que você digita e devolve o que um resolvedor público responde naquele momento. Esse é o seu alcance e o seu limite.
Ela não enumera subdomínios: o que você não perguntar não aparece. Não vê o DNS interno de uma empresa, que pode responder outra coisa dentro da rede corporativa. Não prova quem é o dono do domínio nem certifica que a configuração dele seja segura, e um registro existir não significa que o serviço por trás dele funcione.
Além disso, a resposta pode vir do cache, estar delegada ou passar por um proxy: é um sinal público e repetível, não uma verdade definitiva sobre a infraestrutura. A metodologia em português explica como cada sinal é rotulado e onde ele para. A mesma consulta, com a interface em inglês, está em DNS Lookup.
Digite o domínio sem “https://” nem barra final, escolha “ALL” para ver o inventário completo e faça a consulta pelo formulário desta mesma página. A pergunta sai do servidor do MyIPScan para um resolvedor público de DNS sobre HTTPS, então a resposta não depende do cache do seu computador nem do seu roteador. Para um subdomínio, digite-o inteiro.
O registro MX indica para quais servidores deve ser entregue o e-mail destinado a esse domínio. Normalmente há vários, com um número de prioridade: o remetente tenta primeiro o mais baixo e desce pela lista se ele não responder. Um domínio sem registros MX não consegue receber e-mail, mesmo que o site dele carregue normalmente.
É um registro de texto livre no qual se apoia quase toda a autenticação de e-mail. Nele vão o SPF, que começa com v=spf1 e lista quem pode enviar em nome do domínio, a chave pública do DKIM, em um subdomínio do tipo selector._domainkey.exemplo.com.br, e os tokens de verificação de propriedade. A política DMARC é publicada à parte, em _dmarc.exemplo.com.br.
Quase sempre é cache. Cada resposta DNS traz um TTL, e os resolvedores guardam o valor até esse tempo expirar. Se o seu computador, o seu roteador ou o resolvedor da sua operadora guardaram o valor anterior, eles vão continuar servindo esse valor mesmo que o domínio já publique outro. Espere o TTL vencer antes de supor que há um erro.
O tempo que o TTL do registro anterior indicar, não o do novo. Se o valor antigo foi publicado com um TTL de 86400, haverá resolvedores servindo esse valor por até 24 horas depois da mudança. Por isso vale baixar o TTL para 300 antes de uma migração, esperar o TTL longo expirar e só então mudar o registro.
Significa que esse nome não resolve para nenhum endereço IPv4, então o navegador não sabe para onde se conectar e o site não carrega. Pode ser que o registro tenha sido apagado, que nunca tenha sido criado ou que o domínio publique só AAAA e funcione por IPv6. Em um domínio novo, adicione o registro A com o IP do servidor e consulte de novo depois de quinze ou trinta minutos.
Não. A consulta só responde pelo nome exato que você digita, então um subdomínio pelo qual você não perguntar não aparece em lugar nenhum. Enumerar subdomínios fica fora do que esta consulta faz, por design, e não por falha. Se você conhece o nome, digite-o inteiro e consulte-o à parte.
Estas são as rotas em português aprovadas. Elas não levam a guias futuros, rankings, afiliados nem rascunhos.