Connect a domain to a hosting

Two ways to connect

A domain and a hosting are separate purchases, and nothing connects them until you do. The connection is always the same idea: the DNS must answer with the address of the server, and the server must know the name. There are two ways to get there, and the choice stays with you for the life of the site.

• Delegate the domain to the hosting name servers. At the registrar you replace the name servers with the ones the hosting gives you. From then on the hosting panel holds every record: the address, the mail, the verification codes. Fewer places to look, and the panel keeps the records in step with the site it creates for you.
• Keep the DNS at the registrar and add records. The name servers stay the registrar ones, and you create an A record that points to the hosting address. The hosting only serves the site. You can move the site to another provider by editing one record, and mail can live at a third company.

Beginners should take the first way: fewer mistakes, fewer places where a typo can break the site. Anyone who runs mail, several subdomains or more than one provider will sooner or later prefer the second. Both are normal, and neither is a lock-in as long as you keep control of the registrar account. The checks in this lesson use curl and dig, which run on any Linux machine.

Records you will meet

A DNS zone is a list of records. Each record has a name, a type, a value and a TTL. Seven types cover almost everything a website needs.

TTL deserves a word of its own because it causes most of the confusion. A resolver that asks for example.com keeps the answer for the TTL, usually 3600 seconds, and does not ask again. If you change the record, the old answer lives on in caches around the world until it expires. That is why a change can look broken for an hour and then fix itself, and why nothing you do in the panel makes it faster.

Two more types appear later in the course. CAA limits which certificate authorities may issue certificates for the name, and it is worth adding once HTTPS works. SRV is used by services such as mail autoconfiguration and chat; you can ignore it until a service asks for one.

Apex and www

The name without a subdomain, example.com, is called the apex or the root of the zone. The name with www is a subdomain. Visitors type both, and both must work, ideally with one redirecting to the other.

• The apex must have an A record, and an AAAA record if the site has IPv6. A CNAME is not allowed at the apex: the apex must hold the SOA and NS records of the zone, and a CNAME cannot sit beside any other record. The MX and TXT records that usually live at the apex are an extra reason, not the rule.
• www can be a CNAME to the apex, which follows the address automatically when it changes. Many providers instead give it its own A record, which also works.
• Some providers offer an ALIAS or ANAME record: it behaves like a CNAME at the apex and is resolved by the provider. It is convenient when the hosting address can change, and it is not a standard record type, so moving it to another DNS provider needs care.

Choose one primary name and redirect the other to it. Most sites use the apex as primary and send www to it; the opposite works too. What matters is that both resolve, the certificate covers both, and only one version answers with content, so that search engines and analytics see a single site.

Way 1: delegate to the hosting

The hosting panel shows two or four name servers, for example ns1.hosting.example and ns2.hosting.example. At the registrar, open the domain, find the name server settings, switch from the default servers to your own, and paste the two names. Save, and wait: the registry publishes the new delegation, which takes from minutes to a day.

Check the delegation at the registry, not at your own resolver:

dig +short NS example.com

ns1.hosting.example. ns2.hosting.example.

When the answer shows the hosting servers, the delegation is done. The hosting creates the zone for the domain when you add the site in its panel, so the address record appears there, not at the registrar. If the answer stays empty for a day, the names were probably typed with a missing dot or the registrar requires its own name servers to be removed first.

Way 2: DNS at the registrar

Keep the registrar name servers and add the records yourself. In the DNS section of the registrar panel, create an A record for the apex with the IPv4 address of the server, an AAAA record for IPv6 if you have one, and a CNAME for www:

example.com. 3600 IN A 203.0.113.10 example.com. 3600 IN AAAA 2001:db8::10 www.example.com. 3600 IN CNAME example.com.

The trailing dot in example.com. means a full name. In a panel field you usually type the name without the dot and the panel adds it; typing the dot there can produce example.com.. and a broken record. The @ sign is a common shorthand for the apex.

If mail is handled elsewhere, add its MX records here too, and the TXT records the mail provider gives you. A site that moves to another server then needs one A record changed, and mail keeps working. The full set of mail records is in lesson 9.

Add the domain in the panel

The DNS is only half of the connection. The server must also be told that it answers for this name. On shared hosting that is one form in the panel; on a VPS it is a server block in Nginx, written in lesson 5. The shared hosting steps are usually:

1. Open the sites section and choose Add site or Create website.
2. Type the domain, example.com, without http and without a path.
3. Choose the folder, or accept the one the panel suggests, such as /home/example/www/example.com.
4. Choose the PHP version for the site, 8.3 if the panel offers it.
5. Decide whether the panel should create the DNS zone, a mailbox and a database at the same time.
6. Save, and check that the site appears in the list with the status active.

If the panel asks for the www version as a separate site, add it as an alias rather than a second site: an alias serves the same files and gets the same certificate.

Check with dig and curl

Do not trust the browser yet: it caches, it remembers redirects and it hides errors. Ask the DNS and then ask the server directly.

dig +short example.com

203.0.113.10

dig +short www.example.com

example.com. 203.0.113.10

The second answer shows the CNAME first and then the address it leads to. If the address is not the one in the hosting panel, the record is wrong or cached; ask a public resolver to compare:

dig +short @1.1.1.1 example.com

Then the web server. A HEAD request prints the status line and the headers without downloading the page:

curl -I http://example.com

HTTP/1.1 200 OK Server: nginx Date: Fri, 06 Nov 2026 10:00:00 GMT Content-Type: text/html; charset=UTF-8

A 200 means the server found the site. A 403 usually means the folder exists but the index file is missing or unreadable. A 404 means the server answered but has no such site: the name is not in the panel, or the request reached a default site. A connection refused or a timeout means the address is wrong or a firewall blocks port 80. The status codes themselves are explained in HTTP status codes.

HTTPS from the panel

Once HTTP works, HTTPS is one click on shared hosting. The panel offers a free certificate from Let's Encrypt: it asks the certificate authority for a certificate, proves that you control the domain by placing a file on it or a TXT record in its zone, and installs the result. The proof only works if the domain already points at the server, so connect the domain first and the certificate second.

Two conditions decide whether the automatic issue succeeds: both example.com and www.example.com must resolve to this server, and nothing must block port 80 during the check. Some panels offer a wildcard certificate, which covers every subdomain at once; it needs a DNS challenge instead of a file on the site.

curl -sI https://example.com | head -n 3

HTTP/2 200 server: nginx date: Fri, 06 Nov 2026 10:00:00 GMT

The certificate renews automatically, usually 30 days before it expires, because the panel runs a scheduled task for it. Check once a year that the renewal still works: a domain moved to another server, or a redirect that sends the check to a different name, breaks it quietly. The certificate itself, its chain and its trust are explained in HTTPS and certificates in plain words and PKI.

After HTTPS works, add the redirects: http to https, and one of the two names to the other. On shared hosting they are switches in the panel or rules in .htaccess, and lesson 4 shows both.

Quiz

Article author: Arthur Isaev