How to change your DNS zone at OVH

Changing your DNS zone at OVH happens in exactly one place, and it only trips people up because the panel looks busier than the job. You want the DNS Zone tab of your domain. That's it. The actual work is nearly always the same: point a name at a server by setting its A record to the server's IP. Edit the apex, do the same for www, save. The part everyone forgets is the cleanup, and it's the part that bites, because a leftover AAAA or A record aimed at an old host will quietly send visitors, and Let's Encrypt, to the wrong machine. Here's where the zone lives, which record to touch, the leftover trap that cost me an afternoon once, and how to check the change actually worked.

Where the DNS Zone actually lives

OVH has piled on buttons over the years, so here’s the path that still works: Web Cloud, then Domain names, pick your domain, then the DNS Zone tab. What loads is the entire zone, one row per record. Intimidating at a glance. It’s a list, and you edit it a row at a time.

Edit the A record

An A record maps a name to an IPv4 address. That’s the whole idea. Set the apex, the row OVH shows as @, to your server’s IP, and send www to the same place. Here’s what a clean zone looks like, with example values:

For www you can use a second A record or a CNAME back to the apex. Either works. Pick one and move on. Same picture, drawn out:

Clean up the leftovers, this is the trap

Here’s the one that got me. If the domain ever lived somewhere else, the zone usually still carries an old A or AAAA pointing at that previous host. Nothing warns you. Browsers will happily follow it, and so will Let’s Encrypt when it goes to validate a certificate, which then fails for no reason you can see because the check landed on the wrong server entirely.

So before you walk away: scan the rows and delete anything that doesn’t point at your new server. AAAA records are the usual culprit, because people forget the domain ever had IPv6 in the first place. Two minutes now saves you an hour of squinting at a cert error later.

Check it actually took

Don’t trust your own browser here, it caches like a magpie. Ask a public resolver straight out:

If the public resolver shows the new IP but your machine still shows the old one, that’s your local cache talking, not OVH. Clear it: see flush the DNS cache on Windows or on Linux.

”Propagation” is really just the TTL

There’s no magic delay and nothing you can pay to speed up. Every resolver holding the old answer keeps serving it until that record’s TTL expires, then asks again. So your real wait is whatever TTL sat on the record before you touched it. Knew the change was coming? Then you’d have lowered the TTL first. The full story, and why that’s the one trick that makes DNS changes painless, is in our DNS TTL guide.

Frequently asked questions