How to point a domain at your VPS (A and AAAA records)
Point your domain at your server with A and AAAA records, add www, pick a sensible TTL, and check with dig that the change has really taken effect.
Tested on Debian 13 Stable
Before you start
- A registered domain
- Access to the DNS settings at your registrar or DNS provider
- Your server's IPv4 address (and IPv6 address if it has one)
To point a domain at your VPS, log in to whoever hosts your domain's DNS and create an A record for the domain with your server's IPv4 address as the value, plus an AAAA record with its IPv6 address. Add the same for www (or a CNAME from www to the domain), wait for the old TTL to run out, and check with dig example.com +short.
Nothing changes on the server itself for this; DNS is set where your domain's nameservers are. This tutorial uses example.com, the IPv4 address 203.0.113.10 and the IPv6 address 2001:db8::10. Use your own. We ran the dig commands on Debian 13; they work the same on macOS and other Linux systems.
Find where your DNS is hosted
Your domain's DNS is managed by whoever runs its nameservers, which isn't always the registrar you bought it from. Ask:
dig +short NS example.comNames like ns1.your-registrar.com mean the registrar; *.ns.cloudflare.com means Cloudflare, and so on. That's where you make the changes below.
On Windows without dig, use nslookup -type=ns example.com. On a Linux server, dig comes in dnsutils (Debian, Ubuntu) or bind-utils (AlmaLinux, Rocky).
Create the records
In your DNS provider's control panel, add:
| Type | Name | Value | TTL |
|---|---|---|---|
A |
@ (the domain itself) |
203.0.113.10 |
3600 |
AAAA |
@ |
2001:db8::10 |
3600 |
A |
www |
203.0.113.10 |
3600 |
AAAA |
www |
2001:db8::10 |
3600 |
Notes:
@stands for the domain itself (example.com). Some panels want the field left empty instead, or the full name.- Remove old records for the same names, such as the registrar's "parking" A record. Two A records for one name means visitors are sent to either at random.
- AAAA: add it only if the server really answers on IPv6. If it has an address but your web server or firewall isn't ready for IPv6, IPv6 visitors get errors. IPv6 setup covers checking it.
wwwas a CNAME: instead of its own A and AAAA,wwwcan be aCNAMEtoexample.com. That way you change the address in one place. The domain itself (@) can't be a CNAME.- If you use Cloudflare, the orange cloud ("proxied") makes visitors connect to Cloudflare rather than your server. Start with it off ("DNS only") until the site works.
Choose a TTL
The TTL (time to live) is how many seconds resolvers around the world may cache the answer. It decides how long a change takes to reach everyone:
| TTL | Use it when |
|---|---|
| 300 (5 minutes) | You're about to move the site, or still testing |
| 3600 (1 hour) | Normal operation |
| 86400 (1 day) | Records that never change |
"DNS propagation" is just old answers expiring from caches. If a record had a TTL of 86400 before you changed it, some visitors keep getting the old address for up to a day. Planning a move? Lower the TTL to 300 a day ahead, make the change, then raise it again.
Check it worked
Ask your normal resolver:
dig +short example.com A
dig +short example.com AAAA
dig +short www.example.comEach prints the address you set. For the full answer, including the remaining TTL:
dig example.com A +noall +answerexample.com. 3600 IN A 203.0.113.10If your own resolver still has the old answer cached, ask the authoritative nameserver directly; it always has the current record:
dig @$(dig +short NS example.com | head -1) example.com A +noall +answerAnd check a public resolver or two, which is closer to what visitors see:
dig @one.one.one.one +short example.com
dig @dns.google +short example.comFinally, check the server answers on that name:
curl -I http://example.comAny HTTP response (even 403 or the default page) means DNS and the network path are right. Next stop: HTTPS.
Troubleshooting
dig returns nothing, and status: NXDOMAIN in the full output. The name doesn't exist in DNS. Check the spelling of the record's name, and that you edited the zone at the provider the NS records point to.
The authoritative server has the new address, public resolvers have the old one. They're caching the old record until its TTL runs out. Wait, or test with the authoritative server in the meantime.
curl times out although dig is right. DNS is fine; the server isn't answering on port 80. Check that the web server runs and the firewalls allow it: check open ports.
Let's Encrypt fails with an IPv6 error. Certbot's validation prefers IPv6 when an AAAA record exists. Make the site work on IPv6 too, or remove the AAAA record until it does.
Next steps
- Serve the site with HTTPS: nginx and HTTPS.
- Sending email from this domain? Set reverse DNS and read send email through an SMTP relay.
Doing it on VPSNine
Every VPSNine server gets one IPv4 and one IPv6 address, shown on the server's page in the panel; those are the values for your A and AAAA records. The reverse direction (address to name) is set in the panel as reverse DNS. Works with any distribution, such as Debian 13, on all plans.