Te estás confundiendo al pensar en cómo fluye la información entre las capas de la pila de protocolos TCP / IP, específicamente entre los protocolos de capa de DNS y de aplicación.
Tienes una dirección IP pública. Su DNS sin duda puede resolver tanto mail.example.comy example.comcon la misma dirección IP pública.
En general, los datagramas IP que contienen solicitudes a su dirección IP pública, que serán recibidos por la interfaz externa de su firewall, no contienen el nombre del host al que intenta acceder el cliente remoto. Su firewall no puede "saber" mágicamente qué nombre de host resolvió el cliente remoto, ya que ambos nombres de host se resuelven en la misma dirección IP. La capa IP no conoce el nombre de host utilizado en la capa de aplicación.
Los protocolos TCP y UDP diferencian servicios específicos ofrecidos por un host utilizando números de puerto. En el caso de su ejemplo, es posible utilizar la función de reenvío de puertos (también llamada traducción de dirección de puerto o PAT) de su cortafuegos NAT para enviar solicitudes entrantes al puerto TCP 80 (HTTP) al servidor web mientras envía el puerto TCP entrante 25 (SMTP) a su servidor de correo electrónico.
Sin embargo, si planea alojar el mismo servicio en ambas máquinas, esta estrategia se vuelve problemática. Suponga que va a alojar un sitio web seguro en su servidor web (para acceso del Cliente) y un sitio web seguro en su servidor de correo electrónico (para webmail). Las solicitudes que llegan a la dirección IP pública de su firewall NAT al puerto TCP 443 (HTTPS) solo se pueden enrutar a un servidor u otro.
La solución generalizada a esta situación es tener más direcciones IP públicas. Debido a que las direcciones IPv4 se están volviendo escasas, eso también puede ser problemático.
Terminamos trabajando en torno a la escasez de direcciones IP públicas en algunos protocolos en la capa de aplicación. Por ejemplo, HTTP / 1.1 agregó el Host:encabezado específicamente para permitir que un servidor web aloje múltiples sitios web en la misma dirección IP pública. TLS agrega la extensión de Indicación de nombre de servidor (SNI) para permitir la selección del certificado apropiado basado en el nombre de host ingresado por el cliente remoto.
Hacer este tipo de solución en la capa de aplicación significa que cada protocolo de capa de aplicación necesitaría su propia "solución" (y luego todo el servidor y el software del cliente tendrían que implementar esa "solución"). Esa es una tarea difícil.
En lugar de modificar el protocolo de la capa de aplicación, algunos protocolos son fácilmente susceptibles de ser "multiplexados" entre múltiples hosts utilizando un software que puede "enrutar" las solicitudes. Esto probablemente va más allá de lo que es capaz de hacer un simple firewall NAT porque los paquetes deben ser inspeccionados en la capa de aplicación. El uso de un proxy inverso como nginx es un buen ejemplo de este tipo de "multiplexación" (o reglas de publicación web en Forefront TMG o ISA Server en un entorno de Microsoft) para el protocolo HTTP. En teoría, cualquier protocolo podría multiplexarse a través de un proxy inverso, pero cuanto más esotérico sea el protocolo, más probable es que esté hablando de tener un código personalizado escrito.
Cuando necesite ofrecer el mismo servicio desde dos hosts diferentes en una sola dirección IP pública, siempre tiene la opción de mover uno de los hosts a un puerto no estándar. Sin embargo, esto requerirá que los clientes conozcan el puerto no estándar. En el caso de HTTP (S), esto da como resultado URL con la http://example.com:XXXnotación (donde XXXestá el número de puerto no estándar). Si esto sería problemático en su situación es algo que solo usted puede decidir. (Mi experiencia ha demostrado que prácticamente ningún usuario final es capaz de manejar la :XXXnotación de puertos en cualquier URL que deba ingresar manualmente).