Networks from DNS to TLS

From hostname to HTTPS connection

When you enter https://www.example.com and press Enter, the browser needs a network address before it can contact the site. In this URL, https tells the browser to use protected web communication, and www.example.com is the hostname: the human-readable name of the site.

DNS, the Domain Name System, maps the hostname to an IP address, the numeric address networks use to route traffic. The browser or operating system may already have a recent answer in its cache. Otherwise, the device asks a resolver, a DNS service that looks up answers for clients. The resolver obtains the domain’s published DNS records from an authoritative nameserver, the server responsible for those records. DNS is a distributed naming system.

After receiving an IP address, the browser connects to the server and negotiates TLS, the protocol that authenticates the server and encrypts data between the browser and server. The browser checks the server’s certificate, including whether it covers the requested hostname. The browser and server then establish encryption keys for the connection. The sequence depends on the web protocol: HTTP/3 uses QUIC, which incorporates TLS, rather than creating a TCP connection before adding TLS (TLS 1.3; HTTP/3).

The browser sends an HTTP request for a page or other resource through that protected connection. The server returns a response. The browser then commonly requests other resources, including images, style sheets, and scripts.

DNS finds the destination, while TLS verifies the server and encrypts web data after the connection begins, so they protect different parts of the exchange.

What HTTPS leaves visible

HTTPS encrypts the page path, page contents, and most request and response headers while they travel across the network. Network observers still see the destination IP address and traffic patterns, including connection timing and data volume. They may also see the hostname through an unencrypted DNS lookup or during TLS setup, depending on the DNS and TLS privacy features in use.

Encrypted DNS hides the lookup from the local network, but the DNS provider still receives it.

DNS resolves the destination, while TLS verifies the server and protects web data in transit.

Does HTTPS hide which pages you visit? HTTPS hides the page path and contents from network observers, but it does not hide every detail of the connection.

How DNS finds a server

Before a browser connects to a hostname such as www.example.com, it needs an IP address. The browser and operating system first check for a cached DNS answer. If neither has an unexpired answer, the operating system sends the query to its configured recursive resolver: a DNS service that finds records on the device’s behalf.

The recursive resolver also checks its cache. If it has no usable answer, it follows the DNS hierarchy. It asks a root nameserver which nameservers handle the top-level domain, such as .com. It then asks a .com nameserver which nameservers are authoritative for example.com. Finally, it asks an authoritative nameserver that publishes the DNS data for that domain. The resolver returns the answer to the device and caches it for later requests.

For example, a resolver asked for www.example.com may return an address from its cache. On a cache miss, it obtains the published record from an authoritative nameserver. A records return IPv4 addresses; AAAA records return IPv6 addresses. A CNAME record points one hostname to another, so the resolver follows that name to find an address. Other DNS records serve different purposes. MX records identify mail servers. TXT records hold text used for domain verification and email policies. These record types are defined in DNS standards.

Why answers stay cached

Each DNS answer has a time to live, or TTL. The TTL sets how long a resolver may cache the answer. Caching speeds repeat lookups and reduces queries to authoritative nameservers.

When a domain operator changes an address record, resolvers that cached the old answer continue to return it until its TTL expires. Browsers, devices, and recursive resolvers therefore begin using the new address at different times. A wrong record or incorrect nameserver delegation requires a configuration fix; waiting for cached entries to expire does not correct published DNS data.

Use independent authoritative nameservers

A domain should use multiple authoritative nameservers so DNS remains available if one server or network fails. RFC 2182 recommends placing nameservers on different networks and in different geographic locations. Several nameservers within one network still share the same failure risk. Anycast also complicates server counts because one nameserver address may route queries to many locations.

Recursive resolvers choose among authoritative nameservers partly by observed response time. A 2019 APNIC analysis found that many resolvers favored faster responders. Resolvers that receive few queries have fewer opportunities to measure and compare nameserver performance.

What TLS protects

After DNS gives the browser a server IP address, TLS creates a protected connection. HTTPS carries HTTP requests and responses inside that connection.

In a TLS 1.3 handshake, the browser and server agree on cryptographic settings and exchange key material to derive shared session keys. The server also sends a certificate. The browser checks that certificate before accepting the server as authenticated. After the handshake, the session keys encrypt HTTP data and detect changes made in transit, as defined by TLS 1.3.

The certificate and session keys have different jobs. The certificate helps the browser authenticate the server. The session keys protect traffic after the handshake. HTTP/3 uses QUIC rather than TCP; QUIC incorporates TLS 1.3 instead of using the traditional TLS record layer.

A certificate check

A certificate binds a domain name to a public key. It includes signatures that link it to a certificate authority the browser trusts. The browser checks that the certificate covers the requested domain name and that its signature chain and validity period meet the browser’s rules. The service-identity standard defines how a client verifies that a certificate matches a server name.

An expired certificate, name mismatch, untrusted issuer, or incorrect device clock can produce a browser warning. A valid certificate shows that the browser reached a server with a certificate it accepts for the requested domain name. It does not establish that the website operator is honest, that the site has no security flaws, or that its content is safe.

TLS encrypts page contents and other HTTP data while they travel between the browser and server. It also detects changes made by someone observing or interfering with the network connection. Network observers still see the server IP address, connection timing, and some information about traffic size. Those details can reveal information even when HTTP content remains encrypted.

DNS privacy and integrity

Ordinary DNS queries between a device and its recursive resolver are often unencrypted. A network observer on that path, such as a local network operator or internet provider, can read the requested domain name. DNS over HTTPS (DoH) carries DNS queries inside HTTPS requests, while DNS over TLS (DoT) carries them over a TLS-encrypted connection. Both encrypt DNS traffic from the device to the chosen resolver. The resolver still receives the query and can link it to the device’s network address. RFC 8484 defines DoH, and RFC 7858 defines DoT.

DNSSEC protects the authenticity and integrity of DNS answers. A validating resolver checks cryptographic signatures on DNS records against a chain of trust that begins at the DNS root. For signed zones with a valid chain, it detects forged or altered DNS data and treats invalid answers as bogus. DNSSEC does not encrypt queries or hide requested names. A zone operator must sign its records, and the resolver handling the lookup must validate them. Signed records provide no DNSSEC protection when the resolver does not validate. RFC 4033 defines DNSSEC’s security goals.

Key takeaway: DoH and DoT reduce what the local network learns from DNS lookups. DNSSEC helps a validating resolver reject false DNS answers. They address separate risks.

Choosing an encrypted resolver

The resolver for a lookup may be set in the browser or operating system. A router or managed-network setting can also determine which resolver handles it. Before switching, compare the provider’s privacy policy, logging practices, filtering behavior, reliability, and legal jurisdiction. Encrypted DNS reduces the local network’s visibility while placing trust in the selected resolver.

DoH sends DNS messages through standard HTTPS exchanges. Browser support for DoH does not by itself determine which resolver receives queries; browser or device settings do. On a work or school network, encrypted DNS can bypass DNS filtering or monitoring configured by the network owner.

Local DNS filtering may enforce security controls, parental controls, or organizational policy. Bypassing it can violate network rules and remove protections the network owner intended to provide.

What ECH hides

When a browser begins a TLS connection, its ClientHello message has traditionally included Server Name Indication (SNI), a field that names the domain the browser wants to reach. Without Encrypted ClientHello (ECH), a network observer can read that domain name even though TLS encrypts the web traffic that follows.

ECH encrypts an inner ClientHello, including the requested server name. The client also sends an outer ClientHello with public information that allows the connection to start. RFC 9849 specifies ECH for TLS 1.3. It requires support from the client and the server-side ECH endpoint. Clients commonly obtain ECH configuration through DNS HTTPS records, which publish connection information for HTTPS services.

ECH does not hide the destination IP address. It also does not stop a plaintext DNS lookup from revealing the requested domain. Encrypted DNS protects DNS queries; ECH protects the hostname in the TLS handshake. Using both removes two separate sources of hostname exposure.

ECH can obscure which site a client selected when several domains share the same public-facing IP address or provider front end. An observer still sees a connection to that IP address or network and may infer more from traffic patterns.

The hosting design determines which operator learns the hostname. In shared hosting, the provider terminates TLS for many customer domains and reads the decrypted connection. In a split arrangement, a front end accepts the connection and relays traffic to a separate TLS endpoint. The ECH endpoint must decrypt the inner ClientHello, or pass its contents to a trusted front end, so ECH does not hide the hostname from the services that operate the connection.

Where ECH creates friction

Firewalls and TLS inspection tools that use SNI for domain-specific rules lose that signal when ECH encrypts the inner ClientHello. Organizations that rely on SNI filtering need to revise those policies or manage ECH settings on devices they control.

DNS-based blocking uses a different signal: DNS queries rather than the TLS hostname field. ECH alone therefore does not prevent a network from learning a domain through plaintext DNS. APNIC’s discussion of ECH and network controls describes these operational effects.

Reduced visibility does not indicate that a connection is harmful, and TLS inspection is unnecessary in many environments. Current ECH behavior follows RFC 9849 rather than earlier Internet-Drafts that describe previous designs.

Key takeaway: ECH hides the requested hostname from network-path observers, while DNS queries, destination IP addresses, traffic patterns, and the ECH endpoint still reveal parts of the connection.

When a connection fails

Start with the exact browser error and whether other websites load. If one site fails while others work, the problem is likely with that site’s hostname, DNS records, server, or certificate. If many sites fail, check the device’s network connection and DNS resolver. Testing the same site from another network, such as cellular data, helps identify the failing layer.

A DNS error such as NXDOMAIN means the resolver found no record for the requested hostname. Check the hostname’s spelling first. If you manage the domain, verify its nameserver delegation and DNS records. After a DNS change, resolvers may continue using cached answers until the record’s TTL expires.

If the hostname resolves but the browser times out, check the network path and server. Confirm that the device has network access, the destination address is correct, firewall rules permit the connection, and the server is listening on the required port. Changing DNS providers does not restore a server that is offline or refusing connections.

A certificate warning means the browser could not verify the server’s identity for the requested hostname. Check the device’s date and time, the hostname in the address bar, and the certificate’s expiration date. On work or school networks, TLS inspection software can also trigger a warning if its certificate is not trusted by the device. Mozilla lists common causes of secure-connection warnings.

Match the fix to the failing layer. Renewing a certificate does not restore a missing DNS record, and changing DNS resolvers does not fix an expired certificate. Do not bypass certificate warnings on sites where you enter passwords, payment details, or personal information. The warning means the browser could not verify the connection as expected.

What DNS, TLS, and ECH reveal

Privacy protections limit visibility for particular observers. Encrypted DNS prevents people running the local Wi-Fi network or internet connection from reading DNS queries sent to the selected resolver. The resolver still receives those queries and can associate them with the device’s network address. Encrypted DNS moves that visibility to the resolver; it does not make DNS lookups anonymous.

TLS encrypts web content in transit, including page paths and data in HTTP requests. Network observers still see the destination IP address, connection timing, and approximate volume of transferred data. When the client and server support ECH, it hides the requested hostname from some network observers. They still see the destination IP address, and an unencrypted DNS query reveals any hostname it carries. The hosting provider still receives and handles traffic for the requested site.

Network operators monitor traffic to diagnose outages, enforce access rules, and detect threats. DNS requests and TLS hostnames have long supplied useful signals for those tasks. Stronger privacy protections remove some of those signals, while visibility into browsing destinations imposes a privacy cost. The practical question is which threat needs attention: local-network snooping, altered DNS answers, interception of web content, or a resolver’s record of DNS lookups.

DNS Security Extensions (DNSSEC) address a separate threat by letting validating resolvers verify that signed DNS data is authentic and unchanged. DNSSEC neither encrypts DNS queries nor authenticates email. Email authentication uses mechanisms such as DKIM, which signs messages, and DMARC, which publishes a domain’s policy for messages that fail authentication. Their records appear in DNS, but DNSSEC deployment alone provides little information about a domain’s email authentication.

Common questions

Does HTTPS hide the domain?

HTTPS encrypts pages, form data, and other web traffic after the TLS connection begins. HTTPS alone leaves the domain name visible. Plain DNS lookups can reveal the requested domain, and SNI has traditionally exposed it during the TLS handshake.

Encrypted DNS protects the lookup between a device and its resolver. ECH encrypts hostname information in the TLS handshake. Neither hides the destination IP address.

Is DNSSEC the same as DoH?

No. DNSSEC uses cryptographic signatures so a validating resolver can confirm that DNS data came from the authorized zone and was not changed in transit. DoH encrypts DNS queries and responses between a client and its resolver.

DNSSEC validates the answer; DoH protects the connection to the resolver. The protections work together.

Does a VPN replace HTTPS?

A VPN encrypts traffic between a device and the VPN provider’s gateway. The local network sees an encrypted connection to the VPN, while the VPN provider receives traffic that the local network would otherwise see.

HTTPS still encrypts the web session between the browser and website. A VPN changes the network path and shifts some visibility to the VPN provider.

Why does a DNS change take time?

Resolvers and devices cache answers for the record’s TTL. After an operator updates a record, caches that already hold the old answer keep using it until the cached TTL expires.

There is no single global propagation event. Resolvers cached the old answer at different times, so they discard it at different times. Waiting does not fix an incorrect record or wrong nameserver delegation.

DNS and TLS takeaways

• Separate lookup from protection: DNS finds a domain’s IP address. TLS authenticates the server and encrypts web traffic once the connection begins.
• Match DNS protections to the risk: DNSSEC lets validating resolvers check DNS data for tampering, while DoH and DoT encrypt queries between your device and its resolver. The resolver can still see those queries.
• Know what stays visible: TLS does not hide the destination IP address or traffic patterns. ECH can conceal the requested hostname from some network observers, but it does not replace encrypted DNS.
• Troubleshoot the failing layer: For lookup errors, check DNS records and cached answers. For timeouts, check network reachability. For certificate warnings, check the device clock and certificate details.

FAQ

Does HTTPS hide the website name I visit?

HTTPS alone does not hide the website name. Plain DNS and traditional SNI can expose the requested domain. Use encrypted DNS to keep the local network from seeing DNS lookups. Use ECH where the browser, DNS provider, and website support it.

Is DNSSEC the same as DNS over HTTPS?

DNSSEC verifies signed DNS data when the resolver validates it. DNS over HTTPS encrypts DNS traffic between your device and a resolver. Use DNSSEC for authentic DNS answers and DoH for privacy on the path to the resolver.

How do I choose an encrypted DNS resolver?

Check which resolver your browser, operating system, or router uses. Then compare providers’ privacy policies, logging practices, filtering, reliability, and jurisdiction. DoH or DoT hides DNS queries from local-network observers, but the chosen resolver still sees them.

Why does a DNS change take time to appear?

Resolvers and devices cache DNS answers for the record’s TTL, so they can keep using an old address until that cache expires. If the record or nameserver delegation is wrong, waiting for a cache to expire will not fix the underlying problem.

How do I tell a DNS problem from a TLS problem?

A DNS failure means the device could not obtain a usable address for the hostname. Check the spelling, resolver, records, and whether a recent change remains cached. A certificate warning occurs later in the connection: check the device clock, requested hostname, certificate dates, and whether a managed network is inspecting the connection.

What if my browser shows a certificate warning?

Do not bypass the warning on a site where you enter passwords, payment details, or personal information. Check the device clock and website address. An expired certificate, name mismatch, or untrusted issuer can prevent the browser from authenticating the server.

Does a VPN replace HTTPS?

No. A VPN encrypts traffic between your device and the VPN provider, shifting some network visibility from the local network to that provider. HTTPS still protects the web session between your browser and the website.

What if ECH is enabled on a network that filters websites?

ECH can hide the requested hostname from network devices that rely on SNI for filtering or inspection. DNS-based blocking uses DNS lookups instead, so ECH does not by itself hide a domain requested through plaintext DNS.