No recibir correos de algunos remitentes debido a la configuración de DNS

He notado un comportamiento peculiar de mi dominio de aplicaciones de google. La mayoría de los correos llegan como era de esperar, pero durante un período de tiempo he llegado a la conclusión de que los correos de ciertos remitentes no llegan. Después de identificar a uno de esos remitentes, cuyos correos no se enviaron, le pedí que intentara enviarme un correo electrónico y reenviar la respuesta de "error de entrega" a mi correo regular de Gmail.

La respuesta de falla de entrega contenía el siguiente fragmento:

----- Transcripción de la sesión sigue -----
<myusername@GHS.L.GOOGLE.COM>... Diferido: La conexión ha excedido el tiempo de espera con ghs.l.google.com.

Esto me ayudó a identificar el problema haciendo una búsqueda rápida que me llevó a esta página en el Foro de ayuda de Google Apps. De hecho, verifiqué el registro DNS de mi dominio y me @configuré en ghs.google.com. (CNAME), que no debería ser. Cambiar eso a @ 74.125.93.121 (A)* resolvió el problema.

Entiendo que en los casos en que el correo no llegaba, mi nombre de dominio fue sustituido por su nombre canónico a través de una búsqueda de CNAME, por lo que el correo se envió en myusername@ghs.l.google.comlugar de myusername@mydomain.com. Pero, ¿por qué funcionó para la gran mayoría de los remitentes? ¿Los remitentes cuyo correo no llegó, utilizaron algún tipo diferente de protocolo de correo, algunas configuraciones de DNS extrañas o qué podría ser?

Por lo que pude ver al investigar el problema en Google, este parece ser un problema muy extendido (muchas personas se quejan de que no se reciben correos electrónicos de battle.net, sería un ejemplo popular), solo que la gente no parece tener en cuenta que el problema radica en su propia configuración de DNS, y no en el lado de los remitentes.

Entonces, ¿cómo se puede explicar esto?

^{* Utilicé esta IP por lo que leí aquí , pero creo que cualquier IP funcionaría. ¿Alguien puede confirmar esto? Tenga en cuenta que simplemente eliminar el @registro no resolvió el problema, tuvo que ser cambiado.}

Del RFC 2821 "Protocolo simple de transferencia de correo", sección 5 "Resolución de direcciones y manejo de correo":

La búsqueda primero intenta localizar un registro MX asociado con el nombre. Si se encuentra un registro CNAME, el nombre resultante se procesa como si fuera el nombre inicial.

En general, así es como funcionan los CNAME. A menudo son mal utilizados, mal entendidos y mal implementados. :-)

Si su dominio es example.com, probablemente tenga registros MX existentes que apuntan a los hosts habituales de Google Apps.

example.com. MX 10 ASPMX.L.GOOGLE.COM.
example.com. MX 20 ALT1.ASPMX.L.GOOGLE.COM.
example.com. MX 20 ALT2.ASPMX.L.GOOGLE.COM.
example.com. MX 30 ASPMX2.GOOGLEMAIL.COM.
example.com. MX 30 ASPMX3.GOOGLMAILE.COM.
example.com. MX 30 ASPMX4.GOOGLEMAIL.COM.
example.com. MX 30 ASPMX5.GOOGLEMAIL.COM.

Parece que también tenías una entrada como esta:

example.com. CNAME ghs.l.google.com.

El RFC 1034 "Conceptos e instalaciones de dominio" establece en la sección 3.6.2 "Alias ​​y nombres canónicos" recomienda contra esta configuración:

Si un CNAME RR está presente en un nodo, no deben estar presentes otros datos; Esto asegura que los datos para un nombre canónico y sus alias no pueden ser diferentes.

En el caso del error que pegó, el servidor de correo y / o el servidor DNS en el extremo emisor intentaron buscar registros MX para su dominio, example.com, y encontraron un CNAME que apuntaba a ghs.l.google. com. Luego intentó buscar los registros MX de ghs.l.google.com. Ese dominio actualmente no tiene ningún registro MX, por lo que el servidor de correo habría caído en el registro A de ghs.l.google.com. Esa dirección IP no estaba escuchando en el puerto SMTP, por lo que el resultado es el error "La conexión agotó el tiempo de espera con ghs.l.google.com".

Al eliminar el registro CNAME, ha solucionado sus problemas de correo. Puede encontrar problemas si la dirección IP que ha definido en su lugar se cambia al final de Google.

En su lugar, podría definir el cname para www.example.com:

www.example.com. CNAME ghs.l.google.com.

Y ejecute un pequeño servidor web en cualquier IP al que señale example.com, que simplemente redirige HTTP a http://www.example.com/

Es algo sorprendente que funcionó tan bien como lo hizo. La ley de Postel tiene algo de crédito allí, creo. :-)

Volver a RFC 1034 2.6.2:

Los RR de CNAME provocan acciones especiales en el software DNS. Cuando un servidor de nombres no puede encontrar un RR deseado en el conjunto de recursos asociado con el nombre de dominio, verifica si el conjunto de recursos consiste en un registro CNAME con una clase coincidente. Si es así, el servidor de nombres incluye el registro CNAME en la respuesta y reinicia la consulta en el nombre de dominio especificado en el campo de datos del registro CNAME. La única excepción a esta regla es que las consultas que coinciden con el tipo CNAME no se reinician.

Entonces, en este caso se podría argumentar que el servidor DNS no debería / debería seguir el CNAME en una búsqueda MX a menos que no se encontraran registros MX.

Al enviar correo, Sendmail y qmail (y probablemente otros) intentarán por defecto reescribir cualquier CNAME utilizado en el lado derecho de una dirección de correo electrónico con el nombre canónico.

De hecho, algunos sitios confiaron en este comportamiento. djb detalla por qué piensa que la gente debería dejar de confiar en él en su documento "CNAME records in mail" .

El @símbolo en un registro BIND es solo una forma abreviada de escribir el dominio. Si está creando un registro para example.com, entonces @es solo un alias para example.com. Decir que el @registro tenía que ser una IP es una declaración a la que le falta información crítica: no nos dijo qué tipo de registro era.

Según el informe de entrega, parece que quizás haya hecho algo con su DNS para que el servidor de correo remoto reescriba su dominio a ghs.l.google.com - muy extraño (PS, un registro A debe ser una IP, un registro CNAME no debe ser una IP u otro registro CNAME).

Por qué el servidor de correo de esa persona está reescribiendo su dirección es extraño, no debería, a menos que esa persona haya hecho algo para decirle explícitamente que lo reescriba. Tampoco debería importarle en absoluto cuál es la IP de su dominio a menos que no pueda encontrar ningún registro MX, ya que los registros MX son la forma en que los servidores de correo determinan a dónde va el correo.

Me parece que, dada la muy poca información proporcionada, no siguió las instrucciones de Google sobre cómo configurar correctamente su DNS para el correo electrónico. Probablemente incluso tenga algunos errores en su archivo de zona: haga que un administrador de zona competente los revise.