El DNS inverso no es un nombre de host válido [cerrado]

Ayudo a un amigo a ejecutar un servidor, que incluye un servidor de correo. http://mxtoolbox.com informa que nuestro DNS inverso no es un nombre de host válido.

El DNS inverso actualmente apunta a domain.com. ¿Debería señalar hostname.domain.com? He visto aquí que es convencional usar este esquema para DNS inverso. Sin embargo, esto causará un problema si el servidor de correo responde así:

220 domain.com ESMTP Postfix (Ubuntu)
EHLO PWS3.mxtoolbox.com
250-domain.com
250-PIPELINING
250-SIZE 10240000
...

Básicamente, ¿será válido el DNS inverso que apunta a un subdominio del dominio que informa el servidor de correo?

EDITAR: Mi pregunta original fue la siguiente: Si el servidor de correo informa domain.comcomo su FQDN, ¿puede apuntar el DNS inverso hostname.domain.com? Vea los comentarios a continuación para saber por qué esto no es necesario y por qué ambos deberían ser lo mismo.

postfix reverse-dns ptr-record

— ConnorJC
fuente

Posible duplicado de: serverfault.com/questions/711600/…

— Håkan Lindqvist

Realmente no. Quería saber si hostname.domain.comes válido como DNS inverso para el correo hacia / desde domain.com, mientras que la otra publicación quería saber cuál debería ser su DNS inverso. Mi respuesta utiliza la respuesta de la otra publicación y hace una pregunta al respecto.

— ConnorJC

Ok, en ese caso, ¿podría aclarar por qué quiere que el servidor de correo informe algo más que el nombre de host en primer lugar? Idealmente, el nombre de host que informa el MTA debe ser el nombre de host real, al igual que la entrada dns inversa.

— Håkan Lindqvist

Bueno, antes de que @Halfgaar respondiera a mis preguntas anteriores, pasé por alto que SPF se usa para validar si un servidor puede enviar correo domain.com, no el FQDN informado. Originalmente supuse que el servidor tendría que informar domain.compara enviar el correo domain.com. Como me di cuenta recientemente, podría usarlo v=spf1 mx -allcomo registro SPF para permitir que la otra máquina envíe correo. Esto se aclaró en los comentarios de la respuesta aceptada.

— ConnorJC

Respuestas:

Básicamente, ¿será válido el DNS inverso que apunta a un subdominio del dominio que informa el servidor de correo?

No. Simplemente dale a tu servidor un nombre completo como myserver.mydomain.com. Asegúrese de que su DNS inverso también contenga myserver.mydomain.com, y que el servidor de correo también se haya anunciado (con HELO) myserver.domain.com.

Técnicamente, podría serlo mail.domain.com, pero eso significa que sería el nombre de host no FQDN de la máquina mail, lo que no es elegante.

No tenga su nombre de host domain.com, (creo que) el dominio debe ser la entidad organizativa, no un nombre de host.

— Halfgaar
fuente

Sin embargo, el servidor de correo tiene que anunciarse como servidor de dominio.com para enviar correos electrónicos como usuario@dominio.com, ¿verdad? Si el servidor de correo se anuncia como myserver.domain.com, ¿no será necesario que las direcciones de correo electrónico sean user@myserver.domain.com?

— ConnorJC

Además, no estoy seguro de lo que quieres decir con no tener mi nombre de host domain.com, ¿te refieres al FQDN? Actualmente, el nombre de host de la máquina de correo es vps1, por lo que el DNS inverso debe apuntar en vps1.domain.comlugar de domain.com, ¿correcto?

— ConnorJC

The mail server has to announce itself as serving domain.com to send emails like user@domain.com though, right? If the mail server announces itself as myserver.domain.com, won't the email addresses need to be user@myserver.domain.com?

- No. Para eso están los registros SPF.

— joeqwerty

Oh ya veo. Gracias. Solo para aclarar, mi registro MX debería cambiarse de domain.coma vps1.domain.com. Además, el registro SPF de v=spf1 mx -alldebería funcionar con esta configuración. ¿Es eso correcto?

— ConnorJC

Si y si. Para aclarar: Un registro MX designa donde el correo electrónico va A . Un registro SPF designa donde el correo electrónico proviene DE .

— joeqwerty

Se espera que tanto el nombre de host que informa el software del servidor de correo como la entrada de DNS inversa sean el nombre de host fqdn canónico real (como se discutió en la pregunta de referencia para el caso de DNS inverso).

Sin embargo, generalmente no se verifica que estos dos valores realmente coincidan (aunque tenga más sentido si lo hacen).

Tenga en cuenta que no se espera que el nombre de host especificado en ninguno de estos lugares tenga necesariamente ninguna relación con los nombres de dominio para los que el servidor de correo acepta o envía correo; identifica el servidor de correo en sí, no los dominios que maneja.

— Håkan Lindqvist
fuente