How to point a domain to a web host

Pointing a domain means changing DNS so web requests reach your hosting service. It’s a smaller change than it sounds — a record or two — and it shouldn’t touch your email records or move the registration. Most trouble with this task comes from editing more than was needed, not less.

1. Collect the host’s required values

Find the domain-connection instructions for the hosting service. Record the exact hostname, record type, and destination. A host may request:

• an A record for the root domain,
• an AAAA record for IPv6,
• a CNAME for www, or
• provider-specific verification records.

Do not substitute an IP address for a required hostname or create a CNAME at the root unless the DNS provider explicitly supports the needed alias behavior.

2. Confirm where authoritative DNS is managed

Check the domain’s nameservers and sign in to the provider that hosts that zone. Editing a DNS panel that is no longer authoritative has no public effect.

Export or capture the existing zone before changing it. Pay particular attention to MX, SPF, DKIM, DMARC, verification, and subdomain records.

3. Lower TTL before a planned cutover

If the old site is live, lower the TTL on the records you will change at least one previous TTL period before the cutover. A TTL of 300 seconds can be useful during a controlled move. It cannot invalidate answers that were cached under an earlier, higher TTL.

Do not lower every record by default. Change only the web records involved.

4. Create or update the web records

Configure the root domain and www according to the host’s instructions. A common arrangement is:

@      A       192.0.2.10
www    CNAME   example.com.

192.0.2.10 is reserved for documentation; use the address supplied by the host. Many DNS panels represent the root with @, a blank field, or the full domain name.

Remove conflicting records only after confirming they are obsolete. A hostname should not normally have a CNAME and other record types at the same name.

5. Verify authoritative and recursive answers

Query the authoritative server first, then a normal recursive resolver. (dig ships with macOS and most Linux systems; on Windows, nslookup or any web-based DNS lookup tool answers the same questions.)

dig NS example.com +short
dig @ns1.dns-provider.example example.com A +short
dig example.com A +short
dig www.example.com CNAME +short

Confirm the returned values match the intended host. If authoritative DNS is correct but a recursive resolver returns the old answer, wait for the cached TTL to expire.

6. Test the website and HTTPS

Open the root domain and www over both HTTP and HTTPS. Verify the correct site appears, certificate names cover every public hostname, and redirects end at one canonical HTTPS URL. Test forms, authentication, assets, and important pages.

Keep the old host available through the longest relevant TTL and a validation window. If the new origin fails, restore the prior records and investigate without deleting the old environment.

Sources and further reading

• RFC 1034: DNS concepts and facilities
• RFC 1035: DNS implementation and specification