Pesquisa de DNS

Como funciona

1. Insira um domínio : digite um nome de domínio (incluindo subdomínios) no campo.
2. Selecione os tipos de registros : escolha quais tipos de registros DNS consultar : A, AAAA, MX, CNAME, TXT, NS, SOA ou todos.
3. Consulte os resultados : os resultados são obtidos de um provedor DNS-over-HTTPS público e exibidos com os valores TTL e os dados.
4. Diagnostique : compare os resultados entre os tipos de registros para identificar uma configuração incorreta, atrasos de propagação ou registros ausentes.

Por que usar a pesquisa DNS ?

Problemas de DNS estão entre as causas mais frequentes de indisponibilidade de sites, falhas de entrega de e-mails e problemas de migração de domínio. Poder consultar registros DNS diretamente do navegador, sem recorrer a ferramentas de linha de comando como dig ou nslookup: é valioso para desenvolvedores, DevOps e administradores de sistema. Esta ferramenta consulta os registros via DNS-over-HTTPS para privacidade e bypass de firewalls. Use-a para verificar os registros MX após uma mudança de provedor de e-mail, confirmar os registros A/CNAME após uma migração de DNS, verificar os registros TXT para a autenticação SPF/DKIM e diagnosticar atrasos de propagação.

Tipos de registros DNS

• A: endereço IPv4 de um domínio
• AAAA: endereço IPv6 de um domínio
• MX: registros de servidores de e-mail para o roteamento de e-mails
• CNAME: apelido de nome canônico que aponta para outro domínio
• TXT: registros de texto para SPF, DKIM, verificação de domínio
• NS: servidores de nomes autoritativos para o domínio

40 anos de DNS: de RFC 882 a DNS sobre QUIC

O Domain Name System foi projetado por Paul Mockapetris na USC/ISI e especificado em RFC 882 e RFC 883 (novembro de 1983), substituindo o arquivo plano HOSTS.TXT que a ARPANET havia superado. O sistema foi revisado e formalizado em RFC 1034 e RFC 1035 (novembro de 1987), os documentos ainda citados hoje. Jon Postel coordenou a atribuição dos 13 servidores raiz originais, rotulados a.root-servers.net a m.root-servers.net, um número fixado não pela capacidade mas pelo limite de tamanho de pacote UDP de 512 bytes da época. Dois grandes choques remodelaram o DNS neste século. Em julho de 2008, Dan Kaminsky divulgou um ataque de envenenamento de cache que permitiu aos atacantes injetar registros forjados nos resolvers em segundos. A indústria respondeu com um patch coordenado (aleatorização da porta de origem) e renovado interesse em DNSSEC (RFC 4033-4035, março de 2005), que assina registros criptograficamente. O segundo choque foi a privacidade: as consultas viajavam em texto plano pela porta UDP 53 por 35 anos. DNS sobre TLS (DoT, RFC 7858, maio de 2016) envolve as consultas em TLS na porta 853. DNS sobre HTTPS (DoH, RFC 8484, outubro de 2018) tuneliza as consultas via HTTPS na porta 443, ocultando até o fato de que DNS está acontecendo. DNS sobre QUIC (RFC 9250, maio de 2022) é o mais recente, usando o mesmo transporte que alimenta HTTP/3. Os resolvers públicos 1.1.1.1 (Cloudflare, lançado em 1º de abril de 2018), 8.8.8.8 (Google Public DNS, dezembro de 2009) e 9.9.9.9 (Quad9, novembro de 2017) todos suportam DoH e DoT hoje.

Tipos de registros em profundidade

• A (RFC 1035). Endereço IPv4 de 32 bits. Um domínio pode ter muitos registros A para balanceamento de carga; os resolvers rotam entre eles (DNS round-robin).
• AAAA (RFC 3596, 2003). Endereço IPv6 de 128 bits. Pronunciado «quad-A». A partir de 2024, cerca de 45% do tráfego do Google é IPv6.
• CNAME (RFC 1035). Apelido: «siga este nome e procure seus registros em vez disso». Não pode coexistir com nenhum outro registro no mesmo nome. É por isso que example.com não pode ter tanto um CNAME quanto um MX ou A no ápice; alternativas modernas usam ALIAS ou ANAME (específicos do fornecedor) ou registros HTTPS (RFC 9460, 2023).
• MX (RFC 1035, atualizado pela RFC 7505 «null MX»). Servidor de troca de email com um valor de prioridade. Prioridade menor é preferida; empates são aleatorizados. 0 . (RFC 7505, junho de 2015) diz explicitamente «este domínio não recebe email», bloqueando spam para domínios sem caixa postal.
• TXT (RFC 1035). Strings de texto livre. Agora carrega autenticação crítica: SPF (RFC 7208, 2014), DKIM (RFC 6376, 2011), DMARC (RFC 7489, 2015), e verificação de propriedade para Google Search Console, Microsoft 365, desafios ACME (Let's Encrypt) DNS-01.
• NS (RFC 1035). Nomes dos servidores de nomes autoritativos. Sempre pelo menos dois para redundância. Os «glue records» na zona pai fornecem IPs para que um resolver recursivo possa alcançar o servidor de nomes sem buscas circulares.
• SOA (RFC 1035). Start of Authority. Único registro por zona listando o servidor de nomes primário, email admin (com o primeiro . substituído por @), número de série (incrementado nas mudanças), refresh, retry, expire e TTL mínimo.
• CAA (RFC 8659, 2019; originalmente RFC 6844, 2013). Certificate Authority Authorisation. Lista quais CAs estão autorizadas a emitir certificados para o domínio. Verificação obrigatória pelos requisitos de linha base do CA/Browser Forum desde setembro de 2017.
• SRV (RFC 2782, 2000). Localização de serviço: protocolo, prioridade, peso, porta, host destino. Microsoft Active Directory, XMPP, SIP, federação Matrix todos usam registros SRV para descoberta de serviço.
• PTR (RFC 1035). DNS reverso. Mapeia um IP de volta para um domínio. Vive nas zonas in-addr.arpa (IPv4) ou ip6.arpa (IPv6). Exigido por muitos servidores de email para aceitar email; PTR ausente é um sinal comum de spam.
• DNSKEY / DS / RRSIG (RFC 4034-4035). Encanamento DNSSEC. O DNSKEY publica as chaves de assinatura da zona; DS na zona pai é o ponteiro criptográfico «aqui está o próximo elo da cadeia»; RRSIG carrega a assinatura real para cada conjunto de registros.

Onde a busca DNS realmente ajuda

• Configurar email em um novo domínio. Verifique se os registros MX apontam para o provedor correto (Google Workspace aspmx.l.google.com, Microsoft 365 example-com.mail.protection.outlook.com, Fastmail, ProtonMail). Verifique SPF (v=spf1 include:_spf.google.com ~all), DKIM (selector._domainkey), DMARC (_dmarc TXT).
• Migração de domínio e propagação. Após atualizar servidores de nomes no registrador, consulte tanto os servidores autoritativos antigos quanto novos para confirmar que a mudança se propagou globalmente. Diferentes resolvers fazem cache por diferentes durações (o TTL é dica, não contrato).
• Solução de problemas de certificado TLS / SSL. O desafio ACME DNS-01 usado pelo Let's Encrypt e similares requer colocar um registro TXT em _acme-challenge.example.com. Verifique o valor antes de disparar a emissão de certificado para evitar tentativas desperdiçadas de rate-limit.
• Detectar risco de tomada de subdomínio. Um CNAME apontando para um serviço não registrado (app Heroku deletada, bucket S3 liberado) permite que atacantes registrem e sirvam conteúdo no seu subdomínio. Uma auditoria rápida de CNAME pega ponteiros pendurados.
• Verificação de CDN e balanceador de carga. Confirme que um domínio CNAMEa para o endpoint correto Cloudflare, Fastly, Akamai, CloudFront ou Vercel após o deploy. Detecte quando staging aponta acidentalmente para produção.
• Comparação DNS geográfica. Alguns sites servem diferentes registros A por região (GeoDNS). Consultar de diferentes endpoints DoH (Cloudflare 1.1.1.1 vs Google 8.8.8.8) sugere como um usuário em Frankfurt vs Mumbai vê o site.
• Segurança e resposta a incidentes. Procure registros NS inesperados (sequestro de registrador), registros TXT suspeitos ou registros MX recentemente adicionados. Use o número de série SOA para rastrear quando uma zona mudou pela última vez.

Erros DNS que quebram sites e email

• CNAME no ápice. A RFC 1034 proíbe colocar um CNAME em example.com em si (apenas em subdomínios como www.example.com). Cloudflare, Route 53, DNSimple contornam isso com CNAME flattening ou registros ALIAS; Vercel, Netlify usam registros de vinculação de serviço HTTPS (RFC 9460). Tentar isso no painel DNS básico de um registrador quebra silenciosamente o email.
• Esquecer de baixar o TTL antes de uma migração. Se seu registro A tem TTL 86400 (24 horas) e você o muda na manhã da troca, resolvers no mundo todo continuarão entregando o IP antigo por até um dia. Baixe TTLs para 300 segundos alguns dias antes da mudança.
• Registro SPF com muitas buscas DNS. A RFC 7208 limita SPF a 10 buscas DNS por avaliação. Encadeie diretivas include: demais e seu registro SPF falha com permerror, que o DMARC trata como falha. Achate ou consolide com ferramentas como SPF Surveyor.
• CNAME pendurado após desmontagem de serviço. Deletou a app Heroku mas o CNAME app.example.com ainda aponta para example.herokuapp.com? Qualquer um pode registrar esse nome de app e hospedar seu conteúdo no seu subdomínio. Audite e remova CNAMEs órfãos.
• Sem registro CAA. Sem um registro CAA, qualquer CA no WebPKI (~50 mundialmente) pode emitir um certificado para seu domínio. Trave-o em uma ou duas CAs confiáveis: 0 issue "letsencrypt.org". Verificação CA obrigatória desde setembro de 2017.
• Registros wildcard mascarando entradas faltantes. Um registro A *.example.com faz cada subdomínio com erro tipográfico resolver, escondendo erros reais de configuração. Combine cuidadosamente com regras MX explícitas para evitar spam para endereços com erro.
• Misturar DNSSEC e zonas não assinadas durante transição. Habilitar DNSSEC no registrador antes que os novos servidores de nomes sirvam registros assinados produz SERVFAIL para cada resolver validador (Cloudflare 1.1.1.1, Quad9). Sempre assine primeiro, depois publique o registro DS.

Mais perguntas frequentes

Ferramentas relacionadas