Herramientas de diagnóstico de red
Registros de localización de servicios
DNS y registros
Consulta DNS Todos los registros DNS de cualquier dominio Consulta de registro A Direcciones IPv4 de un dominio Consulta de registro AAAA Direcciones IPv6 de un dominio Consulta MX Servidores de correo de un dominio Consulta NS Servidores de nombres autoritativos Consulta TXT Registros TXT, SPF, verificación Consulta CNAME Registros de nombre canónico (alias) Consulta SOA Registro Start of Authority Consulta SRV Registros de localización de servicios Consulta CAA Qué CAs pueden emitir certificados DNS inverso (PTR) Dirección IP a nombre de host Comprobación DNSSEC ¿Está el dominio firmado y validado? Diagnóstico DNS Un informe completo de delegación y DNSEntregabilidad de correo
Comprobación SPF Valida tu registro Sender Policy Framework Comprobación DMARC Inspecciona y califica tu política DMARC Comprobación DKIM Encuentra y valida tu clave pública DKIM Comprobación de lista negra Comprueba una IP contra listas negras de correo (DNSBLs) Test SMTP Conecta a un servidor de correo y comprueba STARTTLS Comprobación MTA-STS Política TLS forzada para el correo entrante Comprobación BIMI Registro del logo de marca para el correo Comprobación TLS-RPT Política de informes de TLS de SMTPRed y web
Comprobación de certificado SSL Inspecciona el certificado TLS de un sitio y su caducidad Comprobación de cabeceras HTTP Inspecciona cabeceras de respuesta, redirecciones y seguridad Ping (TCP) Accesibilidad y latencia sobre TCP Comprobación de puertos Qué puertos comunes están abiertosDominio
Consulta WHOIS Datos de registro de dominios, IPs y ASNsUn registro SRV (Service) anuncia el hostname y el puerto de un servicio concreto —como SIP, XMPP, LDAP o el autodiscover de Microsoft— junto con la prioridad y el peso para el reparto de carga. A diferencia de un registro A, indica a los clientes no solo dónde vive un servicio sino en qué puerto, para que las aplicaciones localicen servicios sin configuración codificada a mano. Se consultan con el formato _servicio._proto.dominio.
Un registro SRV se nombra con un patrón distintivo: _servicio._proto.dominio, por ejemplo _sip._tcp.example.com. Los guiones bajos evitan choques con hostnames ordinarios. Los datos del registro contienen cuatro valores: prioridad, peso, puerto y destino. La prioridad funciona como en MX: los números más bajos se prueban primero. El peso distribuye la carga entre destinos de la misma prioridad, recibiendo proporcionalmente más tráfico los de mayor peso. El puerto es el puerto TCP o UDP en el que escucha el servicio, y el destino es el hostname que lo proporciona, que debe tener su propio registro A o AAAA.
IPeek devuelve la prioridad, el peso, el puerto y el host de destino de cada registro SRV para el nombre de servicio que consultaste. Lee primero la prioridad: los clientes usan los destinos de menor prioridad antes de recurrir a los más altos. Entre prioridades iguales, el peso decide la cuota de tráfico que recibe cada destino. Confirma que el puerto coincida con el servicio que esperas: 5060 para SIP, 389 para LDAP, 443 para muchas configuraciones de autodiscover. Comprueba que cada destino resuelva a un host válido. Un resultado vacío significa que el servicio no está anunciado bajo ese nombre en el dominio.
Los registros SRV importan siempre que los clientes deban descubrir un servicio automáticamente en lugar de depender de ajustes fijos. Microsoft Teams, Skype for Business y los proveedores de SIP los usan para localizar servidores de voz y presencia. El chat XMPP, las consultas de directorio LDAP, los servidores de Minecraft y Kerberos dependen todos del descubrimiento SRV. La gran ventaja es la flexibilidad: mueve un servicio a un nuevo host o puerto, o repártelo entre varios servidores, y los clientes siguen los registros SRV sin reconfiguración. Si un servicio requiere un nombre _servicio._proto concreto, publica un registro SRV que coincida o los clientes no lo encontrarán.
Este patrón nombra un registro SRV por el servicio y el protocolo que describe. _servicio es la etiqueta del servicio (como _sip o _ldap), _proto es el transporte (_tcp o _udp), y dominio es tu dominio. Por ejemplo, _sip._tcp.example.com anuncia SIP sobre TCP. Los guiones bajos iniciales evitan que estas etiquetas choquen con hostnames normales.
La prioridad y el peso controlan qué destino elige un cliente. La prioridad funciona como en los registros MX: los clientes prueban primero los destinos de menor prioridad y recurren a números más altos. Entre destinos que comparten prioridad, el peso fija la proporción de tráfico que recibe cada uno, así que un peso mayor atrae más conexiones. Juntos permiten tanto la conmutación por error como el reparto de carga.
Un registro A asigna un hostname a una dirección IP, mientras que un registro SRV especifica además el puerto y añade prioridad y peso para un servicio con nombre. SRV permite a los clientes descubrir tanto dónde como en qué puerto se ejecuta un servicio, además de cómo repartir la carga, algo que un registro A simple no puede expresar. Los destinos SRV siguen dependiendo de registros A para resolver.
Los sistemas SIP y VoIP, el chat XMPP, LDAP y Active Directory, Kerberos, Microsoft Teams y Skype for Business, e incluso los servidores de Minecraft usan habitualmente registros SRV. Cualquier protocolo que se beneficie del descubrimiento automático de servicios sin ajustes de host y puerto codificados a mano es candidato. El cliente debe estar programado para consultar el nombre _servicio._proto pertinente.
Un resultado SRV vacío suele significar que no hay ningún registro publicado bajo ese nombre exacto _servicio._proto.dominio. Comprueba que la etiqueta del servicio, el protocolo y el dominio estén bien escritos, incluidos los guiones bajos. El servicio puede usar un nombre distinto del esperado, o el registro simplemente no existir. Confirma el nombre exacto que requiere la aplicación cliente.