Connect a domain to a website

What it means

To connect a domain to a website, make the intended hostname resolve to the hosting service and ensure the service is configured to answer requests for that hostname over HTTPS. The usual change involves a DNS A, AAAA, CNAME or provider-specific alias record, depending on the hosting provider's instructions. DNS only supplies routing information; it does not deploy website files or issue a TLS certificate by itself. DNS routing Record types

This is a procedure, not a live DNS check or a command to edit any particular production domain. Obtain the exact target values from your hosting provider. The addresses below are reserved illustrations and must never be pasted as real destinations. Documentation-only IPs

Try it

Example — review a fictional zone before making a change. This is static sample data, not real DNS output.

example.com.      IN A      192.0.2.20
www.example.com.  IN CNAME  example.com.
example.com.      IN MX 10  mail.example.com.
example.com.      IN TXT    "v=spf1 ..."

The A record and the CNAME concern web routing. The MX and TXT entries illustrate independent mail functions. Changing the web host does not require deleting those mail records. At the exact hostname where a CNAME is used, other ordinary data cannot coexist with it under standard DNS rules. Many DNS providers offer special apex alias/flattening features; follow that provider's supported configuration instead of placing a standard CNAME next to an apex's NS/SOA records. DNS aliases Mail records

Before you change anything

• Confirm you control the domain registration and have permission to edit the currently authoritative DNS zone. The registrar, DNS operator and host may be different companies.
• Have the replacement website staged and working on a provider preview address; confirm it serves the correct content. Know whether the host needs example.com, www.example.com or both.
• Obtain the provider's exact record name, type and target, including whether an A/AAAA address, CNAME hostname or vendor alias is required. Do not invent a destination IP.
• Export or photograph the existing DNS zone, including web, MX, TXT (SPF/DKIM/DMARC where used), CAA, NS and other service records. Record original TTL and who operates email.
• Decide on a rollback window. Keep the old host alive while cached DNS answers might still point to it. Lowering TTL shortly before cutover does not shorten lifetimes already cached by resolvers. TTL guidance

Safe change procedure

1. Identify the authoritative zone. Compare the domain's delegated name servers with the DNS control panel you intend to edit. A record saved in a non-delegated zone may not affect public answers. Do not change registrar name servers just to edit one website record. Wrong-zone diagnosis
2. Prepare both hostnames. Ensure the destination accepts the domain names and has a valid certificate or a documented issuance process. Note the application's expected canonical hostname and redirects.
3. Change only the necessary web record. For an address supplied by the provider, update the named A/AAAA record as instructed. For a provider hostname, use CNAME on a compatible subdomain such as www, or the DNS operator's documented apex alias when required. Do not create a CNAME alongside other records of that same owner name. Supported types
4. Leave other services intact. Keep MX and mail-authentication TXT records, plus unrelated names. Never replace the whole zone with a minimal example, and do not disable DNSSEC without a specific migration plan. Mail record types
5. Save and verify the authoritative answer. Read the saved record back in the control panel and, if you have a DNS client, query the authoritative name servers for the intended type. A provider-side simulated response is not proof that public delegation points to that zone. Authoritative vs delegated zone
6. Test through a regular resolver and in a browser. Check both root and www as applicable, direct deep links, redirects, HTTPS certificate/hostname, and the expected page. Check email reception and sending on an existing mailbox, if relevant, without touching mail DNS.
7. Watch and retain the rollback path. Different resolvers may have different cached answers. Keep monitoring the old and new endpoints during overlap; do not treat a single successful lookup as worldwide confirmation. TTL and caches

Verification example

With a DNS client installed, the following are read-only example queries. Replace example.com with your own authorized hostname and select the intended record type. Different recursive resolvers can report different cached results.

dig NS example.com
dig A example.com
dig AAAA example.com
dig CNAME www.example.com
dig MX example.com

Do not infer that an empty CNAME response means www is broken; it may use address records instead. Check the type the provider actually instructed. An authoritative lookup and an ordinary recursive lookup answer different questions; both can be useful. Live results, the TLS endpoint and real application content must be verified independently of this article.

If the result is wrong

If only DNS differs, first verify that you edited the delegated zone and the right hostname/type. If DNS is right but the website is wrong, examine the web host's domain binding, deployment and HTTPS setup; DNS cannot repair the application. If existing email fails, check original MX, TXT and mail service state before making additional edits. Avoid broad “reset DNS” controls. DNS diagnosis

In practice

Rollback: restore only the web records you recorded before the change, subject to the current provider's supported record constraints. Leave mail and unrelated DNS settings untouched. Keep both destinations operational while cached answers expire and confirm website and mail service again. If you actually changed name servers as part of a planned DNS-provider migration, follow a separate full-zone migration and rollback plan; it affects much more than web traffic. Delegation warnings

The desired finish is measurable: correct authoritative records, successful browser load with HTTPS for intended hostnames, working important links, and unchanged mail service. A teaching example cannot certify those real-world outcomes.