DNS records for VPS hosting, explained practically

DNS is a distributed database with caching. Most VPS “DNS problems” are one of three things: the wrong record type, an old cached answer, or an application that is not listening on the resolved address.

Web and API records

Point a hostname directly at the VPS with address records:

app.example.com.  300  IN  A     203.0.113.20
app.example.com.  300  IN  AAAA  2001:db8:100::20

Use both when the service works over IPv4 and IPv6. Publishing a broken AAAA record creates intermittent-looking failures for IPv6-capable users.

A CNAME aliases one hostname to another:

www.example.com.  300  IN  CNAME  app.example.com.

Do not put a CNAME alongside other records at the same name. Root-domain CNAME behaviour varies by DNS provider; use A/AAAA records or the provider's flattening feature.

Mail-related records

MX records name mail servers, not IP addresses:

example.com.       3600 IN MX 10 mail.example.com.
mail.example.com.  3600 IN A     203.0.113.25

TXT records commonly hold SPF, DKIM, domain verification, and security policy data. Copy values exactly, but understand which service owns each one before deleting it.

Reverse DNS maps an IP address back to a hostname. It is configured by the IP provider, not in the normal forward zone. Mail systems often expect forward and reverse DNS to agree.

Restrict certificate authorities with CAA

example.com.  3600 IN CAA 0 issue "letsencrypt.org"

CAA limits which certificate authorities may issue certificates for the domain. Add entries for every CA you intentionally use before enabling it.

Verify the authoritative answer

Find the nameservers:

dig NS example.com +short

Ask one of them directly:

dig @ns1.provider.example app.example.com A +noall +answer
dig @ns1.provider.example app.example.com AAAA +noall +answer

Then compare public resolvers:

dig @1.1.1.1 app.example.com +short
dig @8.8.8.8 app.example.com +short

If the authoritative server is correct but a recursive resolver is old, wait for the previous TTL. Changing the TTL after the bad record has already been cached does not shorten that cache.

Finally, prove the service itself:

curl -4I https://app.example.com
curl -6I https://app.example.com

DNS gets traffic to an address. Firewalls, listeners, virtual hosts, and certificates take over from there. Debug each layer separately.

Set records in a change-friendly order

For a new HTTPS service, create the A/AAAA records first, wait for them to resolve, then issue the certificate and enable the virtual host. Add redirects only after the canonical hostname works. If you use a CNAME, query both the alias and its target while testing.

Keep a zone export or provider API backup before a large change. Record the intended TTL, owner, and rollback value in the change note. Do not delete an old record until caches have expired and traffic logs show the new target is receiving requests.

Avoid common record mistakes

An MX target must have an address record; an MX pointing at a CNAME is rejected by some mail systems. SPF is one TXT record for a domain, so combine mechanisms instead of publishing several competing SPF strings. DKIM selectors are separate names, and verification TXT records often belong at a subdomain rather than the root.

When debugging, clear only the local resolver cache if you understand its behaviour. Testing from a phone network, a public resolver, and the authoritative server gives a much clearer picture than repeatedly refreshing one browser.