Ferramentas de Diagnóstico de Rede
Registros de localização de serviço
DNS e Registros
Consulta DNS Todos os registros DNS de qualquer domínio Consulta de Registro A Endereços IPv4 de um domínio Consulta de Registro AAAA Endereços IPv6 de um domínio Consulta MX Servidores de e-mail de um domínio Consulta NS Servidores de nomes autoritativos Consulta TXT Registros TXT, SPF, verificação Consulta CNAME Registros de nome canônico (alias) Consulta SOA Registro Start of Authority Consulta SRV Registros de localização de serviço Consulta CAA Quais ACs podem emitir certificados DNS Reverso (PTR) Endereço IP para hostname Verificação DNSSEC O domínio está assinado e validado? Diagnóstico de DNS Um relatório completo de delegação e DNSEntregabilidade de E-mail
Verificação SPF Valide seu registro Sender Policy Framework Verificação DMARC Inspecione e avalie sua política DMARC Verificação DKIM Encontre e valide sua chave pública DKIM Verificação de Blacklist Verifique um IP em listas de bloqueio de e-mail (DNSBLs) Teste SMTP Conecte-se a um servidor de e-mail e verifique o STARTTLS Verificação MTA-STS Política de TLS obrigatório para e-mail de entrada Verificação BIMI Registro de logotipo da marca para e-mail Verificação TLS-RPT Política de relatórios de TLS do SMTPRede e Web
Verificação de Certificado SSL Inspecione o certificado TLS e a validade de um site Verificação de Cabeçalhos HTTP Inspecione cabeçalhos de resposta, redirecionamentos e segurança Ping (TCP) Acessibilidade e latência por TCP Verificação de Portas Quais portas comuns estão abertasDomínio
Consulta WHOIS Dados de registro de domínios, IPs e ASNsUm registro SRV (Service) anuncia o hostname e a porta de um serviço específico — como SIP, XMPP, LDAP ou o autodiscover da Microsoft — junto com prioridade e peso para balanceamento de carga. Diferente de um registro A, ele informa aos clientes não apenas onde um serviço fica, mas em qual porta, para que as aplicações localizem serviços sem configuração fixa. Consulte-os usando a forma _service._proto.domain.
Um registro SRV é nomeado com um padrão distinto: _service._proto.domain, por exemplo _sip._tcp.example.com. Os underscores evitam conflitos com hostnames comuns. Os dados do registro contêm quatro valores: prioridade, peso, porta e alvo. A prioridade funciona como no MX — números mais baixos são tentados primeiro. O peso distribui a carga entre alvos de mesma prioridade, com pesos mais altos recebendo proporcionalmente mais tráfego. A porta é a porta TCP ou UDP em que o serviço escuta, e o alvo é o hostname que o fornece, que deve ter seu próprio registro A ou AAAA.
O IPeek retorna a prioridade, o peso, a porta e o host alvo de cada registro SRV do nome de serviço que você consultou. Leia primeiro a prioridade: os clientes usam os alvos de menor prioridade antes de recorrer aos mais altos. Entre prioridades iguais, o peso decide a parcela de tráfego que cada alvo recebe. Confirme que a porta corresponde ao serviço que você espera — 5060 para SIP, 389 para LDAP, 443 para muitas configurações de autodiscover. Verifique se cada alvo resolve para um host válido. Um resultado vazio significa que o serviço não é anunciado sob aquele nome no domínio.
Os registros SRV importam sempre que os clientes precisam descobrir um serviço automaticamente em vez de depender de configurações fixas. Microsoft Teams, Skype for Business e provedores de SIP os usam para localizar servidores de voz e presença. XMPP para chat, consultas de diretório LDAP, servidores de Minecraft e Kerberos dependem todos da descoberta via SRV. A grande vantagem é a flexibilidade: mova um serviço para um novo host ou porta, ou distribua-o entre vários servidores, e os clientes seguem os registros SRV sem reconfiguração. Se um serviço exige um nome _service._proto específico, publique um registro SRV correspondente ou os clientes não o encontrarão.
Esse padrão nomeia um registro SRV pelo serviço e protocolo que ele descreve. _service é o rótulo do serviço (como _sip ou _ldap), _proto é o transporte (_tcp ou _udp) e domain é o seu domínio. Por exemplo, _sip._tcp.example.com anuncia SIP sobre TCP. Os underscores iniciais impedem que esses rótulos colidam com hostnames normais.
A prioridade e o peso controlam qual alvo um cliente escolhe. A prioridade funciona como nos registros MX: os clientes tentam primeiro os alvos de menor prioridade e recorrem aos números mais altos. Entre alvos que compartilham uma prioridade, o peso define a proporção de tráfego que cada um recebe, então um peso mais alto atrai mais conexões. Juntos, eles permitem tanto failover quanto balanceamento de carga.
Um registro A mapeia um hostname para um endereço IP, enquanto um registro SRV adicionalmente especifica a porta e acrescenta prioridade e peso para um serviço nomeado. O SRV permite que os clientes descubram tanto onde quanto em qual porta um serviço roda, além de como balancear a carga, o que um registro A simples não consegue expressar. Os alvos de SRV ainda dependem de registros A para resolver.
Sistemas SIP e VoIP, XMPP para chat, LDAP e Active Directory, Kerberos, Microsoft Teams e Skype for Business, e até servidores de Minecraft costumam usar registros SRV. Qualquer protocolo que se beneficie de descoberta automática de serviço sem configurações fixas de host e porta é um candidato. O cliente precisa ser escrito para consultar o nome _service._proto relevante.
Um resultado SRV vazio normalmente significa que nenhum registro está publicado sob aquele nome _service._proto.domain exato. Verifique se o rótulo do serviço, o protocolo e o domínio estão escritos corretamente, incluindo os underscores. O serviço pode usar um nome diferente do esperado, ou o registro pode simplesmente não existir. Confirme o nome exato que a aplicação cliente exige.