Cómo redirigir DNS a diferentes puertos

(Ha pasado un tiempo desde que hice estas cosas. Por favor, no asuma ciegamente que todos los los detalles a continuación son correctos. Pero espero no estar demasiado equivocado. :))

Como se indicó en la respuesta anterior, el cliente de Minecraft (a partir de 1.3.1) admite la búsqueda de SRV record utilizando el nombre del servicio _minecraft y el nombre del protocolo _tcp, lo que significa que si su archivo de zona se ve así...

arboristal.com.                 86400 IN A   <your IP address>
_minecraft._tcp.arboristal.com. 86400 IN SRV 10 20 25565 arboristal.com.
_minecraft._tcp.arboristal.com. 86400 IN SRV 10 40 25566 arboristal.com.
_minecraft._tcp.arboristal.com. 86400 IN SRV 10 40 25567 arboristal.com.

...a continuación, los clientes de Minecraft que realizan La búsqueda de registros SRV como se indica en el registro de cambios utilizará los puertos 25566 y 25567 con preferencia (40% de las veces cada uno) sobre el puerto 25565 (20% de las veces). Podemos suponer que los clientes de Minecraft que encuentren y respeten estos registros SRV y no usarán el puerto 25565 como de costumbre.

Sin embargo, yo diría que en realidad sería más "limpio y profesional" hacerlo usando un equilibrador de carga como Nginx. (Escojo Nginx solo porque lo he usado antes. No estoy reclamando es especialmente adecuado para esta tarea. Incluso podría ser una mala elección por alguna razón.) Entonces no tienes que meterte con tu DNS, y puedes usar el mismo enfoque para equilibrar la carga cualquier servicio, no solo los como Minecraft que han hecho el duro trabajo del lado del cliente para buscar y respetar los registros SRV. Para hacerlo de la manera Nginx, ejecutarías Nginx en la máquina arboristal.com con algo como lo siguiente en /etc/nginx/sites-enabled/arboristal.com:

upstream minecraft_servers {
    ip_hash;
    server 127.0.0.1:25566 weight=1;
    server 127.0.0.1:25567 weight=1;
    server 127.0.0.1:25568 weight=1;
}
server {
    listen 25565;
    proxy_pass minecraft_servers;
}

Aquí estamos controlando el equilibrio de carga nosotros mismos en el lado del servidor (a través de Nginx), por lo que ya no tenemos que preocuparnos de que los clientes mal comportados prefieran el puerto 25565 a los otros dos puertos. De hecho, ahora todos los clientes hablarán con arboristal.com:25565! Pero el oyente en ese puerto ya no es un servidor de Minecraft; es Nginx, proxy secretamente todo el tráfico en otros tres puertos en la misma máquina.

Equilibramos la carga en función de un hash de la dirección IP del cliente (ip_hash), de modo que si un cliente se desconecta y luego se vuelve a conectar más tarde, hay una buena probabilidad de que se vuelva a conectar al mismo servidor de Minecraft que tenía antes. (No se cuánto le importa esto a Minecraft, o cómo los clientes habilitados para SRV están programados para lidiar con este aspecto.)

Observe que solíamos ejecutar un servidor de Minecraft en el puerto 25565; lo he movido al puerto 25568 para que podamos usar el puerto 25565 para el balanceador de carga.

Una posible desventaja del método Nginx es que convierte a Nginx en un cuello de botella en su sistema. Si Nginx baja, entonces los tres servidores se vuelven inalcanzables. Si alguna parte de su sistema no puede mantenerse al día con el volumen de tráfico en ese único puerto, 25565, los tres servidores se vuelven anticuados. Y sin mencionar que Nginx es una gran dependencia nueva en su ecosistema. Tal vez no desee introducir otra pieza masiva de software con un lenguaje de configuración complicado y una enorme superficie de ataque. Puedo respetar eso.

Una posible ventaja del método Nginx es... que hace que Nginx a cuello de botella en su sistema! Puede aplicar políticas globales a través de Nginx, como rechazar paquetes por encima de cierto tamaño o responder con una página web estática a conexiones HTTP en el puerto 80. También puede cortafuegos de los puertos 25566, 25567 y 25568 desde Internet, ya que ahora deben ser hablados con solo por Nginx a través de la interfaz de bucle invertido. Esto reduce un poco la superficie de ataque.

Nginx también hace que sea más fácil agregar nuevos servidores de Minecraft a su backend; ahora puede simplemente añade una línea server a tu configuración y service nginx reload. Usando el antiguo enfoque basado en puertos, tendría que agregar un nuevo registro SRV con su proveedor DNS (y podría tomar hasta 86400 segundos para que los clientes noten el cambio) y luego también recuerde editar su firewall (por ejemplo, /etc/iptables.rules) para permitir el tráfico externo sobre ese nuevo puerto.

Nginx también te libera de tener que pensar en DNS TTLs al hacer cambios en ops. Supongamos que decide dividir sus tres servidores de Minecraft en tres diferentes máquinas físicas con diferentes direcciones IP. Usando Nginx, puede hacerlo completamente a través de cambios de configuración en sus líneas server, y puede mantener esas nuevas máquinas dentro de su firewall (conectadas solo a Nginx a través de una interfaz privada), y los cambios tendrán efecto inmediatamente, por definición. Mientras que, usando registros SRV, tendrá que reescribir su archivo de zona a algo como esto...

arboristal.com.                 86400 IN CNAME mc1.arboristal.com.
mc1.arboristal.com.             86400 IN A   <a new machine's IP address>
mc2.arboristal.com.             86400 IN A   <a new machine's IP address>
mc3.arboristal.com.             86400 IN A   <a new machine's IP address>
_minecraft._tcp.arboristal.com. 86400 IN SRV 10 20 25565 mc1.arboristal.com.
_minecraft._tcp.arboristal.com. 86400 IN SRV 10 40 25565 mc2.arboristal.com.
_minecraft._tcp.arboristal.com. 86400 IN SRV 10 40 25565 mc3.arboristal.com.

...y tendrás que dejar las tres máquinas nuevas metiendo fuera su firewall para que puedan recibir conexiones de Internet. Y tendrá que esperar hasta 86400 segundos para que sus clientes noten el cambio, lo que podría afectar la complejidad de su plan de implementación. Y si estaba ejecutando cualquier otro servicio (como un servidor HTTP) en arboristal.com, ahora tiene que moverlos a la máquina mc1.arboristal.com debido a cómo hice ese CNAME. Lo hice solo para el beneficio de esos hipotéticos clientes de Minecraft que no respetan los registros de SRV y seguirá intentando conectarse a arboristal.com:25565.

Por lo tanto, creo que ambas maneras (registros SRV y equilibrio de carga Nginx) son razonables, y su elección dependerá de sus preferencias personales. Caricaturizo las opciones como:

• SRV records: "Solo necesito que funcione. No quiero complejidad. Y conozco y confío en mi proveedor de DNS."
• Nginx: "Preveo arboristal.com apoderarme del mundo, o al menos mudarme a una máquina más grande algún día. No tengo miedo de aprender una nueva herramienta. ¿Qué es un archivo zone?"