Registro MX

A registro de intercambiador de correo (Registro MX) es un tipo de registro de recursos En Sistema de nombres de dominio que especifica un servidor de correo responsable de aceptar Correo electrónico mensajes en nombre de dominio de un destinatario y un valor de preferencia utiliza para priorizar la entrega de correo si se dispone de múltiples servidores de correo. El conjunto de registros MX de un nombre de dominio especifica cómo debe enviarse correo electrónico con el Simple Mail Transfer Protocol (SMTP).

Resumen

Registros de recursos son los elementos de información básica de la Domain Name System (DNS). Se distinguen por una identificación de tipo (A, MX, NS, etc.) y una clase DNS (Internet, caos, etc.). Los registros tienen un (período de valideztime-to-live) asignados a ellos, indicando Cuándo debe actualizarse la información que poseen de un servidor de nombres autorizado. Registros de recursos se organizan en el DNS basado en sus nombre campo, que es un nombre de dominio completamente calificado (FQDN) de un nodo en el árbol de DNS. En el caso de un registro MX, especifica el nombre de dominio de un destinatario correo Dirección de correo electrónico, es decir, la parte después de la @ símbolo que delimita el nombre de cuenta del beneficiario.

La información de carga característica de un registro MX es el nombre de dominio completamente calificado de un host de correo y un valor de preferencia. El nombre de host debe asignar directamente a uno o más registro de dirección (A, o AAAA) en el DNS y no debe apuntar a cualquier Registros CNAME.

Cuando se envía un mensaje de correo electrónico a través de Internet, el envío agente de transferencia de correo (MTA) consulta el sistema de nombres de dominio para los registros MX de cada destinatario nombre de dominio. Esta consulta devuelve una lista de nombres de host de servidores de correo exchange aceptar correo entrante para ese dominio y sus preferencias. El agente envío entonces intenta establecer una conexión SMTP.

El mecanismo de MX proporciona la capacidad de ejecutar múltiples servidores de correo para un solo dominio y permite a los administradores especificar un orden en el cual debe ser juzgados. Esta capacidad de ejecutar múltiples servidores de correo resulta muy valiosa para clusters de alta disponibilidad de pasarelas de correo barato, que luego puede procesar cientos de mensajes por segundo en total para poner en cuarentena o eliminar spam o los virus.

El mecanismo de MX no le otorga la capacidad de proporcionar el servicio de correo de alternativa números de Puerto, ni brinda la capacidad de distribuir el correo a través de un conjunto de servidores de correo de prioridad desigual asignando un valor de ponderación a cada uno. MX puede utilizarse para distribuir entrega a través de servidores de correo de prioridad de igualdad.

Prioridad, la distancia y preferencia MX

Según RFC 5321, los registros de número más bajo son los preferidos. Esta frase puede ser confuso y el número de preferencia se refiere a veces como el distancia:: distancias más pequeñas son más preferibles. Una RFC mayor, RFC 974, indica que cuando los números de preferencia son las mismas para los dos servidores, tienen el mismo prioridad, por lo tanto esos dos términos se utilizan indistintamente.

Los conceptos básicos

En el caso más simple, un dominio puede tener un servidor de correo. Por ejemplo, si un MTA busca los registros MX de example.com, y el servidor DNS respondió con correo.ejemplo.com sólo con un número de preferencia de 50, el MTA intentará entrega del correo electrónico en el servidor que aparece. En este caso, el número de 50 podría haber sido cualquier número entero permitido por la especificación SMTP.

Pero cuando más de un servidor es devuelto por una consulta MX, el número de preferencia para cada registro dicta la prioridad relativa del servidor indicado. Cuando un cliente remoto (típicamente otro servidor de correo) haga una búsqueda MX para el nombre de dominio, se pone una lista de servidores y sus números de preferencia. El menor número de preferencia tiene la máxima prioridad y cualquier servidor con el menor número de preferencia debe intentarse primero. Para proporcionar la transmisión confiable de correo, el cliente SMTP debe ser capaz de probar (y vuelva a intentarlo) cada una de las direcciones correspondientes en esta lista en orden, hasta que consiga un intento de entrega. Si hay más de un registro MX con el mismo número de preferencia, todos aquellos deben ser juzgados antes de pasar a las entradas de menor prioridad.

Distribución de la carga entre una matriz de los servidores de correo

Técnica utilizada para distribuir la carga de correo entrante sobre un array de servidores es devolver el mismo número de preferencia para cada servidor en el conjunto. Cuando se determina qué servidor de igual preferencia para enviar mail, "el remitente SMTP debe aleatorizar para repartir la carga a través de múltiples intercambiadores de correo para una organización específica", a menos que exista una razón clara a favor de uno. Tenga en cuenta que multitarjeta los servidores reciben un trato diferente, ya que en este caso cualquier aleatorización se supone que se han aplicado ya por el servidor de nombres. Esta técnica dirige principalmente a problemas de enrutamiento; otros tipos de carga del servidor pueden abordarse mediante el uso de un proxy SMTP.

La otra alternativa mencionada en el RFC es utilizar lo que parece ser un multitarjeta Un registro para un servidor de correo. De hecho puede ser una matriz de servidores de correo que comparten el mismo nombre de host. Este método coloca la carga en el sistema DNS más que el remitente SMTP para realizar el balanceo de carga, que en este caso presentará una lista de direcciones IP en un orden específico a los clientes consultar el registro del intercambiador de correo. Puesto que el RFC requiere que el uso de SMTP remitente la orden dada en la consulta de registros A, el servidor DNS es libre de manipular cuidadosamente su equilibrio basándose en cualquier método, incluyendo round robin DNS, carga de servidor de correo, o algún esquema de prioridad no revelada.

El backup MX

A servidor de destino, es decir, uno que sabe cómo ofrecer al usuario relevante de buzón de correo electrónico Normalmente es uno que es el más preferido. Bajar servidores de prioridad, a.k.a. Backup MX o MX secundaria, suele mantener los mensajes en una cola esperando el servidor primario a estar disponibles. Si ambos servidores están en línea o de alguna manera conectados uno al otro, el backup MX típicamente brevemente un mensaje de la coleta y reenvíelo inmediatamente a la primaria MX. El backup MX actúa como un tienda y hacia adelante servidor de correo.

Prioridad

Una idea falsa común sobre el orden de preferencia de MX es que se pretende aumentar la probabilidad de que se puede entregar correo; Sin embargo, el mero hecho de tener varios registros MX con la misma preferencia proporciona este beneficio. Porque el orden de preferencia de MX especifica que se deberían probar a algunos servidores primera, es, si acaso, un medio de establecer el desequilibrio de la carga. Otra interpretación común de preferencia MX pedido es que se pretende proporcionar un medio de "failover" en caso de sobrecarga del servidor. Mientras que puede ser utilizado de esa forma, es una técnica de gestión de recursos pobres porque intencionalmente crea sobrecarga y no utilizar plenamente el hardware disponible. Asignar el mismo valor de preferencia a todos los servidores disponibles ofrece el mismo beneficio y puede incluso ayudar a evitar las situaciones de sobrecarga y así aumentar el rendimiento del sistema por la disminución de latencia.

El protocolo SMTP establece una red store-and-forward, y si los servidores de correo de un dominio son todos los servidores fuera de línea, envío están obligados a cola de mensajes destinado a ese dominio a intentar más tarde. Sin embargo, estos servidores de envío no tienen forma de ser notificado que los servidores de un dominio previamente fuera de línea ya están disponibles. Los servidores de envío sólo descubrirá que el dominio está disponible cuando se intenta próxima entrega de los mensajes de retrasos. El retraso entre cuando se conecten los servidores de un dominio y cuando finalmente se entregan mensajes retrasados puede ser de minutos a días, dependiendo del horario de reintento de los servidores de envío. Esto es el problema que copia de seguridad de registros MX están excepcionalmente calificados para resolver. La idea es que los servidores enumeran como servidores MX secundarios tienen algunos out-of-band forma de saber cuándo los servidores primarios son en línea. Por lo tanto, son un lugar más útil a la cola de mensajes cuando los servidores primarios están desconectados de la cola del remitente original.

La pregunta que surge es: si los servidores secundarios están todavía en línea, ¿por qué no darles la misma prioridad que el resto de registros MX del dominio? Servidores secundarios son los que, por cualquier razón, no puede o no debe ser utilizado normalmente, pero que se puede utilizar si los servidores primarios están desconectados. Razones para que no se utilicen normalmente pueden variar ampliamente, pero aquí hay algunos ejemplos:

• el servidor de backup es propiedad de una compañía diferente u organización
• el servidor de backup no tiene acceso directo al almacenamiento primario de correo
• el servidor de backup no puede determinar direcciones de destinatarios válidas
• ancho de banda de Internet del servidor de backup más caro
• el servidor de backup tiene significativamente menos ancho de banda de Internet
• el servidor de backup tiene una conexión a Internet alta latencia

Spammers

Spammers con frecuencia la publicidad directa a uno de los refuerzos (alta distancia) servidores MX de un dominio primero para evitar los filtros anti-spam que pueden ejecutarse en el intercambiador primario (menor distancia/mayor preferencia). Servidores de Backup MX a menudo tienen diferente software anti-spam, y usarlos pueden ocultar dirección IP de los remitentes de spam desde los servidores primarios de MX. Esto puede ser frustrado por usar falsa alta distancia MX servidores.

Alternativamente, a veces los spammers sólo Apunten los registros MX de menor distancia para dominios y no recurrir a registros MX mayor distancia cuando los registros MX de menor distancia son inalcanzables. Una técnica llamada nolisting derrotará a este comportamiento.

El RFC SMTP es ambiguo sobre exactamente qué tipo de falta de entrega debe resultar en volver a intentar entrega a través de registros MX más distantes (aquellos con valores más altos de preferencia).

Por ejemplo, a veces los servidores indican fallos temporales, enviando explícitamente un error 4xx o por finalización de la conexión inesperadamente (que debe ser tratado como un error 451, según Sección 3.8 del RFC). ¿Si hay un fallo temporal, debe realizarse un registro MX más distante, o se el servidor espera y vuelva a intentarlo más tarde? Según Sección 4.5.4.1: El remitente debe retrasar reintentando un destino en particular después de una tentativa fracasó.

Pero cuando el remitente reintenta más tarde, el RFC guarda silencio sobre si el remitente debe reintentar el mismo servidor que dio el anterior error temporal o un registro MX más distante. Dice, en Sección 5.1: Cuando la búsqueda tiene éxito, la asignación puede resultar en una lista de direcciones de entrega alternativos en lugar de una sola dirección, debido a múltiples registros MX, multihoming o ambos. Para proporcionar la transmisión confiable de correo, el cliente SMTP debe ser capaz de probar (y vuelva a intentarlo) cada una de las direcciones correspondientes en esta lista en orden, hasta que consiga un intento de entrega.

No es específico acerca de lo que debería provocar el remitente a usar un registro MX de mayor preferencia, simplemente que el remitente debe ser poder para utilizar registros MX de mayor preferencia. Algunos servidores (tales como Sendmail y Postfix 2.1 o posterior) intentará el servidor MX siguiente-lejos después de algunos tipos de fallas de entrega temporal, tales como fallas de felicitación. Otros servidores (tales como qmail y Postfix 2.0 o versiones anteriores) serán sólo uso más distantes registros MX si los servidores especificados en los registros MX-la distancia más corta no pueden ser contactados para nada.

Ambos comportamientos son válidos, ya que el RFC no es específico. Volver a intentar con más distantes registros MX hace mucho sentido si falta del MX primaria se considera no autorizada; es decir, si hay la expectativa de que el mensaje aún puede ser entregado por los servidores de backup MX. Esto a menudo es expresado como "Si la alternativa es abandonar y no entregar el correo, por qué no probar las mayor preferencia MXs?" Sin embargo, si falla del MX primaria se considera autorizada (es decir, es el servidor primario por una razón no arbitraria), intentando ofrecer a servidores secundarios MX no es sólo una pérdida de tiempo pero potencialmente un desperdicio de recursos caros, dependiendo de la razón por qué los servidores secundarios tienen valores más altos de preferencia.

Los diferentes comportamientos MX-manejo de (servidores de correo electrónicoMTA) aparece a menudo en los debates de nolisting y los mecanismos de control similares estrategias anti-spam que dependen de manipular la orden MX y ejercer la falta MTA.

Independientemente de cómo uno interpreta las RFC hay una ventaja a elegir para entregar a mayores registros MX numerados cuando se recibe un error 4xx desde un servidor de correo principal. Si el servidor primario está sobrecargado o experimenta algún otro fallo temporal del servidor de backup puede aceptar el correo electrónico y procesarla. Esto significa que el correo electrónico se entrega más rápido que esperando para reintentar el servidor primario hasta que se recupera. Algunos servicios de filtrado de spam de front-end aplicarán técnicas gris listado en solamente el servidor primario para desalentar el correo electrónico de spam bot. Servidores que los más altos registros MX de reintento de envío será capaz de entregar su correo saliente inmediatamente, mientras que los servidores como qmail se retrasará típicamente durante una hora hasta que el servidor primario lo permite. Así que servidores que reintente más altos registros MX numerados obtienen una ventaja de rendimiento.

Historia de suplencia a registro de dirección

RFC 821 salió en 1982. Hace solo paso referencias al DNS, porque en ese momento la transición de HOSTS.TXT para el DNS había empezado. RFC 883, la primera descripción del DNS, salió un año más tarde en finales de 1983. Describió los registros experimentales y poco usados MD y MF. Según RFC 897 y RFC 921, la transición a DNS comenzó en 1983, pero los anfitriones.TXT no estaba previsto que vaya hasta el final de 1985 y fue totalmente gradual hacia fuera hasta finales de los noventa.

En enero de 1986, RFC 973 y RFC 974 los registros de MD y MF en desuso, reemplazándolas con MX y define la búsqueda MX con retraso a. RFC 974 recomienda que los clientes hacen un WKS búsqueda en cada host MX para ver si realmente es compatible con SMTP y deseche la entrada MX si no lo hace. Sin embargo, RFC 1123 cambió esto para decir que WKS No se debe revisarse.

Esto significa que SMTP había estado en uso durante al menos un año usando HOSTS.TXT y luego otro par de años usando A, MD y MF, antes de que llegara MX. MD y MF eran difíciles de usar, así que la mayoría sólo utiliza el registro. Dadas las circunstancias, MX sin respaldo a un no habría funcionado debido a la sustancial base instalada de servidores de correo utilizando los registros. El uso temprano de MX fue identificar vías de acceso a otras redes, pero no salió en uso amplio hasta el DNS estaba bien establecido en la década de 1990.

RFC 5321 Estados sec. 5:

• Los clientes SMTP que busque un registro MX;
• Si ningún registro MX para dominio está presente, mira para un registro A recursos (RR), y si dicho registro está presente, lo tratan como un registro MX;
• Si hay un registro MX, los clientes no deben utilizar un RR A.

Documentos de las normas

• RFC 974 (1986), Enrutamiento de correo y el sistema de dominio (sustituido)
• RFC 1035 (1987), Nombres de dominio - implementación y especificación
• RFC 5321 (2001), Simple Mail Transfer Protocol
• RFC 1912 (1996), DNS común operativa y errores de configuración

Véase también

• Registro SRV -un registro DNS similar para otros servicios de la red de publicidad
• Sender Policy Framework -un poco de un registro MX inverso, diciendo donde correo obtiene en lugar de a.
• Lista de tipos de registros DNS
• Un registro
• Nolisting

Otras Páginas

• Blog de mp3
• Portal web (seccion portales hospedados)
• Asfixia erotica (redireccion de Autoerotic accidente)
• Distrito de Angangxi
• BlueCentral
• Wisehost
• Me recuerdas (pelicula)
• Campeonato Sudamericano de marcha atletica 2002
• Jesus C. Gonzalez
• Liverpool bucaneros