Minecraft “Unknown host”: DNS, address format, and SRV diagnosis

Unknown host means the client never obtained a usable connect target before a normal game connect, a different class from connection refused.

Last verified

2026-07-21

Evidence cutoff

2026-07-20

Direct answer: “Unknown host” (and close relatives such as “can’t resolve hostname”) means the client never obtained a usable connect target for the string you typed. The failure happens before a normal TCP game connect: the name did not resolve, the address format was unusable, or the resolution path returned nothing the client could treat as a host. That is a different evidence class from “connection refused” (something at a reached host:port actively rejected) or “timed out” (no timely answer after a connect attempt). For a status check, unresolved DNS maps to Unknown with an evidence shape like dns_unresolved—not Offline—because there is no admitted target that refused status.

This page owns the unknown-host / name-resolution cluster. For full SRV and address-resolution detail, see Minecraft SRV records and server-address resolution. For the broad join checklist, start with Can’t connect to a Minecraft server.

What the message is (and is not)

Players and logs paraphrase the same idea in several forms:

Unknown host is not:

• proof that the origin game process stopped;

• proof that Mojang/Microsoft platform services are down;

• the same as connection refused at a reached host:port;

• a popularity, ranking, or “best server” judgment of any kind;

• a reason to force a universal public-DNS change as the first step.

Java Server List Ping and join both need a resolved endpoint. If resolution never finishes cleanly, status and play fail for the same address-string reason—before Offline or Online claims apply.

Separate failure classes (do not collapse them)

Treat these as distinct branches. A single “fix DNS” recipe does not fit all of them.

1. Typo and published-string mismatch

• Extra spaces, missing dots, wrong TLD (.con vs .com), wrong subdomain, or an outdated address from an old post.

• Copying a URL (https://…) or chat decoration into the multiplayer field when only a host (and optional port) belongs there.

• Using a display name or Discord invite instead of the actual join hostname.

Next step: re-enter the address from the community’s current instructions, character for character. Do not interpret status colors until the string matches what operators publish.

2. DNS record missing, wrong, or not yet visible

• No usable A/AAAA (or equivalent) for the final direct host you connect to, or for the SRV target when the player-facing name is SRV-dependent. A hostname can intentionally be SRV-only while the SRV target—not the typed label—holds the address record.

• A record points at an obsolete IP after a host move.

• Authoritative zone is correct, but some resolvers still serve old answers until TTL/cache expires.

• On an SRV-dependent player-facing name, a missing or unusable SRV answer is a separate failure from “typed name has no A/AAAA.”

Wiki server-setup guidance treats DNS updates as non-instantaneous because recursive resolvers cache. Waiting for TTL/propagation is a legitimate diagnostic step—not a claim that every path is already fixed.

3. SRV-specific failures

For Java hostnames without an explicit port, clients and many checkers may look up _minecraft._tcp.<hostname>. SRV redirects the connect target (host and port). Failures include:

• SRV present but target host has no working A/AAAA;

• Missing SRV on a name that was published only for SRV-based joins (no direct A/AAAA on the typed label by design);

• SRV priority/weight/port/target mis-typed so the redirect is empty or wrong;

• Players typing a bare domain that only works with a different subdomain that actually holds the SRV;

• Expecting SRV when the join string already includes :port—explicit ports bypass SRV in the living MinecraftStatus checker (allowSrv only when the port is not explicit), which matches common client practice for hostname-only joins.

Checker vs protocol notes (do not collapse them):

• MinecraftStatus checker today: explicit port → no SRV lookup; after a successful SRV connect-target redirect, the original typed hostname remains in the status handshake (the tool does not rewrite handshake host to the SRV target name).

• RFC 2782 weight among equal-priority records: probabilistic weighted selection is the standards model. MinecraftStatus ranks equal-priority candidates by descending weight rather than full weighted probability, so its selected target does not simulate every client choice.

• Vanilla client handshake rewrite: community docs may describe SRV as also changing the handshake server-address string; confirm against client fixtures before stating that as universal law. Prefer “connect target redirected; handshake host may differ by client/tool.”

SRV problems are not the same as “change your DNS provider.” See the dedicated SRV and address resolution guide when the hostname is correct but the port path is mysterious.

4. Cached resolver / local resolver path

• Stale answers after a legitimate DNS change.

• A broken or restricted recursive resolver on the network (school, workplace, captive portal, mis-set router).

• Local hosts-file overrides that map a name nowhere useful.

Official network help notes that if you previously set DNS manually, returning to automatic settings can be appropriate, and that a local DNS cache flush is one optional PC step—scoped guidance, not a universal fix for every unknown-host case.

5. IPv4 vs IPv6 family mismatch

• Name returns only AAAA (IPv6) while the client path cannot use IPv6, or only A (IPv4) while something on the path expects the other family.

• Dual-stack hosts where one family is broken and the client prefers the broken answer first.

Family mismatch can look like “unknown” or later transport failure depending on stack and edition. Treat it as path-scoped, not as proof the server world process exited.

6. Address-format problems (not really “DNS”)

Default Java listen port is 25565 unless configured otherwise. An explicit wrong port is usually a later transport class (refuse/timeout), but a malformed host:port can still surface as an immediate host/address error.

Diagnostic flow (numbered)

1. Capture the exact string and context

• Copy the multiplayer address field exactly as entered (no “cleaned up” paraphrase).

• Note edition (Java vs Bedrock), launcher, and whether friends using the same string succeed.

• If only one community server fails, do not start from a global Minecraft-outage theory.

2. Rule out format and typo before network folklore

• Strip schemes (https://), spaces, and chat markup.

• Confirm dots, subdomain, and TLD against the published address.

• For Java, decide whether the published string is hostname-only (SRV possible) or host:port (explicit port).

• Do not change system DNS yet—fix the string first.

3. Compare resolution classes without overclaiming

If you control DNS or can ask the operator:

• Confirm usable A/AAAA on the final direct host or SRV target (not necessarily on every intermediate player-facing label when SRV-only publication is intentional).

• Confirm _minecraft._tcp.<name> only when the join string is hostname-without-port and operators intended SRV; if the name is SRV-dependent, a missing SRV is enough to fail resolution even when some other A/AAAA exists elsewhere in the zone.

• After record edits, wait for TTL/propagation before declaring success or failure.

If you are only a player:

• Re-check the community’s current address post (old screenshots go stale).

• Try one controlled alternate path you already trust (for example mobile data vs home Wi‑Fi) without running unsafe scanners.

• If friends resolve and join while you cannot, prefer your resolver path or local cache over inventing a global DNS outage.

4. Run an independent status observation

• Use the Minecraft server status checker with the same address string.

• Read Online / Offline / Unknown and any evidence code—not only a color chip.

• Unknown + DNS/unresolved evidence: stay in this article’s branches (string, DNS, SRV, cache, family).

• Offline + connection_refused: resolution already worked; leave the unknown-host branch and investigate the active refusal as a different error class.

• Online: status answered; a join-only failure is a different layer (auth, whitelist, version, packs).

5. Use DNS hygiene only as a scoped step

When format and published records look right, and evidence still points at local resolution:

• Prefer automatic DNS if you previously forced manual resolvers you no longer understand.

• A local cache flush (when your OS documents one) is a low-scope experiment after a known record change.

• Changing to a random public recursive resolver is not a universal fix. It can help a broken recursive path, hide the real zone error, or break split-horizon setups. Treat it as one controlled experiment—not default advice for every unknown-host report.

• Do not download untrusted “DNS fix” binaries or cracked clients.

6. Stop when the claim would exceed the evidence

• One client’s unresolved name is one vantage’s resolve failure.

• Do not upgrade unknown host into “Minecraft is down,” “best servers are broken,” or any relationship/ranking language about listed hosts.

• Do not map dns_unresolved to Offline. Offline requires an admitted target that actively refused status.

• When evidence is incomplete, Unknown is the honest public claim.

Evidence limits

• This article does not assert any current outage, player count, rank, or firsthand live test result.

• Client wording varies by edition, version, locale, and launcher; treat quoted phrases as classes of symptom, not a complete catalog of every build.

• Official Help pages and wiki tutorials can change; recheck them when the live wording or behavior differs.

• The MinecraftStatus checker observes from one network vantage unless a page explicitly shows otherwise; it never proves every ISP path.

• DNS success for one recursive resolver does not prove every client path; DNS failure does not prove the game process exited.

• SRV is Java-relevant for hostname-without-port joins; usable A/AAAA must exist for the final direct host or SRV target, not necessarily for every player-facing label under intentional SRV-only publication.

• Immediate failure timing is consistent with local parsing or cached negative answers; it is not proof of a specific DNS cause.

• With an explicit port, the checker skips SRV lookup and keeps the original hostname in the Java handshake. Its equal-priority SRV choice is deterministic, not RFC 2782 randomized weighted selection.

• No guaranteed fix is offered. Change one controlled variable at a time.

• Public recursive DNS providers are examples in general DNS literature, not endorsements or mandatory steps.

Related resources

Last verified

• Evidence cutoff: 2026-07-20

• Sources re-checked: Minecraft Wiki Java server setup (A/SRV publishing, SRV-target address records, cache/propagation notes, default port); Minecraft Wiki Server List Ping (default port, SRV connect-target redirect; handshake host not asserted as universal rewrite); Minecraft Help network connection troubleshooting umbrella (automatic DNS preference after manual changes; optional local cache flush scope); MinecraftStatus checker surface (allowSrv: !explicitPort, original hostname in handshake) and transport taxonomy for dns_unresolved as Unknown, not Offline.