email - gsuite - registros mx gmail

La aplicación CNAME para Azure causa problemas de correo electrónico con registros MX y A ignorados (4)

Tenemos una aplicación que se ejecuta en Microsoft Azure y hemos configurado un registro CNAME para cubrir el dominio para que podamos tener la buena URL de http://example.com (tenga en cuenta que estoy reemplazando nuestro dominio real con example.com a lo largo de este).

CNAME mydomain.com -> mydomainapp.cloudapp.net

Tenemos los registros MX y A configurados correctamente, por lo que MX contiene mailserver.example.com y un registro A que apunta al servidor de correo a la dirección IP correcta.

MX mailserver.example.com A mailserver -> 198.168.111.111 (note this IP is fictitious)

Todo bien, para la mayoría del correo electrónico PERO para algunos servidores de correo (no estoy seguro de qué tecnología), ahora están usando el CNAME en lugar de los registros MX y A.

Por lo tanto, un correo electrónico dirigido a [email protected] se envía a [email protected] donde example.cloudapp.net es el dominio en Azure que hemos correlacionado con CNAME.

EMAIL TO: [email protected] BECOMES: [email protected]

Las únicas sugerencias que puedo encontrar simplemente dicen NO tienen el nivel de dominio CNAME o no usan CNAME en absoluto, pero, por supuesto, las direcciones IP de Azure pueden cambiar, así que tenemos que usar CNAME. Podríamos prefijar todo www.example.com pero seguramente debe haber una mejor solución.

Cualquier idea muy apreciada.

Sí, hay una mejor solución: use un dominio de segundo nivel para su aplicación. Deje que sea portal.mydomain.com y use un CNAME para asignar portal.mydomain.com a mydomainapp.cloudapp.net y configure el registro MX para mydomain.com y tenga todas las direcciones en la forma [email protected] . De esta manera, queda claro que usted es dueño de mydomain.com y que todos sus correos electrónicos aún se ven serios: [email protected] , no [email protected] .

Btw técnicamente la configuración descrita anteriormente significa que no tiene un nivel de dominio CNAME .

OK, después de mucha investigación parece que la mejor solución (al menos en mi opinión) es utilizar un registro A en lugar de CNAME para el registro de nivel de dominio.

Puede estar gritando "¡qué! ¡Pero la dirección IP está asignada dinámicamente!". Sí, pero solo si destruye su implementación y la reemplaza. Windows Azure le mantendrá su dirección VIP siempre que publique en etapas y use la opción "cambiar producción y puesta en escena". Al hacerlo, conserva su dirección VIP para que pueda usar un registro A en su DNS en lugar de un CNAME.

Consulte http://www.windowsazure.com/en-us/develop/net/common-tasks/custom-dns/ para obtener información general.

Tenga en cuenta que la línea oficial de MS es recomendar CNAME en lugar de un registro A debido al posible intercambio de una dirección IP, pero supongo que no están pensando en personas que desean ejecutar http://mydomain.com en la plataforma Azure.

También encontré otras soluciones posibles, incluida la creación de un oyente SMTP en su aplicación que lee el correo en el puerto 25 y lo reenvía. Técnicamente bueno, pero me vienen a la cabeza los mazos y las nueces, además de que es una cosa más para ir mal, y por supuesto, un montón más de recursos para pagar.

Usamos un registro A para nuestro dominio raíz y esto funciona bien, como dijo @Jezbers en su respuesta. El registro A no romperá el correo electrónico. Sin embargo, el registro CNAME afecta los otros registros (le permite tener la funcionalidad de "redireccionamiento de dominio" por lo que [email protected] también funciona para [email protected]).

Si estaba buscando una mejor solución de "solución alternativa" que la solución de problemas del Listener SMTP, entonces puede considerar lo siguiente:

Aloje su sitio en un subdominio www y coloque el CNAME allí. Haga que otra cosa aloje una redirección 301 a www y use un registro A para dirigir su dominio raíz a este sitio de redirección.

No es perfecto, pero una opción que es mejor que la opción SMTP, lo más probable.

No es posible utilizar un registro CNAME en el nivel de dominio, ya que CNAME es un alias para todos los tipos RR, por lo que siempre provocará una redirección para las búsquedas MX, SOA, NS, etc.

El siguiente extracto de la sección 2.4 de RFC1912 lo dice muy claramente:

No se permite que un registro CNAME coexista con ningún otro dato. En
en otras palabras, si suzy.podunk.xx es un alias de sue.podunk.xx,
tampoco puede tener un registro MX para suzy.podunk.edu, o un registro A, o
incluso un registro TXT. Especialmente no intente combinar CNAME y NS
registros como este !:
podunk.xx. IN NS ns1 IN NS ns2 IN CNAME mary mary IN A 1.2.3.4
A menudo, administradores inexpertos lo intentan como una forma obvia de permitir que su nombre de dominio también sea un host. Sin embargo, los servidores DNS como BIND verán el CNAME y se rehusarán a agregar otros recursos para ese nombre. Dado que no se permite que otros registros coexistan con un CNAME, las entradas NS se ignoran. ¡Por lo tanto, todos los hosts en el dominio podunk.xx también son ignorados!

¡Entonces no debes usar un registro CNAME para mydomain.com !

Por lo tanto, debe establecer un registro A para mydomain.com (entre MX: s y otros registros según sea necesario), porque esa es la única solución que funciona en DNS.