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

Simulation — rehearse a web-only connection change. Prepare a destination, preview the narrow record diff, apply it locally, compare the authoritative and cached views, and roll it back. Every address and readiness result is synthetic; the scene does not contact a DNS provider or issue a certificate.

First select a destination that lacks content, hostname configuration or TLS readiness. Preview remains possible, but Apply stops without changing the original connection. An unused same-name zone also blocks the cutover: editing a zone is not evidence that the public delegation uses it. Return to the delegated zone and a prepared destination before rehearsing a valid web-record change.

After Preview and Apply, Verify reports the authoritative value and the one saved resolver route separately. The old entry expires at t=60. Advancing virtual time and verifying at expiry can obtain the new route; reducing the new TTL does not shorten the old saved lifetime. Roll back authority then verify again: a resolver that already saved the new route can still differ. Keep the old destination available for the authorized transition rather than treating rollback as a global cache flush.

The optional CNAME plan replaces the ordinary web A data rather than coexisting with it. Apex/conflicting CNAME plans and malformed targets stop. The scene uses one abstract routing cache, not separate caches for every alias and address in a real chain. Changing any plan input starts a new rehearsal; Reset restores the original A record, time, protected records and all flags. Record types TTL planning Delegation checks

For the selected A-record plan, the proposed replacement in DNS presentation form is:

www.example.test. 60 IN A 192.0.2.20

This is the complete synthetic web RRset, not a command to run or a replacement for the zone's MX/TXT records. The value is a documentation address. The CNAME plan instead removes the old A data at the same owner before using its synthetic hostname target.

Environment and stop conditions

The operational procedure below assumes you administer the domain, can inspect its delegated authoritative DNS, and have the destination's exact documented requirements. Provider controls and supported record types differ. Any dig example is read-only diagnostic syntax for an installed compatible BIND client, not a command that this page has executed. The documented reference here is BIND 9.20.23. Do not install tooling or change system configuration merely to reproduce the scene. dig command syntax

Stop before changing records if the destination does not serve the intended hostname over verified HTTPS, the delegated zone is uncertain, the proposed diff touches mail or unrelated records, or no authorized rollback is available. Save the old RRset, TTL and intended new values in the private change record. A successful outcome requires the correct public content and preserved unrelated services, not only a matching DNS value.

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.

Key takeaways

Prepare the destination before changing the name's route. Confirm the delegated zone, change only the intended web RRset, and verify authority, resolver data and the actual HTTPS hostname as separate observations. Preserve MX/TXT and the previous destination; a successful rehearsal or provider save message is not evidence that the public site works.