Nuestra empresa tenía 4 dominios cuyos correos electrónicos y DNS estaban alojados en usintegration.com, y luego trasladamos el alojamiento de correo electrónico y DNS de 3 de los 4 dominios a una nueva empresa. Ahora, los 3 dominios que fueron movidosNo puedo enviar ni recibir correos electrónicos hacia y desde el único dominio que aún queda en el servidor anterior.. Todas las demás funciones de correo electrónico funcionan bien para los 4 dominios. No hay rebotes, mensajes de error ni correos electrónicos atascados en la cola, y no hay evidencia de que estos correos electrónicos faltantes lleguen a los nuevos servidores.
La nueva empresa de alojamiento (logixcom.com) confirma que todo está bien por su parte y me asegura que lo más probable es que aún quede un archivo de zona antiguo en el servidor de nombres de US Integration, por lo que los correos electrónicos enviados desde US Integration se enrutan a lo que cree que sigue siendo el servidor de nombres autorizado (es propio). Debido a que los registros MX del archivo de zona antiguo todavía contienen el recurso antiguo, las solicitudes nunca abandonan el servidor de nombres antiguo para conectarse y realizar una nueva búsqueda del servidor de nombres autorizado real (nuevo). El problema agravante es que la integración de Estados Unidos no es capaz de identificar el problema, y mucho menos solucionarlo.
¿El problema es realmente que este antiguo archivo de zona solo necesita eliminarse del servidor de nombres de US Integration? Si es así, ¿cuál es la mejor manera de describirles esto? Si no, ¿cuál crees que podría ser el problema? Cualquier ayuda es muy apreciada. No estoy en TI, así que todo esto es nuevo para mí. Sé que parece extraño para mí (el cliente) tener que hacer este trabajo preliminar, pero solo quiero resolverlo.
Esto es lo que he hecho:
Realicé una excavación para verificar que los registros MX de US Integration todavía apuntan al antiguo servidor de nombres autorizado, en lugar de conectarse a Internet para realizar una nueva búsqueda:
~$ dig @bart.usintegration.com courycollection.com mx ; <<>> DiG 9.6.0-APPLE-P2 <<>> @bart.usintegration.com courycollection.com mx ; (1 server found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 61227 ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1 ;; QUESTION SECTION: ;courycollection.com. IN MX ;; ANSWER SECTION: courycollection.com. 3600 IN MX 10 mail.usintegration.com. ;; ADDITIONAL SECTION: mail.usintegration.com. 3600 IN A 65.198.191.5 ;; Query time: 29 msec ;; SERVER: 65.198.191.5#53(65.198.191.5) ;; WHEN: Sun Dec 26 16:59:22 2010 ;; MSG SIZE rcvd: 88Realicé una investigación para intentar ver dónde miran los servidores de Logix cuando se envían correos electrónicos desde los 3 dominios que se movieron y fueron rechazados:
~$ dig @faith.logixcom.net.net colcordhotel.com mx ; <<>> DiG 9.6.0-APPLE-P2 <<>> @faith.logixcom.net colcordhotel.com mx ; (1 server found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: REFUSED, id: 31599 ;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0 ;; WARNING: recursion requested but not available ;; QUESTION SECTION: ;colcordhotel.com. IN MX ;; Query time: 31 msec ;; SERVER: 216.201.128.10#53(216.201.128.10) ;; WHEN: Sun Dec 26 17:00:14 2010 ;; MSG SIZE rcvd: 34
ACTUALIZACIÓN 28/12/10:US Integration dijo que eliminaron los archivos de zona y la investigación posterior muestra que sus solucionadores ahora apuntan al servidor de nombres Logix correcto, pero los problemas persisten. Lo curioso es que el propietario de US Integration (que tiene un correo electrónico @usintegration.com) puede enviarme un correo electrónico (que tiene un correo electrónico @courycollection.com), pero nuestra propiedad hermana (colcordhotel.com, alojada en US Integration ) todavía no puede enviarnos.
Respuesta1
¿Se han eliminado por completo los dominios antiguos del servidor de correo antiguo? En muchos servidores de correo, si un dominio se define como un nombre servido por ese servidor, ni siquiera buscará en DNS para ver dónde se debe entregar el correo (dado que ya aloja ese dominio, no es necesario buscarlo). El correo de dominio-antiguo.com a otros-dominios.com simplemente se entregaría localmente si todavía estuvieran configurados en el servidor de correo, independientemente de lo que DNS indique que tiene que ver con él.
En cuanto al correo entrante, también podría estar relacionado. Si el servidor receptor ve correo procedente de Internet en dominios que se supone que son locales (es decir, SMTP entrante sin ningún tipo de autenticación o desde un rango de IP conocido), es posible que lo esté tratando como sospechoso y filtrándolo como spam.
Este tipo de cosas también son más fáciles de diagnosticar cuando se utilizan dominios reales. Los dominios de ejemplo son excelentes para problemas teóricos o genéricos, pero los específicos funcionan mucho mejor para problemas específicos.