¿Por qué los registros MX no pueden apuntar a una dirección IP?

89

Entiendo que no debe apuntar un registro MX a una dirección IP directamente, sino que debe apuntarlo a un Aregistro, que, a su vez, apunta a la dirección IP de su servidor de correo.

Pero, en principio, ¿por qué se requiere esto?

domain-name-system email-server mx-record ip-address a-record dayuloli
fuente
Si puede configurar un registro MX, también puede configurar un registro A. No veo el problema aquí.
joshudson
26
@joshudson No es un problema en absoluto, solo yo tratando de entender por qué en lugar de simplemente seguir lo que todos los demás hacen.
dayuloli
Acabo de probar en CloudFlare. No acepta la dirección IP como un valor para el registro MX.
LinuxBabe
Nunca me había importado esto hasta que agregué un registro SPF y tuve demasiadas búsquedas. Tenía que encontrar una forma diferente de cortar algo.
gbryant

Respuestas:

90

La idea detrás del registro MX es especificar un host o hosts que puedan aceptar correo para un dominio. Como se especifica en RFC 1035 , el registro MX contiene un nombre de dominio. Por lo tanto, debe apuntar a un host que pueda resolverse en el DNS. No se pudo utilizar una dirección IP, ya que se interpretaría como un nombre de dominio no calificado, que no se puede resolver.

Las razones de esto en la década de 1980, cuando las especificaciones se escribieron originalmente, son casi las mismas que las razones actuales: un host puede estar conectado a múltiples redes y usar múltiples protocolos.

En los años 80, no era raro tener pasarelas de correo que se conectaban tanto a Internet (relativamente nuevo) que usaba TCP / IP como a otras redes heredadas, que a menudo usaban otros protocolos. La especificación de MX de esta manera permitió registros DNS que podrían identificar cómo llegar a dicho host en una red que no sea Internet, como Chaosnet . En la práctica, sin embargo, esto casi nunca sucedió; prácticamente todos rediseñaron sus redes para formar parte de Internet.

Hoy, la situación es que se puede llegar a un host mediante múltiples protocolos (IPv4 e IPv6) y mediante múltiples direcciones IP en cada protocolo. Un solo registro MX no puede incluir más de una dirección, por lo que la única opción es apuntar a un host, donde todas las direcciones de ese host se pueden buscar. (Como una optimización del rendimiento, el servidor DNS enviará a lo largo de los registros de direcciones para el host en la sección adicional de respuesta si tiene registros autorizados para ellos, ahorrando un viaje de ida y vuelta).

También existe la situación que surge cuando un tercero proporciona sus intercambiadores de correo (por ejemplo, Google Apps u Office 365). Señala sus registros MX a sus nombres de host, pero puede ocurrir que el proveedor de servicios necesite cambiar las direcciones IP de los servidores de correo. Como ha señalado a un host, el proveedor de servicios puede hacerlo de manera transparente y no tiene que hacer ningún cambio en sus registros.

Michael Hampton
fuente
2
Eso realmente no impide la compatibilidad con las direcciones IP; de hecho, la mayoría de los servidores / clientes SMTP funcionan bien con direcciones IP en registros MX de las pequeñas pruebas que he realizado. Creo que la intención era desalentar a la industria del uso de direcciones IP en masa, lo que probablemente habría sucedido si no se hubiera establecido esa regla, y no caso por caso. Por lo tanto, "debería", en oposición a "debe". +1 para la gran información, sin embargo. Nunca había considerado la mayor parte de eso.
Zenexer
16
Las leyes de tráfico de @Zenexer no existen para el inconveniente de relativamente pocos conductores expertos que saben exactamente qué es seguro y qué no. Existen debido al grupo mucho más grande de idiotas que creen que saben lo que están haciendo pero no saben.
Shadur
77
@Zenexer Puede encontrar que un MTA particular lo tolera hoy y mañana no. Después de todo, no es un comportamiento permitido por la norma. Y, por supuesto, no todos los MTA lo admitirán, por lo que esto significa que tiene la garantía de perder el correo.
Michael Hampton
1
@MichaelHampton: si un registro MX DEBE contener un nombre de host en lugar de una dirección IP, un MTA DEBE aceptar una dirección IP. Hipotéticamente, si un registro MX DEBE contener un nombre de host, entonces un MTA DEBE aceptar una dirección IP. Así es como funciona el RFC. La contraparte de un consejo de implementación "DEBE" puede optimizarse suponiendo que se siga el consejo, pero eso es prácticamente todo lo que puede hacer con él.
MSalters
2
@MSalters Creo que estás confundido. Nunca dije DEBERÍA nada. De hecho, dije que el registro MX DEBE contener un nombre de host, que también es lo que dicen los RFC.
Michael Hampton
18

DNS como protocolo tiene algunos tipos diferentes de valores, estos no son intercambiables.

Es importante tener en cuenta que DNS es un protocolo binario con asignaciones estrictas entre el tipo de registro y el tipo de datos que contiene dicho registro.

Por ejemplo:
un Aregistro contiene una dirección IPv4 (4 bytes de datos, longitud fija).
Un AAAAregistro contiene una dirección IPv6 (16 bytes de datos, longitud fija).

Un MXregistro, por otro lado, contiene un nombre (una secuencia de etiquetas en el formato <int number of bytes> <label> <int number of bytes> <label> <int 0>, longitud variable).

No es posible que un MXregistro tenga una dirección IP como sus datos.

Håkan Lindqvist
fuente
Puede hacer que la etiqueta sea la representación textual de una dirección IP, pero no tendría sentido hacerlo, ya que no se puede resolver como un nombre de host.
Michael Hampton
@MichaelHampton De hecho, es posible tener un nombre con etiquetas totalmente numéricas que, en la representación normal amigable para los humanos, parezca una dirección IPv4 a primera vista. Sin embargo, eso realmente no cambia nada cuando se trata de la pregunta, ya que seguiría siendo un nombre y, por lo tanto, se manejará como un nombre (un nombre que, al menos en Internet público, simplemente será NXDOMAIN).
Håkan Lindqvist
Esto realmente no responde la pregunta del OP. Básicamente dices "porque así son las cosas" .
dr01
@ dr01 Teniendo en cuenta que la pregunta demuestra claramente que desconoce "la forma en que está" ("no debe apuntar un registro MX directamente a una dirección IP, sino que debe apuntarlo a un registro A" cuando en realidad no es una posibilidad tener otro valor que no sea un nombre), no creo que esté fuera de lugar señalar cómo están las cosas y por qué eso hace imposible cualquier otra opción. Tengo la sensación de que estás leyendo mucho sobre la pregunta que en realidad no está allí.
Håkan Lindqvist
@ dr01 Es decir, no creo que la pregunta se lea como una pregunta académica sobre las decisiones de diseño en los primeros días de DNS o algo así, sino simplemente una pregunta sobre cómo los MXregistros que realmente existen en el mundo pueden o deben ser utilizados.
Håkan Lindqvist
6

Voy a tirar esto como una suposición. Por supuesto, estoy en casa con gripe, así que tal vez estoy loco.

RFC 974 declara:

El primer paso para el programa de correo en LOCAL es emitir una consulta para MX RRs para REMOTE. Se recomienda encarecidamente que se tome este paso cada vez que un remitente intenta enviar el mensaje. La esperanza es que los cambios en la base de datos del dominio sean utilizados rápidamente por los remitentes de correo y, por lo tanto, los administradores del dominio podrán redirigir los mensajes en tránsito para hosts defectuosos simplemente cambiando sus bases de datos de dominio.

Al requerir un nombre en lugar de IP, fomenta con fuerza esta práctica. Los nombres pueden permanecer iguales y, en caso de equilibrio de carga o DR, no tendrá que preocuparse por cambiar el registro MX y esperar la propagación del DNS.

El limpiador
fuente
8
Contestando preguntas de intercambio de fichas en tu día libre mientras estás enfermo de gripe ... ¡Te doy mi sombrero, buen señor!
Mike B
3

Algunos servidores de correo electrónico (como exim) específicamente no permiten el envío a registros MX que apuntan a una dirección IP pura, por lo que debe utilizar un FQDN para que sea compatible. Esto se debe a que la mayoría de los servidores esperan que el registro MX contenga un nombre de host, no una IP (para eso están los registros A).

Editar: Para elaborar, en DNS cada registro tiene requisitos estrictos para el tipo de datos que puede contener cada registro. En el caso de los registros MX, es solo un nombre de host .

Nathan C
fuente
Entonces, ¿por qué exim no permitió que los registros MX apuntaran a la dirección IP en primer lugar? ¡Me parece extraño! Entiendo que no debería debido a la convención, pero no entiendo por qué se hace ilegal .
dayuloli
1
No veo cómo cualquier MTA podría soportar esto, ya que un MXregistro no puede tener una dirección IP como valor.
Håkan Lindqvist
@ HåkanLindqvist ¡Su respuesta anterior me aclaró este punto! ¡Gracias!
dayuloli
2

EN RFC 1025 Los registros MX solo apuntan a un RR (registro de recursos) de un Registro A o un CNAME.

Por lo tanto, el servidor de correo que envía el correo solicita el RR de un registro MX, el registro mx enumera los registros A de los servidores, el servidor de correo realiza una búsqueda directa para obtener un registro A y luego reenvía el correo por smtp al host del servicio que aparece como un servidor de correo 'dispuesto' a recibir correo para ese dominio.

Su pregunta: ¿por qué el correo no se puede enviar a una dirección IP?

Respuesta: por confianza

Muchas de las reglas vigentes con respecto al correo han evolucionado para mantener la confianza entre dominios de que los mensajes enviados de un lado a otro son realmente válidos. Todo esto es para reducir el SPAM.

  • Búsquedas inversas de IP
  • Una búsqueda directa de nombre para ese asunto

Todos estos componentes esenciales para una base para construir un servidor de correo tienen al menos algún componente pequeño fundado en la creación de comunicaciones confiables y en la reducción de comunicaciones no confiables.

Referencia - RFC 1035 y 974

https://www.ietf.org/rfc/rfc1035.txt35

https://www.ietf.org/rfc/rfc974.txt

Ciudadano
fuente
2

El propósito de los MXregistros es que una aplicación (transferencia de correo) puede aprender sobre el host que se utilizará. A nivel de aplicación, los nombres de host son lo correcto (no las direcciones IP).

Además, agregar el registro de conceot de tipo de variante a DNS introduce una palanca de complicaciones y, por lo tanto, un punto de entrada para problemas, percances de implementación, desafíos de seguridad. Por ejemplo, 1.2.3.4.example.com.es un nombre de host válido (sí, lo es, incluso a la luz de RFC1034, 3.5). Es posible que se especifique este host como MXen un archivo de configuración de enlace para example.com

.  MX 10  1.2.3.4

y presumiblemente es exactamente lo mismo que debería ser un registro MX con una IP. E incluso transferir la información en un datagrama DNS requiere algunos complementos extravagantes; la forma más sencilla sería introducir un nuevo tipo de registro de recursos, por MXAejemplo, para desambiguación. Pero, de nuevo, ¿por qué introducir la carga de un tipo de registro tan nuevo cuando

. MXA 10 5.6.7.8

siempre podría ser reemplazado por

. MX 10 dummy
dummy A 5.6.7.8

(y también sería compatible con clientes DNS que no conozcan los MXAregistros)?

Hagen von Eitzen
fuente