Solución:
Solución 1:
Los registros DNS no pueden apuntar a puertos (con algunas excepciones de casos especiales que no se aplican aquí).
Si tiene un servicio web que escucha en el puerto 8080 y desea acceder a él sin especificar este puerto, tiene 3 opciones:
- Hágalo escuchar en el puerto 80 (o 443 con https).
- Configure lo que ya esté escuchando en el puerto 80 para reenviar solicitudes a su servicio en el puerto 8080 (proxy inverso).
- Si puede vivir con un redireccionamiento, utilícelo en lugar de un proxy, pero sus clientes verán el
:8080parte en sus barras de direcciones después de la redirección.
Solucion 2:
Los servidores web escuchan el puerto TCP 80 de forma predeterminada. Si no desea escribir el número de puerto en la URL explícitamente, tiene algunas opciones:
-
Puede reconfigurar su servidor web para usar el puerto 80 en lugar del puerto 8080. Esto se recomienda para servidores web como nginx o Apache, pero no para servidores web como Gunicorn. Esta opción tampoco siempre es posible, ya que es posible que ese puerto ya esté siendo utilizado por un servidor web diferente.
Además, cuando su servidor está detrás de una puerta de enlace NAT, no posee la dirección IP pública y es posible que la combinación de esa dirección NAT pública y el puerto 80 ya se haya reenviado a un servidor web diferente.
-
Puede poner un servidor proxy inverso frente a su servidor web que acepta el tráfico en el puerto TCP 80 y lo envía a su servidor web en el puerto TCP 8080. Esto también funcionará si el puerto 80 ya está en uso. Simplemente coloque el servidor proxy inverso frente a ambos servidores web, para que ambos escuchen puertos distintos del 80.
Para proporcionar una ayuda mejor y más detallada sobre qué opción podría ser la mejor y las limitaciones, etc., necesitamos saber más sobre su configuración. Ojalá esta explicación ya aclare un poco las cosas.
Solución 3:
Respuesta simple, relacionada con el nivel de la pregunta.
Ignorando los usos exóticos de DNS y también la búsqueda de DNS inversa (no es relevante para la pregunta), casi todo el uso de DNS tiene la forma:
- El cliente envía el nombre de dominio (totalmente calificado o no) a un servidor DNS
- El servidor DNS devuelve información de dominio de sus registros. Por lo general, la información clave solicitada es la dirección IP para comunicarse con la web / correo electrónico en ese dominio, o la dirección IP de otro servidor DNS que pueda proporcionar esa información.
Una vez que el cliente se ha puesto en contacto con el servidor, el servidor mismo se hará cargo y el sistema DNS desaparecerá.
Lo que eso significa es que el sistema DNS no necesita proporcionar información del puerto, y casi nunca lo hace. Entonces, aunque el objetivo de la pregunta es válido, y se hace a menudo, en realidad no es el sistema DNS el que lo hace. Es por eso que no puedes resolverlo 🙂
La idea es que una vez que su cliente pueda localizar la máquina o servidor específico que está buscando, depende de esa máquina escuchar en cualquier puerto que elija y aceptar / denegar / responder a cualquier protocolo en cualquier puerto configurado.
Por ejemplo, los servicios web HTTP generalmente se proporcionan en el puerto 80. Eso significa que una vez que el cliente conoce la IP de una máquina, puede asumir que enviar un mensaje al puerto 80 dará como resultado que el servicio web de esa máquina lea / responda ese mensaje. Pero no tiene por qué ser así. Si el servidor está configurado para escuchar las solicitudes entrantes web en el puerto 9000, cualquier cliente que pueda acceder al puerto 9000 podrá acceder a su servicio web. Si el servidor está detrás de un proxy / NAT / enrutador que redirige el puerto 10000 al puerto 9000, y el cliente envía una solicitud web en el puerto 10000, el servidor la recibirá en el puerto 9000 y también responderá.
Redirigir / mapear dentro del servidor web
Preguntó sobre el mapeo de redireccionamiento o reescribió en un comentario. Estas son funciones que puede realizar un servidor web. Básicamente, puede configurar el servidor web (o la mayoría / muchos servidores web) para administrar cómo maneja la URL que recibe en una solicitud. Por lo tanto, puede modificar internamente la URL al recibirla para hacer que diferentes URL se manejen de la misma manera, o corregir errores tipográficos comunes (mapeo), o puede responder para decirle al cliente que pregunte por segunda vez, utilizando una URL de reemplazo diferente. (redirigir).
Estos tienen sus usos y, en principio, podrían manejar su caso de uso, pero no suenan como la solución “correcta” para usted, por estas razones:
- No creo que el mapeo ayude en absoluto. El mapeo es casi totalmente interno al servidor web, dice “tratar esta URL como si fuera ese URL “. Por ejemplo, puede utilizar la asignación de URL del servidor web para permitir que un usuario consulte un foro utilizando URL muy antiguas, antiguas y actuales (para comodidad del usuario) utilizando” https://example.com/index.php?area – = forum & topic = 2 “, también” https://example.com/forum.php?topic=2 “y también” https://forum.example.com?topic=2 “, y solo maneja esto una vez, por mapear los dos primeros de estos en la tercera URL internamente, como el primer paso en el manejo de la consulta. Como estos destinos afectan la ruta de la consulta, no la IP / puerto, el mapeo no es de mucha utilidad para la administración de puertos, y en su caso, el el cliente nunca consulta 8080 en absoluto.
- La redirección funcionaría, pero puede que no sea lo que desea. La redirección en el servidor web depende de que el servidor web reciba realmente la consulta (porque estas son funciones internas del servidor web). Entonces, el servidor web tendría que escuchar en el puerto 80 de todos modos para obtener la consulta original, a fin de responder con la redirección / mapa. Sería además tiene que escuchar en el puerto 8080. Funcionalmente, necesitaría una regla de redireccionamiento para tener que decirle a cualquier cliente que consulte el puerto 80, que lo vuelva a consultar usando la URL “: 8080”, que no suena como lo que quiere hacer. El usuario también verá la nueva URL con “: 8080” en ella, mientras que parece que desea que sea “transparente” y no se muestre.
- Además, la redirección solo funcionaría para redirigir un puerto estándar (80 o 443) – no podría redirigir el puerto 2000 a 8080, digamos, porque el cliente no consultaba en 2000 de forma predeterminada, en primer lugar, por lo que nunca llegaría al servidor web, incluso si estuviera escuchando en 2000. Esto Aunque podría no ser un problema para ti.
Sin embargo, si desea una redirección “inteligente”, donde solo ciertas consultas se redireccionan a 8080, este podría ser el camino a seguir, porque la redirección puede incluir lógica para decidir qué URL se deben redirigir, mientras que la asignación de puertos (a continuación) se asignaría todo.
Cómo hacerlo correctamente
La respuesta a su pregunta es, desea que el servidor web responda a las solicitudes web que el cliente envía al puerto predeterminado (80/443), pero que el servidor realmente recibe en el puerto 8080.
Eso significa que, como puede ver, necesita algo intermedio mapea los puertos entre el cliente y el servidor. De esa manera, el cliente envía en el puerto 80 (puerto predeterminado utilizado por los navegadores web), pero el servidor web lo recibe en el puerto 8080. Por supuesto, tendrá que configurar el servidor web para escuchar en el puerto 8080, ya que esto no es estándar, pero es fácil y cualquier servidor web debería poder tener sus puertos de escucha especificados.
La forma más habitual de hacer esto sería dentro del enrutador / firewall, a través de la asignación de puertos.
En términos simples, para hacer esto, el enrutador recibe una regla, que todo lo recibido que tenga una IP de destino y un puerto de destino = 80, debe pasarse a la LAN con el puerto de destino cambiado a 8080 en su lugar. Ni el servidor web ni el cliente se darán cuenta del cambio (es 100% manejado por el enrutador), por lo que será 100% transparente para ambos. El cliente no tendrá “: 8080” en su URL y no necesitará redirigir nada, ya que consulta el puerto 80, y el servidor web puede ignorar el puerto 80 y escuchar solo en 8080, ya que nunca recibe consultas en el puerto 80 .
Si desea una forma simple y directa, similar a lo que haría un “DNS para puertos”, este es probablemente el equivalente más cercano a lo que está pidiendo en su pregunta.
Solución 4:
No puedes.
Quiero decir, técnicamente esto podría hacerse. DNS es famoso por poder enviar un nombre de dominio y obtener una dirección IP. Sin embargo, he estudiado un poco el protocolo DNS, y realmente el DNS es técnicamente capaz de actuar como un mecanismo de consulta / respuesta para mucho más que solo nombres de dominio y direcciones IP. Un enfoque posible sería utilizar un registro de recursos DNS que no sea del tipo A o AAAA típico, como un registro TXT (que técnicamente es solo texto y podría usarse para cualquier cosa) o quizás un registro SRV, o cualquier otro el tipo de registro de recursos más nuevo que elija.
Si está creando su propio software (tanto de cliente como de servidor), es posible que no haya ninguna razón técnica para no hacer tal cosa, excepto que sepa que algunas personas usan compañías de alojamiento de DNS y las limitan a usar solo ciertos tipos de registros. Eso es lamentable, ya que las personas que ejecutan sus propios servidores DNS ciertamente tienen suficiente flexibilidad para tales cosas.
Sin embargo, si no está creando su propio protocolo de red (por ejemplo, si desea usar HTTP), es probable que encuentre un problema importante, que es que el software existente no usará su solución personalizada, a menos que use soluciones que ya están establecidas. Esa será la barrera. No es una imposibilidad técnica. Una barrera social: ¿Puedes convencer a todos de que hagan las cosas a tu manera?
Sin embargo, ahora que he explicado por qué no puede hacer eso, es posible que tenga una solución para lo que está buscando. Primero, echemos un vistazo a por qué incluso tenemos direcciones IP y puertos.
Las direcciones IP y los puertos hacen cosas diferentes. El propósito de la dirección IP es cumplir con los objetivos de las Capas 2 y 3 del Modelo OSI de comunicaciones de red. El propósito de la dirección IP es identificar a qué computadora se supone que va el tráfico. El hecho de que podamos usar un número de puerto para ese propósito, al hacer que los firewalls / enrutadores investiguen los números de puerto para realizar NAPT (traducción basada en puertos de direcciones de red, también llamada a veces PNAT o simplemente NAT), es una técnica más nueva que utiliza un recurso (información), pero no formaba parte del diseño original. Si nos alejamos de este “abuso” de los números de puerto durante un minuto y consideramos el diseño original, es posible que podamos encontrar una solución más sencilla. Con el diseño de Internet, se suponía que las máquinas se encontraran utilizando direcciones IP.
El objetivo de un “número de puerto”, utilizado por TCP y UDP y algunas alternativas, es poder realizar un seguimiento de las conversaciones individuales. Esto ayuda a alinear la comunicación con los programas en ejecución. Entonces, si una máquina recibe tráfico en el puerto TCP 80, la máquina sabrá que el tráfico de red está destinado a ser utilizado por el programa que es el servidor web. Si un navegador web descarga varios gráficos simultáneamente, las combinaciones de números de “puerto de origen” y números de “puerto de destino” pueden realizar un seguimiento de qué datos están destinados a qué gráfico, por lo que esas conversaciones simultáneas pueden ocurrir sin mezclar los datos.
Ahora, supongo que tiene acceso a un servidor DNS, y le parece que piensa que la administración de DNS sería conveniente para poder manejar un poco más el enrutamiento del tráfico. Pero el DNS no parece poder ayudarlo a obtener un número de puerto. ¿Qué puedes hacer?
Considere IPv6. IPv6 le permite tener muchas más direcciones IP. Además, a diferencia de algunas implementaciones de IPv4, los dispositivos que usan IPv6 generalmente pueden admitir fácilmente varias direcciones IPv6 activas al mismo tiempo. Por lo tanto, si desea tener tres protocolos de red diferentes en una computadora, puede asignar al menos tres direcciones IPv6 diferentes a la misma computadora. Y luego puedes hacer cualquier ruta travesuras que te gustan con esas direcciones IPv6.
Luego, puede usar el tipo de registro de recursos AAAA para asignar un nombre a esa dirección IPv6, que el diseño de su red puede tratar como si estuviera efectivamente dedicada al servicio específico en la computadora específica que desea.
Wallah, ahora tiene DNS apuntando efectivamente a la pieza de software, y logró ese objetivo sin necesidad de intentar confiar en hacer que DNS apunte a un número de puerto, lo que no funciona bien simplemente porque esa funcionalidad no es común. soportado.
Posible objeción:
Y si se siente atrapado con IPv4 y cree que IPv6 de alguna manera no es compatible, le animo a que intente abordar ese problema. Ese problema probablemente será más fácil de solucionar (tal vez usando algún tipo de tunelización), y probablemente terminará siendo una solución más gratificante una vez que lo haya implementado.