Verify a DNS change without guessing

A domain can point to the right server while the website or game application still has a separate configuration problem. Treat DNS resolution and application connectivity as two different checks.

Record the intended change

Before editing, save the current record name, type, value and TTL. Check which nameservers are authoritative for the domain. Editing records at an old DNS provider will not change answers from the currently authoritative provider.

Verify in layers

1. Confirm the authoritative zone contains the intended record.
2. Check that the record's name is correct: the root domain and a subdomain are different names.
3. Compare the answer from your normal resolver with an independent resolver.
4. Allow for the previously cached TTL; changing a TTL now does not instantly clear old answers.
5. Once the answer is correct, test the application itself using the correct protocol and port.

A CNAME normally points to another hostname, not an IP address or a URL containing https://. An A record holds an IPv4 address. Do not put a game port in an A record's value.

Common misleading results

A browser cache or an existing connection can make a website appear unchanged after DNS is correct. An incorrect AAAA record can send IPv6-capable clients somewhere different from IPv4 clients. A web proxy may be unsuitable for the protocol you are trying to expose.

Is every DNS change instant?

No. TTL controls how long answers can remain cached. Avoid promising a universal propagation time for every resolver and record.

Does DNS open a firewall port?

No. The service must be listening and its network path must allow the required traffic. DNS only resolves the name.

Source: Cloudflare's TTL reference. Related: DNS troubleshooting, Port forwarding.