Skip to content
DevOps devops domains 5 min read

Pointing a Domain to Your Server

You bought a domain, and you have a server running somewhere. Right now those two things know nothing about each other. “Pointing a domain to your server” is the step that connects them: you tell the internet that when someone types yourdomain.com, they should be sent to your server’s IP address (the numeric address, like 203.0.113.42, that identifies your machine on the internet). This is the page that finally makes your site live, so it is worth doing slowly and carefully.

The whole job comes down to one DNS record called an A record (an “Address record”, which maps a name like yourdomain.com to an IPv4 address). Once that record exists and the internet has had time to learn about it, your domain points at your server. Let’s walk through it end to end.

Step 1: Find your server’s public IP address

Before you can point a domain at your server, you need to know the server’s public IP (the address other machines on the internet can reach, as opposed to a private LAN address like 192.168.x.x that only works on a local network).

If you are logged into your Ubuntu server over SSH (Secure Shell, the encrypted way you connect to a remote machine), run this:

curl -4 ifconfig.me

This asks an external service to tell you which IPv4 address your requests are coming from, which is your public IP.

Output:

203.0.113.42

Do not use the IP shown by ip addr or hostname -I alone. On most cloud servers those show a private internal address, not the public one your domain needs. Cloud providers (AWS, DigitalOcean, Hetzner) also show the public IP in their dashboard — confirm the two match.

When to use which IP: use the public IPv4 address for your A record. If your provider also gives you an IPv6 address, you can add an AAAA record (the IPv6 equivalent of an A record) later, but an A record alone is enough to go live.

Step 2: Create the A records at your DNS host

Your DNS host (the company that answers DNS questions for your domain — often your registrar, or a service like Cloudflare) has a control panel where you add records. You will create two A records:

Name (host)TypeValue (points to)What it covers
@A203.0.113.42The bare domain, yourdomain.com
wwwA203.0.113.42The www.yourdomain.com subdomain

The @ symbol is shorthand for “the domain itself” with no prefix. Adding www separately means both yourdomain.com and www.yourdomain.com reach your server.

In most panels the steps are:

  1. Open your domain’s DNS or DNS records page.
  2. Click Add record.
  3. Set Type to A, Name/Host to @, Value/Points to to your IP, and TTL to 3600 (or “Automatic”).
  4. Save, then repeat with Name set to www.

TTL (Time To Live) is how many seconds other servers are allowed to cache this record before checking again. A lower TTL means changes spread faster but slightly more lookups. 3600 (one hour) is a sensible default.

Gotcha: some panels want the full name (www.yourdomain.com) and some want just www. If you accidentally create www.www, your subdomain breaks. When unsure, look at an existing record to see which convention your host uses.

Step 3: Wait for DNS propagation

Propagation is the delay while DNS servers around the world drop their old cached answer and pick up your new record. It is usually quick (a few minutes) but can take up to the TTL value, and occasionally longer for a brand-new domain. You do not need to do anything during this time except wait and check.

Step 4: Verify the record from your own machine

On your local computer (not the server), use dig (a command-line tool for querying DNS) to ask what IP your domain now resolves to. On Ubuntu, dig comes from the dnsutils package:

sudo apt update
sudo apt install -y dnsutils
dig +short yourdomain.com A

The +short flag trims the output down to just the answer.

Output:

203.0.113.42

If that matches your server’s IP, the A record is working. Check www too:

dig +short www.yourdomain.com A

Output:

203.0.113.42

You can also use ping to confirm the name resolves and the server responds:

ping -c 3 yourdomain.com

Output:

PING yourdomain.com (203.0.113.42) 56(84) bytes of data.
64 bytes from 203.0.113.42: icmp_seq=1 ttl=54 time=11.8 ms
64 bytes from 203.0.113.42: icmp_seq=2 ttl=54 time=12.1 ms
64 bytes from 203.0.113.42: icmp_seq=3 ttl=54 time=11.9 ms

The key part is the IP in parentheses: it must be your server’s public IP. If ping resolves the right IP but times out with no replies, that is fine — many servers block ping (ICMP) with the firewall. As long as dig shows the correct IP, DNS is done.

Step 5: Tie it into your Nginx server_name

DNS gets the visitor’s request to your server. Nginx (a popular web server and reverse proxy — a server that sits in front of your app and forwards requests to it) then decides what to serve based on the domain the visitor asked for. That match happens through the server_name directive.

Edit your site config in /etc/nginx/sites-available/:

sudo nano /etc/nginx/sites-available/yourdomain.com

Make sure server_name lists both names so Nginx accepts requests for either:

server {
    listen 80;
    server_name yourdomain.com www.yourdomain.com;

    root /var/www/yourdomain.com/html;
    index index.html;

    location / {
        try_files $uri $uri/ =404;
    }
}

Test the config and reload Nginx so the change takes effect:

sudo nginx -t
sudo systemctl reload nginx

Output:

nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
nginx: configuration file /etc/nginx/nginx.conf test is successful

If your firewall (ufw, the Uncomplicated Firewall on Ubuntu) is active, make sure web traffic is allowed:

sudo ufw allow 'Nginx Full'

Now open http://yourdomain.com in a browser. You should see your site. The server_name value must exactly match the names in your A records, or Nginx falls back to its default server and you may see the wrong page or a 404.

Best Practices

  • Always create both @ and www records so visitors reach you with or without the www prefix.
  • Keep your A records pointing at a single source of truth — if you change servers, you only update the IP in one place.
  • Use a short TTL (e.g. 300) a day before a planned IP change so the switch propagates fast, then raise it back to 3600 afterward.
  • Verify with dig +short from your local machine before assuming propagation is incomplete — browsers and your OS cache aggressively and can lie.
  • Make sure server_name in Nginx matches your records exactly, and run sudo nginx -t before every reload.
  • Once HTTP works, add HTTPS with a free certificate so your site loads securely over https://.
Last updated June 15, 2026
Was this helpful?