Soy bastante nuevo en la administración de redes y, por lo tanto, ya estoy entusiasmado de haber configurado con éxito un registro DNS.

Ahora estoy un poco confundido, porque me gustaría tener esta URL:

http://www.example.org:8080/fetch/characters/

ser alcanzado por esto

http://www.example.org/fetch/characters/

Para que los usuarios puedan acceder al servicio en el puerto 8080 sin tener que configurar explícitamente el puerto.

¿Cómo puedo hacer esto? ¿Necesito alguna aplicación especial en mi servidor? ¿O algún material de redireccionamiento que se aplicará a las solicitudes?

Los registros DNS no pueden apuntar a puertos (con algunas excepciones de casos especiales que no se aplican aquí).

Si tiene un servicio web, escuche en el puerto 8080 y quiera llegar a él sin especificar este puerto, tiene 3 opciones:

• Haga que realmente escuche 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 una redirección, use esto en lugar de un proxy, pero luego sus clientes verán la :8080parte en sus barras de direcciones después de la redirección.

Los servidores web escuchan el puerto TCP 80 de manera 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 ese puerto ya podría estar en uso por un servidor web diferente.

  Además, cuando su servidor está detrás de una puerta de enlace NAT, no es el propietario de la dirección IP pública y la combinación de esa dirección NAT pública y el puerto 80 podría ya haberse reenviado a un servidor web diferente.

• Puede colocar un servidor proxy inverso frente a su servidor web que acepte el tráfico en el puerto TCP 80 y lo envíe 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 que no sean 80.

Para proporcionar una ayuda mejor y más detallada sobre qué opción podría ser mejor y las limitaciones, etc., necesitamos saber más sobre su configuración. Esperemos que esta explicación ya haya aclarado un poco las cosas.

Respuesta simple, relacionada con el nivel de pregunta

Ignorando los usos exóticos de DNS, y también la búsqueda inversa de DNS (no relevante para la pregunta), casi todo el uso de DNS es de la siguiente forma:

1. El cliente envía el nombre de dominio (totalmente calificado o no) a un servidor DNS
2. 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 se hará cargo y el sistema DNS se saldrá de la imagen.

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 a menudo se hace, 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, le toca a esa máquina escuchar en cualquier puerto que elija y aceptar / negar / 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 suponer que enviar un mensaje al puerto 80 hará que ese mensaje sea leído / respondido por el servicio web de esa máquina. Pero no tiene por qué ser así. Si el servidor está configurado para escuchar 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 lo recibirá en el puerto 9000 y responderá también.

Redireccionar / mapear dentro del servidor web

Preguntó sobre el mapeo de redireccionamiento o reescribir en un comentario. Estas son funciones que puede hacer 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 en el recibo para hacer que las 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, usando alguna URL diferente de reemplazo. (redireccionar).

Estos tienen sus usos y, en principio, podrían manejar su caso de uso, pero no parecen la solución "adecuada" para usted, por estos motivos:

1. No creo que el mapeo pueda ayudar en absoluto . La asignación es casi totalmente interna al servidor web, dice "trata esta URL como si fuera esa 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 conveniencia 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 maneje esto una vez, asignando los dos primeros de estos en la tercera URL internamente, como el primer paso en el manejo de la consulta. Como este objetivo afecta la ruta de la consulta, no la IP / puerto, la asignación no es muy útil para gestión de puertos, y en su caso, el cliente nunca consulta 8080 en absoluto.
2. 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 realmente reciba la consulta (porque estas son funciones internas del servidor web). Por lo tanto, 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 también tiene que escuchar en el puerto 8080. Funcionalmente, se necesitaría una regla de redirección a tener que decirle a cualquier puerto de consulta del cliente 80, para consultar de nuevo con el ": 8080" URL, que no suena como lo que usted quiere hacer. El usuario también vería la nueva URL con ": 8080", mientras que parece que quiere que sea "transparente" y no se muestre.
3. Además, la redirección solo funcionaría para redirigir un puerto estándar (80 o 443) ; por ejemplo, no podría redirigir el puerto 2000 a 8080, porque el cliente no consultaría en 2000 de forma predeterminada, en primer lugar, por lo que nunca lo haría ir al servidor web, incluso si estaba escuchando en 2000. Sin embargo, esto podría no ser un problema para usted.

Sin embargo, si desea una redirección "inteligente", donde solo ciertas consultas se redirigen a 8080, este podría ser el camino a seguir, ya que la redirección puede incluir lógica para decidir qué URL deben redirigirse, mientras que la asignación de puertos (a continuación) mapearí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 que asigne los puertos entre el cliente y el servidor . De esa manera, el cliente envía el puerto 80 (puerto predeterminado utilizado por los navegadores web), pero en realidad 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 especificar sus puertos de escucha.

La forma más habitual de hacerlo 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. Ni el servidor web ni el cliente estarán al tanto del cambio (el enrutador lo controla al 100%), 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.

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 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 posible enfoque sería utilizar un registro de recursos DNS que no sea el tipo A o AAAA típico, como un registro TXT (que técnicamente es solo texto y podría usarse para cualquier cosa) o tal vez un registro SRV o cualquier otro nuevo tipo de registro de recursos que elija.

Si está creando su propio software (tanto cliente como servidor), puede que no haya una razón técnica para no hacer tal cosa, excepto saber que algunas personas usan empresas 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 puedes hacer eso, puedo tener una solución para lo que buscas. 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 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 debe ir el tráfico. El hecho de que podamos usar un número de puerto para ese propósito, haciendo que los firewalls / enrutadores investiguen los números de puerto para realizar NAPT (traducción basada en el puerto de la dirección de red, a veces también llamada PNAT o simplemente NAT), es una técnica más nueva que utiliza un recurso (información), pero no era parte del diseño original. Si nos alejamos de este "abuso" de los números de puerto por un minuto y consideramos el diseño original, podremos encontrar una solución más fácil. Por el diseño de Internet, las máquinas estaban destinadas a ser encontradas usando 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. Por lo tanto, si una máquina recibe tráfico en el puerto TCP 80, la máquina sabrá que el programa que es el servidor web debe utilizar el tráfico de red. Si un navegador web descarga múltiples 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 cree que la administración de DNS sería conveniente para poder manejar un poco más el enrutamiento del tráfico. Pero 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 pueden soportar fácilmente múltiples direcciones IPv6 activas al mismo tiempo. Entonces, 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 puede hacer cualquier travesura de enrutamiento que desee con esas direcciones IPv6.

Luego, puede usar el tipo de registro de recursos AAAA para asignar un nombre a esa dirección IPv6, que su diseño de red puede considerar como efectivamente dedicado 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 tener que 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 piensa 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 (quizás utilizando algún tipo de túnel), y probablemente terminará siendo una solución más gratificante una vez que lo haya implementado.