DNS issues

DNS is the most common source of “I set everything up but it doesn’t work.” This page is the diagnostic recipe book.

See DNS setup for the configuration reference.

”Domain not verified” in the panel

Verification keys off the CNAME — pointing it at the IF edge is what proves ownership. If the domain stays unverified:

1. 1

   Confirm the CNAME resolves

   bash

   $ dig +short CNAME play.example.comClick to copy

   {uuid}.front-de.infinity-filter.com.

   If empty or pointing at the wrong target, fix the CNAME in your DNS editor.

2. 2

   Check Cloudflare proxy

   On Cloudflare, the CNAME must be DNS only (grey cloud). An orange cloud hides the real target behind Cloudflare’s proxy, so the panel can’t read it. Switch the row to grey.

3. 3

   Add the TXT fallback

   If the CNAME is correct but still won’t verify, add the recommended TXT fallback on the root domain (Name = @). Its value must exactly match what the panel shows — a copy-paste with an extra space or wrong character is the #1 cause of failure:

   bash

   $ dig +short TXT example.comClick to copy

   "infinity-filter-verification=..."

4. 4

   Wait for propagation

   DNS propagation across resolvers can take a minute or two. Re-check with dig @1.1.1.1 and dig @8.8.8.8 to verify resolvers other than your local one see it.

Trying to add a Bedrock subdomain fails verification

Bedrock subdomains don’t go in the Domains table. Only Java domains do — the verification probe is Java-only. Bedrock just needs the CNAME at your DNS provider. See Geyser integration.

Hardcoded IP instead of CNAME

If your DNS record is an A or AAAA pointing at the resolved IP of the IF edge:

• It worked when you set it up because the IP was current.
• It will silently break the next time we rotate the IP.

Fix: replace with a CNAME pointing at the IF hostname (<uuid>.front-<region>.infinity-filter.com or <uid>.ip.infinity-filter.com).

Cloudflare orange cloud is on

The Minecraft protocol is not HTTP. Cloudflare’s proxy (orange cloud) only knows how to proxy HTTP/S, so the connection fails.

Fix: every Minecraft-related record on Cloudflare must be DNS only (grey cloud).

If you also want to expose a related web service (Dynmap, BlueMap), put it on a separate subdomain with its own proxied CNAME pointing at a different origin — don’t mix them.

CNAME points at the wrong region

Players in your target region see high latency? Run the Latency Test — your backend may be closer to a different PoP. Update the CNAME region on the Domains page.

This is non-disruptive: existing players stay, new players use the new region as DNS propagates.

Same CNAME used for Java and Bedrock

Don’t share a CNAME for both:

• A Java CNAME pointing at front-* won’t accept Bedrock UDP traffic.
• A dedicated-IP CNAME <uid>.ip.infinity-filter.com shared with Java means Bedrock clients can end up resolving via shared edge pools to another customer’s dedicated IP, which is broken at best and a privacy issue at worst.

Always use separate CNAMEs for Java (play.example.com) and Bedrock (bedrock.example.com).

SRV record exists but routes through a non-IF host

If _minecraft._tcp.<domain> SRV exists, its target must ultimately resolve to a front-* host. If the target is anything else (a legacy provider’s hostname, a hardcoded IP), the SRV breaks the routing.

Fix: either remove the SRV record (and let players connect via the CNAME), or update the SRV target to a hostname that resolves to a front-* host.

See SRV records.

DNS API-driven updates aren’t reflected

Dynamic backend IPs refreshed via a DNS API work — Infinity-Filter respects the TTL. If updates aren’t picked up:

• TTL is too long. Lower it to 60–300 seconds for dynamic records.
• The TTL on the record is honored, but the TTL on caching resolvers is independent — you can’t shorten that retroactively.

Common one-line diagnoses

What’s next