DNS and TLS – Is It Really You?
This time, we want to explore an interesting question: how does entering the name of a website into your browser actually lead you to its content, and how can you be almost certain that the name you entered really points to the intended website and not to some shady imitation? The techniques and principles discussed below apply not only to accessing websites, but also to communication with services over the internet and networks in general.
DNS – Or: Can You Give Me Your Address?
The Domain Name System (DNS) ensures that you can reach a server hosting a website by entering a unique URL.
Behind the scenes, this works by resolving a Fully Qualified Domain Name (FQDN) into an IP address—specifically, a 32‑bit address in the case of IPv4—under which the server can be reached. Let’s walk through this step by step, starting with the registration of a second‑level domain, assuming that the server, including the website and a public IPv4 address, already exists.
First, the desired domain must be registered with a provider. Naturally, only names that have not already been assigned to someone else are available. The next step is choosing a top‑level domain (TLD). Today, there is a wide variety of them. Well‑known examples include .com or .org, as well as country‑specific endings such as .de or .uk.
Let’s assume we register the domain clouditarchitect.com. Next, on the name server that manages our DNS zone, we create an A record (address record) that maps our fully qualified domain name to the IPv4 address of the website.
Name Servers, DNS Zones, and Related Concepts
Anyone who has not worked much with DNS so far might now wonder what all these technical terms actually mean. Let’s clarify them together and introduce a few more along the way.
A name server, as the name suggests, is a server that provides various records associated with a domain, both for management and for retrieval by other servers. This collection of records is called a DNS zone, because it bundles all domain‑related data into a single logical unit.
The most important record types include:
Start of Authority (SOA) Record Contains administrative information, including the MNAME field, which defines the master name server. Typically, a DNS zone is hosted on multiple name servers, but one of them acts as the master and serves as the single source of truth.
Name Server (NS) Record Points to other name servers, often located in different DNS zones.
Address (A) Record Maps a hostname to an IPv4 address.
AAAA Record The IPv6 equivalent of an A record.
Canonical Name (CNAME) Record Also known as an alias record. This allows a subdomain to point to another domain. For example, blog.clouditarchitect.com could point to clouditarchitect.com. If the IP address in the A record changes, the subdomain automatically follows the new address.
MX Record Specifies which servers receive email for the domain.
TXT Record Can be used for various purposes, such as proving domain ownership to services like Google.
Additional record types include SRV (service discovery), CAA (certificate authorities), PTR (reverse DNS), and several others, some of which are relevant for DNSSEC. DNSSEC allows the authenticity of DNS records to be protected using digital signatures, preventing tampering by malicious attackers. At present, this mechanism is still relatively rarely used by domain owners.
From the Browser to the Website Address
When you enter a human‑readable domain name into your browser’s address bar, the browser cannot immediately access the website because it needs the corresponding IP address, which is difficult for humans to remember. This is why DNS resolution exists.
The process works roughly as follows: first, the browser checks its own cache to see whether it already knows the address. If not, the operating system’s cache is checked next. If the address is still not found, the actual DNS lookup begins.
The operating system then contacts the configured DNS resolver to obtain the desired address. One of the most well‑known recursive DNS resolvers is Google’s, reachable at the IP address 8.8.8.8. This resolver also maintains a cache, which is checked before the resolution process continues.
If no cached entry exists, the resolver queries a root server. The root server provides information about the relevant top‑level domain. In our example, for clouditarchitect.com, it would return the address of a server responsible for the .com TLD.
Next, that TLD server is queried to find information about the second‑level domain clouditarchitect. The TLD server contains NS records that specify the domain names of the authoritative name servers for clouditarchitect.com, as provided by the domain registrar.
An interesting edge case occurs when the name servers themselves are located within the same DNS zone. In that situation, resolving their addresses could otherwise lead to an infinite loop. To prevent this, the TLD server stores the IP addresses of the name servers directly in this special case. Normally, however, another DNS lookup is required to resolve the name server’s IP address.
Once the IP address of the authoritative name server is known, that server is queried for the address associated with clouditarchitect.com. It responds with the IP address stored in the A record. This address is then cached at all previously involved levels, so future requests can be resolved more quickly. Finally, the browser can establish a connection to the website using the resolved IP address.
TLS – Show Me Your ID
Once the browser knows the web server’s address, it initiates the TCP three‑way handshake on port 443, assuming the website is served via https. After that, the Transport Layer Security (TLS) handshake begins.
The browser announces which encryption methods it supports and sends a random value along with additional information to the server. The server responds with its own random value, further data, and—most importantly—its certificate. The certificate contains the domain name, the public key, the certificate authority (CA) that issued it, and a digital signature.
A Short Detour into Certificates
Browsers come with a set of preinstalled certificates, stored for example in the Windows Certificate Store or in a Linux CA bundle. These so‑called root certificates form the starting point of the chain of trust.
Root certificates sign intermediate certificates, which are then used by certificate authorities to sign website certificates. A well‑known CA that issues free certificates is Let’s Encrypt.
Signing a certificate means creating a digital signature. The certificate’s contents are first hashed, and this hash is then encrypted using the private key of the issuing certificate in the chain of trust. That encrypted hash is the digital signature.
To verify a certificate, the browser also hashes the certificate contents and decrypts the digital signature using the public key obtained during the TLS handshake. If both hashes match, the browser can generally trust the certificate.
To obtain a certificate from a CA for a domain, the domain owner must prove ownership. This can be done, for example, by placing a randomly generated one‑time token provided by the CA at a specific location under the domain.
Back to TLS
In addition to verifying the digital signature, the browser checks during the TLS handshake whether the certificate has expired and whether the domain name in the certificate matches the domain being accessed. If all checks pass, the key exchange can begin.
Focusing on the current TLS 1.3 standard, both sides generate temporary keys and exchange their public components. Based on these, they independently derive a shared secret that only they can compute. This shared secret forms the basis for symmetric encryption.
Symmetric encryption is deliberately used for data transfer because it is far more efficient than asymmetric encryption, where typically only one party holds the private key while others know the public key.
Using the shared secret and additional data such as the exchanged random values, session keys are generated during the TLS handshake. These keys are valid only for the current TLS session and are used to encrypt the subsequent data stream. Once the handshake is complete, the browser can securely retrieve the website’s content.
What Does “Secure” Actually Mean?
One major advantage of TLS is confidentiality: no one else can read the transmitted data. Even if someone intercepts the data packets, they only see encrypted information. Another benefit is integrity—any data manipulation would be detected immediately because verification values would no longer match.
An additional and very important security aspect is authentication: you know who you are communicating with. The server proves its identity to the client, in this case the browser.
Without TLS—and without DNSSEC—it would be possible to be redirected to a malicious server even when entering the correct URL. This is known as DNS spoofing and could enable various criminal activities. Fortunately, TLS and its associated certificates protect us from such attacks and many others carried out by malicious actors.
I hope this explanation has made the fundamentals of modern browser‑to‑website communication easier to understand. I’m already looking forward to sharing more insights with you in future blog posts.