¿En qué circunstancias (si corresponde) debería un registro MX apuntar a localhost?


8

Estoy pensando que no hay absolutamente ninguna razón o justificación para esto, pero antes de abrir la boca y obtener algo de kimchi profundo, pensé que debería preguntar.

¿Hay alguna circunstancia en la que un registro MX debe apuntar a una dirección de bucle invertido? Para mí, esto dice que cualquier servidor de correo que intente enviar a este dominio se enviará a sí mismo y fallará, pero no soy un gurú del correo, así que tal vez me estoy perdiendo algo.

Me encontré con lo siguiente cuando solucioné un problema de ¿por qué no estamos recibiendo correo electrónico? problema para un cliente, y estoy teniendo problemas para entenderlo. Sin embargo, tal vez estoy pensando demasiado.

ingrese la descripción de la imagen aquí


77
Esto básicamente es decir, no nos envíes correo ... habla con la mano
Mike Pennington

@MikePennington Si no quisieras recibir el correo electrónico de nadie, ¿por qué harías esto en lugar de, por ejemplo, eliminar tu registro MX?
HopelessN00b

55
Si elimina el registro MX, el correo se envía al registro A para la parte del dominio de la dirección de correo electrónico. sin registro MX, obtienes un montón de personas llamando a tu puerta en busca de un servidor de correo que no responde. con una dirección de bucle invertido, el remitente llama a su propia puerta y no desperdicia su ancho de banda.
cuello largo

@longneck Ese es el resultado final, pero probablemente no sea la mejor manera de hacerlo. En mi humilde opinión contaminar el DNS público es un movimiento bastante Dick para deshacerse de los spammers que sólo le costaría unos pocos bytes de un RSTpaquete si no se está ejecutando un servidor de correo ...
voretaq7

No dije que fuera una buena idea. Estaba explicando lo que sucede cuando elimina su registro MX, y cómo eliminar los registros MX no replica la configuración solicitada.
Longneck

Respuestas:


4

Respuesta corta: no debería.

Respuesta larga: si el dominio en cuestión (DIQ) no debe recibir correo electrónico, al ingresar una dirección de bucle de retorno para el registro MX, el servidor emisor intentará conectarse a sí mismo. Esto ahorra al DIQ unos pocos bytes de medición y posiblemente limpia los registros del firewall (si alguien está mirando) cuando otros servidores de correo intentan conectarse. Sin embargo, en mi opinión, el ahorro de ancho de banda no es suficiente para justificar la violación de RFC 3330.


10

Definitivamente un NO, no con una IP 127.0.0.0. Todo el rango 127.0.0.0 en IPv4 funciona como direcciones de bucle invertido, por lo tanto, cuando cualquier máquina se conecta a IP en ese rango, intentará conectarse a sí misma.

Su dirección IP de registro MX debe ser accesible desde el mundo exterior y lo que ese resultado le dice a cualquier servidor que realice una consulta MX, para intentar conectarse a sí mismo.

Si mi servidor intentaba enviarle un correo electrónico, buscaría el registro MX y luego conectaría su propia dirección IP, enviaría el correo electrónico y fallaría.


1
+1: NO es una buena razón para NUNCA establecer un registro DNS público en una dirección en 127.0.0.0/8, 10.0.0.0/8, 172.16.0.0/12 o 192.168.0.0/8 ... (Al igual que con todos "reglas" de Internet, por supuesto, puede ignorarlo, pero lo hace bajo su propio riesgo, y solo debe hacerlo con pleno conocimiento de lo que está haciendo y por qué ...)
voretaq7

@ voretaq7warez IN A 127.0.0.1
Michael Hampton

¿@MichaelHampton sirve desde DNS público y mundial? Estoy bastante seguro de que hay algo en el RFC que dice lo hace, es el equivalente de gatitos ahogamiento ...
voretaq7

@ voretaq7 Sí, lo he visto y en muchos lugares. Se remonta al menos a la década de 1990. La forma en que se usaba era: alguien preguntaba dónde encontrar a warez, y se le daba la dirección warez.example.comque tiene este registro particular ...
Michael Hampton

6

Las RFC relevantes dicen:

  • El registro de recursos MX DEBE apuntar a un nombre de dominio completo (no una dirección IP) de un servidor en Internet público que acepte correo para el dominio. Tenga en cuenta que este servidor no necesariamente tiene que estar en el mismo dominio que el registro MX. RFC 1035 sección 3.3.9

  • Las direcciones en el rango 127.0.0.0/8 NO DEBEN aparecer en la Internet pública. RFC 5735 sección 3

Tenga en cuenta que algunos servidores de correo rechazarán el correo electrónico de los remitentes que no cumplan con los RFC relevantes .


4

Cuando un host debe poder enviarse correo a sí mismo a través de diferentes dominios alojados pero no acepta correo externo, "MX 0 localhost". es aceptable. Para indicar que un host no tiene ningún servidor de correo, utilice "MX 0".

El "MX 0". se detalla en RFC7505 .


3

Bueno, tengo una situación en la que parece ser necesario configurar el MX de un dominio en localhost.

En marzo de 2012 registré un lindo dominio que me sorprendió encontrar disponible. Fue para un sitio de colaboración artística que mi hija quería crear. Configuré el MX en uno de mis otros servidores smtp. Esto funcionó bien, pero luego comencé a recibir muchos rebotes de correo de "usuarios desconocidos" a xxx@cute-domain.com (no el nombre de dominio real). Entonces utilicé MailScanner para bloquear todos los mensajes entrantes a ese dominio, excepto una dirección legítima. Parece que el dominio era un servicio de correo electrónico gratuito a partir de 2001, pero aparentemente se había oscurecido y renunció a su lindo nombre de dominio.

Esto funcionó bien hasta hace un par de días (20/11/12) cuando el servidor smtp comenzó a rechazar los mensajes entrantes debido a conexiones abiertas excesivas. Estos fueron procesos smtp esperando respuestas de "recibo a", creo. Miré el tráfico y me bombardearon miles de mensajes entrantes para xxx@cute-domain.com de la misma cantidad de retransmisiones smtp en todo el mundo. (17,000 mensajes en un período de 24 horas)

Así que cambié el MX para apuntar a otro servidor que no ejecuta smtp con el puerto 25 bloqueado. Efectivamente, miles de sesiones caídas comenzaron a aparecer. Dado que este comportamiento se parece a una especie de torrente de spam, tal vez desde una botnet, pensé que podría requerirse configurar el MX en localhost.

Lo dejaré así por un tiempo. No necesitamos ningún correo electrónico para cute.domain.com, por lo que no se pierde nada excepto los ciclos de la botnet.


-1

¿Por qué no usar un objetivo MX que no resuelve nada? P.ej:

ejemplo.com. EN MX 10 algo inválido.

Los spammers verán el error de resolución y no se molestarán con el próximo registro MX, pensando que el objetivo está mal configurado. Los servidores reales intentarán el próximo registro. Esto no molestará al puerto TCP 25 cerrado de nadie, es decir, sin tráfico smtp, solo DNS.

Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.