smtp - verificar - ¿Por qué tener registros MX?
verificar registro mx (5)
Anteriormente, hice una pregunta sobre los registros MX (y aprecio las respuestas reflexivas que recibí de SO''ers). Ahora que ese problema está resuelto, quiero dar un paso atrás y preguntar por qué hay registros MX en primer lugar.
Específicamente: ¿Por qué SMTP recibe un tratamiento especial por DNS?
No tenemos registros HX para registros HTTP o FX para FTP. Parece que todos los demás protocolos de Internet se llevan bien con el registro DNS ''A''. De hecho, el artículo de Wikipedia sobre registros MX establece que la especificación SMTP actual dice que si no existe un registro MX para un receptor, el servidor debería recurrir a un registro A. También menciona algunos alojamientos SMTP hechos en un mundo previo al DNS, pero eso fue hace 25 años. ¿Realmente necesitamos registros MX?
Parece que todos los demás protocolos de Internet se llevan bien con el registro DNS ''A''.
Bueno, el tipo de registro SRV está disponible para aquellos.
Probablemente si SMTP se escribiera hoy, lo usaría.
Además de permitir la especificación de los intercambiadores de respaldo, observe que no todos los dominios tienen su propio servidor de correo, por lo que es necesario poder especificar un servidor de correo que exista en otro dominio como autorizado para intercambiar correo para que los mensajes administrativos y del sistema a postmaster, raíz o cualquier contacto técnico / administrativo incluido en el DNS. Se pueden entregar registros de WHOIS, incluso si no existen en el dominio actual.
Simplemente no necesita eso para ftp y http porque esos servicios no inician conexiones salientes como MX ni se consideran puntos de contacto oficiales.
Nunca descuide la explicación de "razones históricas". En los primeros años 80, SMTP era prácticamente el único protocolo públicamente conocido que tenía que estar disponible para mapear todo un sitio, y la búsqueda DNS se hacía con el archivo HOSTS común en muchos sistemas.
MX registros MX se usaron porque era necesario enrutar el tráfico SMTP al user@domain de forma diferente a otro tráfico para ese dominio, y los registros SRV aún no se habían inventado.
La moderna convención de que puede escribir http://example.com/ en su navegador sin un prefijo www y aún así llegar al sitio web requerido es en realidad un poco extraño. Para explicar con más detalle, considere cómo una zona normalmente se configuraría para lograr este acceso sin prefijo:
$ORIGIN example.com
@ IN A 192.168.1.1
IN MX mail.example.com
www IN A 192.168.1.1
mail IN A 192.168.1.2
Por lo tanto, cualquier tráfico dirigido a example.com va a esa dirección IP, independientemente del protocolo en uso (a menos que sea un correo electrónico que utilizará el registro MX).
En la práctica, sería preferible para todas las aplicaciones hacer uso de los registros SRV , y luego podríamos eliminar los prefijos específicos de la aplicación, y usar los registros A para su propósito real, específicamente asignar nombres de host reales a direcciones IP.
Si se usaron registros SRV de esta manera, ese archivo de zona se vería como sigue:
$ORIGIN example.com
_http._tcp IN SRV 0 0 80 www.example.com
_smtp._tcp IN SRV 0 0 25 mail.example.com
www IN A 192.168.1.1
mail IN A 192.168.1.2
Esta suposición de que el registro principal A de un dominio es en realidad para el servicio HTTP también es parte de la razón por la cual el "servicio" de VerFinder SiteFinder causó tantos problemas como cuando se introdujo (brevemente) en 2003. Al interceptar todo el registro DNS A búsquedas de dominios desconocidos y la devolución de una de sus propias direcciones, Verisign rompió todo tipo de protocolos que suponían que podrían conmutar por error a otros mecanismos de base de datos de direcciones si la búsqueda DNS fallaba.
El objetivo principal detrás de los registros MX es la capacidad de especificar máquinas para manejar un protocolo específico para todo el dominio, y también para especificar servidores de correo de respaldo (con diferentes prioridades). De esta forma, si un servidor falla, puede alcanzar el próximo servidor en línea para entregar el correo electrónico a ese dominio. Ninguno de los dos se puede hacer con registros simples A, que asignan directamente un nombre completo con un host.
Ahora se puede hacer con registros SRV (fechados hace 8 años, no 25) como señala Frank. En aquel entonces no había muchos otros protocolos estándar masivamente disponibles.