Implementing Multi-Subdomain Pointing to Different Ports on a Single-IP Server

Fundamentals of DNS and Ports

DNS (Domain Name System) primarily translates human-readable domain names (e.g., example.com) into machine-readable IP addresses (e.g., 192.168.1.1). This is achieved through DNS records, with A records being the most common, mapping domains directly to IPs. However, DNS does not inherently manage port information. Ports are part of the transport layer (e.g., TCP or UDP), used to distinguish between different network services on the same IP address. For instance, web servers typically use port 80, while Minecraft servers default to port 25565.

In the user scenario, when attempting to access services on different ports via subdomains—such as one.something.example pointing to port 25565 and two.something.example to port 25566—DNS cannot fulfill this directly. Since DNS resolution only returns an IP address, clients (e.g., Minecraft) must specify the port separately to connect to the correct service. This explains why the user initially could only access the second server using formats like something.example:25566.

Solution 1: Using SRV Records

SRV (Service) records are a DNS extension that associates service names, protocols, and ports with domain names. Designed for applications like VoIP or gaming, they can specify ports for subdomains in Minecraft setups.

Configuring SRV records typically involves: first, creating A records in DNS management (e.g., No-IP console) to point subdomains (e.g., mc1.something.example and mc2.something.example) to the server's IP. Then, adding SRV records, for example:

Name: _minecraft._tcp.mc1.something.example
Priority: 5
Weight: 5
Port: 25565
Value: mc1.something.example

Name: _minecraft._tcp.mc2.something.example
Priority: 5
Weight: 5
Port: 25566
Value: mc2.something.example

Thus, when a Minecraft client resolves mc1.something.example, DNS returns the SRV record indicating port 25565. However, SRV records are limited by client support; while Minecraft clients natively support them, general-purpose clients like web browsers do not, making this solution application-specific.

Solution 2: Configuring a Reverse Proxy Server

Reverse proxy servers (e.g., Nginx or Apache) offer a more universal solution for single-IP environments. They listen on standard ports (e.g., 80 or 443) and forward traffic to internal ports based on the requested domain, handling port mapping without relying on DNS records.

Using Nginx as an example, configuration includes: installing Nginx, editing the configuration file (e.g., /etc/nginx/nginx.conf), and adding server blocks to define subdomain and port mappings. For instance:

server {
    listen 80;
    server_name one.something.example;
    location / {
        proxy_pass http://localhost:25565;
    }
}

server {
    listen 80;
    server_name two.something.example;
    location / {
        proxy_pass http://localhost:25566;
    }
}

In this setup, Nginx listens on port 80, proxying traffic for one.something.example to local port 25565, and for two.something.example to port 25566. This requires A records in DNS pointing all subdomains to the server's IP. Reverse proxies are advantageous due to their compatibility, support for multiple protocols and services, and ability to add features like load balancing and SSL encryption.

Solution 3: Assigning Multiple IP Addresses

If the server supports multiple IP addresses (e.g., via virtual interfaces or IPv6), each subdomain can be assigned a distinct IP, avoiding port conflicts. For example, point one.something.example to IP 192.168.1.101 and two.something.example to 192.168.1.102, with both servers running on the default port 25565.

Implementing this requires: configuring multiple IPs on the server (e.g., using ip addr add in CentOS), setting corresponding A records in DNS, and ensuring firewall and routing rules permit traffic. This method is straightforward but limited by IP address availability and may be impractical in IPv4-scarce environments.

Comparison and Applicable Scenarios

The SRV record approach suits specific applications like Minecraft, dependent on client support; it requires no extra software but lacks generality. The reverse proxy method is the most flexible, applicable to web services, game servers, and more, supporting single-IP setups, though it necessitates proxy software installation and configuration. The multi-IP solution is simple and efficient but relies on IP availability and may incur higher costs.

For the user scenario, reverse proxy is recommended as it is compatible with Minecraft clients and easily extensible. In deployment, ensure DNS records correctly point to the server IP, Nginx configuration is accurate, and services are restarted for changes to take effect. Additionally, consider security measures like firewall rules to restrict port access and SSL configuration for proxy traffic encryption.

In summary, by understanding the separation of DNS and ports, and leveraging technologies like reverse proxies, efficient subdomain-to-port mapping on single-IP servers can be achieved, enhancing user experience and service management.