DNS Lookup / inspecionar registos DNS
Lê todos os registos DNS importantes de um domínio numa só consulta: A, AAAA, MX, TXT, CNAME, NS, SOA e CAA, incluindo TTL. Os registos SPF, DKIM e DMARC são analisados inline e mostrados com badge de validade. O lookup corre a partir do nó KernelHost em Frankfurt FRA01.
Como funciona o DNS?
O Domain Name System (DNS) é o livro de telefones da internet. Quando o seu navegador abre tools.kernelhost.com, o domínio é primeiro traduzido em endereço IP. O DNS não é um servidor único, mas uma cadeia hierárquica: servidores root (.), servidores de TLD (.com, .de, .at) e finalmente o nameserver autoritativo do domínio. O resolver percorre esta cadeia e guarda o resultado em cache local.
Uma consulta DNS consiste em pergunta e resposta: que registos do tipo X existem para o domínio Y? A resposta contém um ou mais registos mais um TTL (time to live), que indica ao resolver quanto tempo pode manter a entrada em cache. As alterações DNS não são portanto visíveis instantaneamente em todo o mundo, propagam-se ao longo da hierarquia de cache.
A nossa ferramenta arranca um lookup UDP/TCP através do resolver do sistema do container em Frankfurt FRA01. Não há tracking, não há logging do domínio consultado e não há API de terceiros. A resposta chega normalmente em poucos milissegundos, porque o nó de Frankfurt está ligado diretamente ao DE-CIX.
Que tipos de registo existem?
Cada tipo de registo DNS tem uma função específica. A nossa ferramenta mostra os oito tipos mais comuns que realmente precisa para operar um domínio.
- A: Mapeia um domínio para um endereço IPv4. Um domínio pode ter vários registos A (round-robin DNS, balanceamento de carga).
- AAAA: Mapeia um domínio para um endereço IPv6. Obrigatório em setups web modernos, o Google avalia positivamente a conectividade IPv6.
- MX: Mail exchanger. Que servidor aceita email para este domínio. Tem uma prioridade (número menor é preferido) para failover.
- TXT: Texto livre. Na prática, usado quase exclusivamente para SPF, DKIM, DMARC, verificação de domínio (Google, Microsoft) e _acme-challenge (Let's Encrypt).
- CNAME: Alias para outro domínio. www.kernelhost.com pode ser um CNAME a apontar para kernelhost.com. CNAME não é permitido no domínio apex.
- NS: Que nameservers são autoritativos para este domínio. Os registos NS são definidos no registo do domínio e indicam onde os outros registos são geridos.
- SOA: Start Of Authority. Define o nameserver primário, o email de admin e os valores refresh/retry/expire/minimum TTL para zone transfers.
- CAA: Certificate Authority Authorization. Que CAs podem emitir certificados TLS para este domínio. Proteção contra emissão não autorizada.
MX vs SPF vs DKIM vs DMARC: configuração de email explicada
Uma configuração completa de email consiste em quatro componentes DNS. Se faltar um, o seu email ou não chega ou cai na pasta de spam.
- MX (receção): Diz ao mundo que servidor aceita email recebido para o seu domínio. Sem MX, ninguém lhe pode escrever. O MX aponta tipicamente para um hostname como mx.kernelhost.com, que é depois resolvido via A/AAAA.
- SPF (autenticação de remetente): Registo TXT com v=spf1 que especifica os IPs autorizados a enviar email pelo seu domínio. -all no fim é obrigatório (caso contrário, qualquer pessoa pode falsificar o seu domínio).
- DKIM (assinatura criptográfica): Cada email enviado é assinado com uma chave privada, a chave pública fica no DNS em selector._domainkey.seu-dominio.com como TXT v=DKIM1. Os recetores verificam a assinatura e detetam manipulação.
- DMARC (política + reporting): TXT em _dmarc.seu-dominio.com com v=DMARC1; p=reject; rua=mailto:dmarc@... O DMARC combina SPF e DKIM, diz ao recetor o que fazer com email que falha e fornece relatórios.
A nossa ferramenta analisa SPF, DKIM e DMARC inline e mostra badges verdes, amarelos ou vermelhos para que veja imediatamente se a configuração está limpa ou se, por exemplo, falta -all, a chave DKIM é demasiado curta ou o DMARC está apenas em modo de monitorização.
TTL e cache DNS
O TTL (time to live) indica ao resolver, em segundos, quanto tempo pode guardar um registo DNS em cache. Com TTL=3600, o resolver só volta a consultar o servidor autoritativo passada uma hora. Isto poupa largura de banda mas torna as alterações DNS não imediatamente visíveis.
O TTL certo depende do que pretende. Produção estável: TTL alto (1 hora a 1 dia). Mudança de servidor iminente: baixe o TTL para 60 a 300 segundos com dias de antecedência, mude, depois suba novamente.
- TTL curto (60 a 300s): Alterações rápidas, mas mais carga no servidor autoritativo e ligeira latência adicional no lookup.
- TTL longo (3600 a 86400s): Menos carga, respostas mais rápidas a partir de cache, mas as alterações demoram horas a dias até serem visíveis em todo o mundo.
- Para migrações: Baixe o TTL para 60 a 300 segundos pelo menos 24 horas antes da mudança, para que todas as caches dos resolvers expirem mesmo antes do cutover.
O que é o DNSSEC e preciso dele?
O DNSSEC (DNS Security Extensions) assina criptograficamente os registos DNS, para que o resolver possa verificar se a resposta foi adulterada pelo caminho. Sem DNSSEC, um ISP malicioso ou um resolver de WiFi público pode devolver IPs falsos (DNS spoofing).
O DNSSEC usa duas chaves: ZSK (zone signing key) assina os registos, KSK (key signing key) assina o ZSK. O hash do KSK é publicado como registo DS no registrar, fechando a cadeia de confiança até à raiz.
Precisa dele? Para bancos, serviços públicos, fornecedores de email e quem usa registos SMIMEA, TLSA ou OPENPGPKEY (DANE): sim. Para uma loja online normal, o DNSSEC é um nice-to-have que não custa nada se o fornecedor o suportar. O DNS KernelHost suporta DNSSEC out of the box.
Casos comuns de debugging
Para que precisa realmente desta ferramenta no dia a dia:
- O email não chega: Verifique os registos MX, depois SPF, DKIM, DMARC. Se algum dos quatro estiver partido, o email vai para spam ou é rejeitado pelo recetor.
- O domínio aponta para o IP errado: Verifique os registos A e AAAA. Muitas vezes, numa mudança de servidor, só os registos A foram atualizados e os AAAA antigos ficaram.
- O subdomínio não responde: Verifique o CNAME ou o registo A direto no subdomínio. Erro comum: o subdomínio foi criado no painel de hosting mas o DNS continua a apontar para o nada.
- Verificar a propagação DNS: Após uma alteração, faça vários lookups espaçados no tempo. Quando o TTL expira, todos os resolvers devem ver os novos registos.
- Lets Encrypt recusa-se a emitir certificado: Verifique os registos CAA. Se listam apenas outra CA e o Lets Encrypt está em falta, o Lets Encrypt recusa-se a emitir.
DNS na KernelHost
O webhosting KernelHost inclui DNS gerido completo: todos os registos são geridos via o nosso painel de controlo, o DNSSEC está ativo por defeito, e nameservers anycast geograficamente redundantes em Frankfurt e Viena entregam respostas rápidas em todo o mundo.
Quem só precisa de DNS hosting sem webspace pode usar os nossos planos de serviço de domínio. Registo de domínio, transferência e gestão de DNS estão incluídos em todos os tarifários KernelHost. Para configurações mais complexas (split horizon, geo DNS, alta precisão de TTL) um VPS com servidor autoritativo próprio é uma opção, e pode usar esta ferramenta em qualquer altura para diagnóstico.
Perguntas frequentes
Que tipos de registo são consultados?
A, AAAA, MX, TXT, CNAME, NS, SOA e CAA. São os oito tipos mais comuns que realmente precisa para operar um domínio. Registos especiais como SRV, PTR, DS, DNSKEY ou TLSA estão disponíveis na ferramenta Check-Host no modo DNS com dig.
Os seletores DKIM são encontrados automaticamente?
Não. Os registos DKIM ficam em <selector>._domainkey.<domain>, e o seletor é arbitrário (google, k1, default e por aí). Sem conhecer o seletor, as entradas DKIM não podem ser enumeradas. Se conhece o seletor, introduza diretamente, por exemplo, google._domainkey.kernelhost.com como domínio, e a ferramenta mostrará a entrada TXT com parser.
O DMARC é verificado automaticamente?
Sim. O DMARC fica sempre em _dmarc.<domain> e é consultado automaticamente em paralelo com o domínio principal. Verá a entrada no bloco TXT com badge DMARC e explicação da política (none / quarantine / reject), pct, aspf, adkim e rua.
O que significa 'sem registos MX'?
Este domínio não recebe email. Se enviar mensagem para, por exemplo, info@este-dominio.com, ela faz bounce. O MX é o pré-requisito obrigatório para receber mail, sem MX não pode receber email para o domínio mesmo que exista um registo A.
Que valores de TTL fazem sentido?
Em produção, 3600 segundos (1 hora) até 86400 segundos (1 dia). Antes de alterações, baixe para 60 a 300 segundos pelo menos 24 horas antes, para que as caches sejam curtas e a alteração rapidamente visível em todo o mundo. Suba novamente depois.
As entradas são guardadas?
Não. Não há logging dos domínios consultados, sem cookies de tracking, sem API de terceiros. O lookup corre localmente no container via dns_get_record(). Não vemos histórico de consultas e também não o podemos reconstruir a partir de logs.
Porque não vejo registos DNSSEC?
A ferramenta mostra oito tipos de registo padrão. Registos específicos do DNSSEC (DS, DNSKEY, RRSIG, NSEC) estão disponíveis na ferramenta Check-Host no modo DNS (dig +dnssec). O foco aqui está nos registos que cada dono de domínio gere normalmente, não na cadeia de validação.
Posso usar a ferramenta para subdomínios?
Sim. Basta introduzir o subdomínio (ex: www.kernelhost.com ou mail.kernelhost.com). Em subdomínios é comum haver registos CNAME, e os A/AAAA são depois resolvidos através do CNAME e combinados numa só resposta pelo resolver.
Todos os produtos KernelHost
Precisa de mais do que ferramentas? Confira nossa linha de hospedagem comercial.