Domain, DNS and HTTPS: what happens when someone types your address

01From name to number: why DNS exists

Monday morning, nine o'clock. A firm's website opens blank, email is not arriving, the phone starts ringing. No virus, no server failure: the domain expired on Friday, and the renewal notice was going to a mailbox nobody reads anymore. It happens more often than you might think, and it can be avoided by knowing a few mechanisms. Let's start at the beginning.

Computers connected to the Internet recognize each other by numbers, IP addresses: something like 203.0.113.10 in the older version (IPv4), or a long sequence of digits and letters separated by colons in the newer one (IPv6). People, on the other hand, remember names. No customer would type a string of numbers to find your firm, while they remember yourcompany.it effortlessly.

The DNS (Domain Name System) is the service that bridges the two: it receives a name and returns the number of the server to contact. It was described in 1987 in two technical documents, RFC 1034 and 1035, which are still the foundation of everything today. It is, quite literally, the street directory of the Internet.

In the chapter on professional web infrastructure I described the house, meaning the server. Here I describe the address and the road to get there: what you buy when you buy a domain, what happens in the milliseconds between the moment someone types your name and the moment they see the page, and which mistakes in this chain bring down a website or the email of an entire company.

How to read an address

A web address is read from right to left, from the general to the specific, like a postal address written backwards. Each dot separates a level:

• the extension (in jargon TLD, top level domain) is the last part: .it, .com, .eu, .ro;
• the name is the part you register: it is yours as long as you renew it;
• the subdomain is everything in front of it: www, but also book.yourcompany.it or mail.yourcompany.it. You do not buy it: you create it yourself with a DNS record;
• the path after the slash has nothing to do with DNS: it is the page inside the site, and the server decides it.

02Registry, registrar and registrant: who owns the name

A domain is not bought forever: it is registered for a period, usually one or more years, and renewed. There are four players in the chain, and it is useful to know them all because each has a different role:

• ICANN is the international nonprofit organization that coordinates the system of names and addresses worldwide;
• the registry runs a single extension and keeps the official list of registered names. For .it it is the Registro .it, based in Pisa at the Institute of Informatics and Telematics of the CNR (the Italian National Research Council);
• the registrar is the provider you turn to in order to register the name, often the same one that sells hosting and email;
• the registrant is whoever holds the right to use the name: it must be your business, with its own details.

Expiry: the most trivial and most costly risk

A domain that is not renewed stops working: website, email, everything. After expiry there is usually a period in which the former registrant can still recover it, then the name becomes free again and anyone can register it, including people who buy expired names to resell them. Three precautions are enough to avoid the risk:

• turn on automatic renewal with a payment method that does not expire next month;
• keep the registrant's contact email up to date, because that is where the notices arrive;
• note the expiry date somewhere another person in the company can see it too.

03Resolution: four questions in a few milliseconds

When someone types your address, their computer does not know where the server is. It has to ask, and it does so through a chain of questions called resolution. It is worth following it step by step, because it explains almost all the “mysterious” behavior of domains.

Put this way it sounds long, but it happens in a few tens of milliseconds, and almost never in full: every link keeps in memory the answers it has already received. Your Internet provider's resolver already knows who manages .it, because thousands of people asked it a minute ago. The browser itself and the operating system also keep recent answers.

The root servers are identified in the system by 13 names, from the letter a to m, run by 12 different organizations. Behind each name there are in fact many machines scattered around the world, answering at the same address: that is why the root of the Internet does not go down when a single computer fails.

The authoritative server is the one that matters to you: that is where your domain's records live, and whoever has access to the panel where they are edited decides where the website and email go. Which servers are your authoritative ones is communicated to the registry through the NS records, usually with a couple of clicks in the registrar's panel.

04DNS records: the domain's identity card

On the authoritative server, your domain is described by a list of lines called records. Each record has a name (which address it refers to), a type (what it says), a value and a TTL (how long others may keep it in memory). It is an identity card: whoever reads it knows where the website lives, where to deliver email, who is authorized to send on your behalf.

TXT records and email

Three TXT records decide whether the emails you send land in the inbox or in spam: SPF (which servers may send on behalf of the domain), DKIM (the cryptographic signature of messages) and DMARC (what to do with emails that fail the checks). They are so important that they have a chapter of their own, the one on professional business email. Here it is enough to know where they live: in the same identity card of the domain, next to the website's record.

Subdomains: different doors of the same house

With a record you create a subdomain, and each subdomain can point to a different server: the showcase website on a hosting plan, book.yourcompany.it on the portal's VPS, shop.yourcompany.it on an external platform. It is also one of the ways to organize a website in several languages, along with folders (/ro/) and national domains: I compare the pros and cons of each choice in the chapter on the multilingual website.

05The TTL and the famous “propagation”

When a record is changed, the person who just edited it sees the new website, the colleague next to them still sees the old one, and a customer on the other side of Italy sees one or the other depending on the time. People say the DNS is “propagating”, as if the change had to travel. In reality nothing travels: memories expire.

Every record has a TTL (Time To Live), expressed in seconds. A resolver that received an answer with a TTL of 3600 can reuse it for an hour without asking again. If you changed the address five minutes later, that resolver will keep giving the old one for another 55 minutes. Multiply that by the millions of resolvers in the world, each with its own expiry, and you have “propagation”.

How to move without gaps

The TTL is the lever for moving a website or a mailbox from one server to another without outages. The procedure I follow is always the same:

1. One or two days before, lower the TTL of the records that will change (for example to 300 seconds, five minutes). You have to wait for the old, long TTL to expire, so that the memories are updated.
2. Prepare the new server and test it before moving the name, for example by forcing the address on your own computer.
3. Change the record: within a few minutes almost everyone sees the new server.
4. Keep the old server running for a while longer, for late requests.
5. Once the move is complete, raise the TTL again: a high value lightens the servers' workload and makes the domain more resilient.

This procedure also applies when moving from shared hosting to a VPS, the transition I describe in the chapter on web infrastructure. With email it requires extra care: the MX record must be moved, and SPF and DKIM must be updated for the new sending server, otherwise outgoing emails look suspicious for days.

06HTTPS: the encrypted conversation and the padlock

Once the server is found, the browser starts talking to it. With the old HTTP the conversation traveled in the clear: anyone on the same network (a café's Wi-Fi, a compromised router) could read passwords and forms, or even change the page as it arrived. HTTPS is the same HTTP inside a channel encrypted with the TLS protocol, and it solves three problems at once:

• confidentiality: what the browser and server exchange cannot be read by anyone in between;
• integrity: nobody can modify the page or the data along the way without the browser noticing;
• authenticity: the server proves, with a certificate, that it really belongs to the domain written in the address bar.

The handshake

Before exchanging the page, browser and server carry out a short negotiation called the handshake. In the current version of the protocol, TLS 1.3, a single round trip is enough: the browser proposes how to encrypt, the server replies by choosing and presenting its certificate, both calculate a secret key that nobody has ever transmitted, and from that moment everything travels encrypted.

The certificate and the chain of trust

The certificate is a digital document that binds the domain name to a cryptographic key, signed by a certificate authority. The browser does not know your certificate, but it already knows a list of root authorities it trusts: if your certificate is signed by an intermediate, and the intermediate by a root on the list, the chain holds and the page opens without warnings.

Today a certificate for a website no longer costs anything: Let's Encrypt, a nonprofit authority, issues them for free and automatically. Its certificates last 90 days and are renewed by a program that does it on its own, usually every 60 days. The trend across the whole industry is toward ever shorter lifetimes: the CA/Browser Forum, the body that brings together certificate authorities and browser makers, approved in 2025 a gradual reduction of the maximum certificate lifetime from 398 to 47 days, in stages between March 2026 and March 2029. The upshot: a certificate renewed by hand once a year is a way of working that is coming to an end. Renewal must be automatic.

What the padlock says, and what it doesn't

The padlock in the address bar means that the connection is encrypted and that the server really belongs to the domain written there. It does not mean the site is honest: even a scam page can have a valid certificate for its scam domain. That is why you have to read the address, not just glance at the padlock: yourcompany.it and yourcompany-payments.com are two different owners.

The last three precautions

• Permanent redirect: all variants of the address (with and without www, with http and with https) must lead with a 301 redirect to a single version. For search engines, a site reachable from four different addresses is four sites competing with each other.
• HSTS: a header with which the server tells the browser “from now on, with me, speak only HTTPS”. It also closes the very first instant in which the connection might start in the clear.
• No mixed content: an HTTPS page that loads an image or a script over HTTP loses part of its protection, and browsers block or flag those pieces.

07The mistakes that bring a website down (and how to avoid them)

Almost all the trouble with domains and certificates comes from a few recurring mistakes. Knowing them is the cheapest way not to live through them.

A well-managed domain is never noticed. It gets noticed the day email stops arriving, and that is usually a Monday.

Frequently asked questions

Sources

1. RFC 1034, “Domain Names – Concepts and Facilities” and RFC 1035, “Domain Names – Implementation and Specification”: the foundations of DNS, records and TTL.
2. IANA, “Root Servers”: the 13 names of the root servers and the 12 organizations that run them.
3. ICANN and Registro .it (in Italian): the global coordination of names and the registry of the Italian extension.
4. RFC 8446, “The Transport Layer Security (TLS) Protocol Version 1.3”: the handshake in a single round trip.
5. Let's Encrypt, frequently asked questions (in Italian): free certificates, 90-day lifetime and renewal recommended every 60 days.
6. CA/Browser Forum, Ballot SC-081v3: the reduction of the maximum certificate lifetime from 398 to 47 days between March 2026 and March 2029.
7. MDN, “Strict-Transport-Security” and MDN, “Mixed content” (in Italian).

Chapter updated October 2026. IP addresses, server names and times in the plates are examples, taken from the ranges the standards reserve for documentation; the redirect behavior of zenithdevelop.com was checked on October 22, 2026.