Pointing a Domain at Your Server

What is it? #

Connecting a domain to your server means creating DNS records that map the name to the server's IP address.

For most setups this is two records: an A record for the apex domain and either a CNAME or a second A record for www.

The part that causes confusion is timing. A change is not pushed anywhere; old answers expire from caches at their own pace, governed by the TTL that was in effect before the change.

Lowering the TTL a day in advance is what makes a planned migration quick.

Think of it like this #

Updating the address in a directory that many people have already copied into their own notebooks.

The directory is correct immediately. The notebooks update when their owners next check, which is why lowering how long people keep their copy — before you move — makes the change appear faster.

Simple example #

You have a server at 203.0.113.10 and a domain. You create the records, verify them with dig, wait for the cache to expire, and confirm the site loads before requesting a TLS certificate.

Code #

The records for a typical setup

Type    Name    Value            TTL     Purpose
A       @       203.0.113.10     300     the apex domain
A       www     203.0.113.10     300     www — or a CNAME to @
AAAA    @       2001:db8::1      300     IPv6, if your server has one
CNAME   api     example.com      3600    a subdomain on the same server
MX      @       10 mx.provider   3600    email, usually elsewhere
TXT     @       "v=spf1 ..."     3600    mail authentication

Note: a CNAME cannot coexist with other records at the apex, which is why
the apex uses an A record and www can use either.

# Verify from your machine
dig +short example.com A
dig +short www.example.com
dig @1.1.1.1 +short example.com      # ask an external resolver, not your cache

# Has it taken effect everywhere yet?
dig +noall +answer example.com       # shows the remaining TTL

# Does the server actually respond for that name?
curl -I -H "Host: example.com" http://203.0.113.10
curl -I http://example.com

Planning a migration without downtime

1. a day before: lower the TTL on the records you will change to 300
2. wait for the old TTL to expire, so everyone now caches for 5 minutes
3. make the change
4. verify with dig against several resolvers
5. keep the old server running for a few hours — some clients cache longer
6. raise the TTL back to 3600 once settled

Before requesting a TLS certificate

Let's Encrypt validates by making an HTTP request to the domain. The DNS
must already resolve to this server and port 80 must be reachable, or
validation fails. Confirm with curl first, then run certbot.

How it works #

An A record maps a name to an IPv4 address. The @ symbol means the apex domain itself — example.com with nothing in front.

A CNAME points one name at another. It is convenient for www and for third-party services, and it cannot be used at the apex alongside other records, which is why the apex needs an A record.

TTL is how long resolvers may cache the answer. The value in effect before your change is what governs how long old answers survive, which is why lowering it in advance is the only thing that speeds up a migration.

dig @1.1.1.1 queries an external resolver directly, bypassing your local cache. Comparing that with a plain dig shows whether you are looking at a stale local answer.

The curl -H "Host: example.com" test hits the server by IP while claiming the domain name, which confirms Nginx is configured for that host name before DNS has finished propagating.

Certificate validation depends on all of this being correct. Certbot makes a request to your domain over HTTP, so the record must resolve and port 80 must be open — attempting it too early is a common and confusing failure.

Real-world use #

Every deployment involves this step, and it is where deployments most often stall — usually because the record was created on the wrong domain, or because the old TTL was long.

Using a CDN or a proxy such as Cloudflare changes the picture: the record points at their network rather than your server, and they connect to your origin. That adds caching and protection, and it also means your server's real address should not be published anywhere.

Email records are separate and easy to break. Changing nameservers without recreating MX and TXT records silently stops mail delivery, which is often noticed days later.

For a planned server migration, the TTL sequence above is the difference between a five-minute cutover and a day of split traffic.

Monitoring the domain registration expiry is worth doing. An expired domain takes everything down regardless of how well the server is configured.

Common mistakes #

• Changing records while a long TTL is still in effect, then waiting hours.
• Trying to create a CNAME at the apex alongside other records.
• Requesting a certificate before DNS resolves to the server.
• Changing nameservers without recreating MX and TXT records first.
• Testing only from your own machine, where the old answer is cached.

Practice #

Point a domain or subdomain at a test server with a 300-second TTL. Verify with dig against two different resolvers and confirm the server responds for that host name. Then write down the exact sequence you would follow to migrate it to a new IP address with minimal disruption.