How to Connect a Domain to a Minecraft Java Server

Map the endpoint before editing DNS

A custom domain changes how players find a server; it does not create the network path to it. Write down the exact public hostname players should enter, the server's public IPv4 or IPv6 address, the external Java TCP port and the DNS provider that is authoritative for the domain. Confirm that the server already accepts an outside connection by IP and port. If that direct test fails, DNS will only give the same unreachable endpoint a friendlier name.

Separate the player-facing name from the origin name. A practical plan might use play.example.com for players and mc-origin.example.com as the hostname that carries the server address. Keeping an origin hostname makes the SRV target explicit and lets the website at example.com remain independent. Record whether the host assigns a fixed address or a hostname, and whether the game port is the default 25565 or a different allocation.

Check every listener before publication. Paper's current server-properties reference lists server-port=25565 as the default. A managed host may assign another public port or translate it to a different container port, so use the public endpoint players can actually reach. For a home server, finish the TCP firewall and router path in /blog/port-forward-minecraft-java-server first. Never publish a private 10.x, 172.16–31.x or 192.168.x address for internet players.

• Player address: the root domain or subdomain people will type.
• Origin: a stable public IP address or provider-approved hostname.
• Service: the externally reachable Java TCP port.
• Rollback: the current working IP, port and DNS values.

Choose an address record or an SRV record

Use an A record to map a hostname to a public IPv4 address and an AAAA record to map it to a public IPv6 address. If players will join play.example.com on Java's default port 25565, an address record for play is normally the simplest setup. The hostname resolves to the server, and the client uses its normal port without needing a service record.

Use an SRV record when players should omit a non-default port, when the root domain should direct Minecraft somewhere different from the website, or when the memorable player name and the server target must be separate. Current Porkbun guidance documents the Minecraft service name as _minecraft._tcp and shows _minecraft._tcp.play for a play.example.com endpoint. The SRV record supplies the target hostname and port that the Java client should use.

An SRV record supplements address resolution; it does not replace it. RFC 2782 requires the SRV target to be a domain name with address records and says the target must not be an alias. Build a real target such as mc-origin.example.com with A and, only when IPv6 genuinely works end to end, AAAA. Do not put a raw IP address in the SRV target field. Avoid a chain of convenience aliases that makes the destination harder to audit.

• Default port and one hostname: start with A or AAAA.
• Non-default port without :port in the player address: add SRV.
• Website and Minecraft on the same domain: use SRV to direct the game service separately.
• One service endpoint: keep priority and weight simple rather than inventing failover.

Create the server address record

Open the authoritative DNS zone, not merely the registrar account if another provider hosts DNS. Add an A record for a name such as mc-origin with the server's public IPv4 address. Add an AAAA record only when the server, firewall, provider and client path all support the advertised IPv6 address. Publishing an untested AAAA response can send compatible clients toward a route that never reaches the game listener.

Set a deliberate time to live. Cloudflare describes TTL as the period a DNS record remains valid in caches and therefore one factor in how quickly changes reach users. Lower it before a planned migration when the provider permits, wait for the prior TTL to age out, then change the endpoint. Raising it again after acceptance reduces repeated lookups. Do not promise instant propagation: recursive and device caches can retain an earlier answer until it expires.

When Cloudflare hosts the zone, use DNS-only for the ordinary Minecraft origin record. Cloudflare's current proxy-status documentation says its standard proxy routes HTTP and HTTPS traffic, while non-HTTP services are common DNS-only cases. An orange-clouded A or CNAME answer returns Cloudflare anycast addresses instead of the game server. A separately configured Layer 4 product is a different architecture; do not assume the website proxy protects a Java TCP listener.

Build the Minecraft SRV record correctly

Create a service record for the exact player name. For example.com, the owner is _minecraft._tcp. For play.example.com, the owner is _minecraft._tcp.play. DNS dashboards vary: some ask separately for service, protocol and name, while others expect the combined owner. Inspect the preview before saving so the provider does not append the zone twice and create a record under _minecraft._tcp.play.example.com.example.com.

For one server, use priority 0, weight 0, the actual public port and the address-bearing target hostname. A complete answer for a server on port 25580 might read 0 0 25580 mc-origin.example.com. RFC 2782 defines lower priority numbers as preferred and weight as relative selection among records with the same priority. Weight is not another priority field. With only one target, zero values keep the record clear and avoid pretending that DNS is a health check.

Enter the target as a hostname, never an IP address or a URL. Some dashboards want a final dot on a fully qualified name and others add it automatically; follow the provider's field help and inspect the published response. The port in SRV must be the external Java TCP port, not an internal container port unless they are genuinely the same. Keep Geyser, voice chat, Query and other UDP services out of this Java _tcp record.

• Name for play.example.com: _minecraft._tcp.play
• Priority: 0 for the single intended target.
• Weight: 0 when there is no same-priority selection.
• Port: the public Java TCP port players can reach.
• Target: an address-bearing hostname such as mc-origin.example.com.

Verify DNS before asking players to retry

Query the records directly before opening Minecraft. Run dig +short A mc-origin.example.com for IPv4, dig +short AAAA mc-origin.example.com for IPv6 when used, and dig +short SRV _minecraft._tcp.play.example.com for the service. The SRV response should expose four values in priority, weight, port and target order. On Windows, nslookup -type=SRV _minecraft._tcp.play.example.com provides the same kind of check.

Query both the authoritative nameserver and at least one independent recursive resolver when a change appears inconsistent. If the authoritative answer is correct but a recursive resolver still returns the old value, wait for the earlier TTL rather than repeatedly editing a good record. If the authoritative answer is wrong or empty, correct the DNS owner, target or zone first. Save the command output and time so support can distinguish publication from cache state.

Then test the exact player journey from outside the server network. Enter play.example.com without :port so the no-port path actually exercises SRV. Join with a normal authenticated Java account, watch the Paper or proxy console for the attempt, move in the world and reconnect. Also test the direct IP and port once as a control. A working direct join with a failing hostname isolates the problem to DNS or client resolution rather than the Minecraft listener.

• Confirm A or AAAA returns the intended origin address.
• Confirm SRV returns the intended priority, weight, port and target.
• Test the advertised hostname without an explicit port from another network.
• Match the attempt time with the server or proxy log.

Fix the common domain connection failures

If the hostname does not resolve, verify that the domain uses the nameservers where you created the records and that the record owner is in the correct zone. If A resolves but SRV is empty, look for an incorrectly expanded name, the wrong _tcp protocol or a provider form that wanted service and protocol in separate fields. Delete only the malformed record after capturing it; do not add several speculative duplicates with different values.

If both answers resolve but Minecraft times out, query the SRV target and compare its port with the known direct endpoint. A private target address, stale host allocation, closed firewall, missing container publish or Paper bind failure remains a networking problem. If Cloudflare answers with its proxy addresses, return the game origin to DNS-only unless a supported TCP proxy has been deliberately configured. DNS cannot open ports or make a stopped process listen.

If some players connect and others do not, compare resolver answers and client editions before changing the zone. Java and Bedrock are different connection paths. Geyser's current connectivity guidance tells Bedrock users to enter the Java server address and the configured Bedrock port; test and publish that endpoint separately instead of assuming the Java SRV record covers it. VPN, school and mobile resolvers may also retain answers differently, so collect the exact address, edition, error and attempt time.

• No DNS answer: nameserver, zone or record-owner problem.
• SRV target has no address: missing A or AAAA record.
• Timeout with correct DNS: listener, firewall, NAT or allocation problem.
• Only one edition fails: verify the Java and Bedrock endpoints separately.

Cut over and keep rollback simple

For a server move, lower TTL ahead of the maintenance window, freeze player writes and validate the new host by its direct endpoint first. Update only the address record or SRV target needed for the cutover, then repeat the DNS queries and outside join. Do not keep two writable copies of the same world online while caches converge. The controlled transfer process in /blog/move-minecraft-server-to-new-host covers the consistent backup and destination acceptance steps that DNS cannot provide.

Keep the previous record values, TTL, host allocation and working direct address through a defined rollback window. Roll back when the new target is unreachable, identity changes unexpectedly behind a proxy, or the server cannot pass its normal health checks. Restore the complete prior DNS record set together; changing the A record back while leaving SRV aimed at a different hostname produces another ambiguous path.

After acceptance, raise TTL to the normal operational value, remove obsolete records and document who controls the registrar, authoritative DNS and server endpoint. Re-test after address, port, proxy or nameserver changes. More practical server guides are collected at /blog. If the current host cannot provide a stable public endpoint or a port that matches the published plan, compare the documented options at /pricing before building more DNS indirection around it.