ClueDNSSearch

concept · beginner

Domain names, DNS, URLs, hosting, CDN, and email

Learn what each layer identifies or delivers, where one layer ends, and why a DNS answer cannot prove that a website or email works.

Published
Jul 28, 2026
Last verified
Review by
Risk
read-only
Provider
neutral

A domain name is a name. DNS is a distributed naming system and protocol. A URL identifies a resource and includes instructions for accessing it. Hosting, a CDN, and email are services that can use the name; none of them is the name itself.

Read one URL by layer

Consider this reserved example:

https://www.example.com:443/guides/dns?view=short#answer
Part Value Job
Scheme https Selects the URL scheme and associated connection behavior
Host www.example.com Identifies the host in this URL
Port 443 Selects a network port; omitted when the default applies
Path /guides/dns Identifies a path handled after reaching the service
Query view=short Supplies application-specific input
Fragment answer Identifies a secondary resource in the representation; it is not sent in an HTTP request

The URL Standard defines how these components are parsed [1]. DNS may help resolve the host, but DNS does not resolve the URL path, query, or fragment.

Domain name

Current DNS terminology defines a domain name as an ordered list of labels [2]. In common display form, dots separate labels: www.example.com.

The labels form a hierarchy:

  • com is below the root;
  • example is below com;
  • www is below example.com.

“Domain” is used loosely in conversation. It may mean a registered name such as example.com, a DNS subtree, or a URL’s host. State the exact name when the distinction matters.

DNS

DNS associates names with typed data called resource records. For example:

  • A and AAAA can associate a name with IPv4 and IPv6 addresses;
  • MX can identify mail exchangers;
  • NS participates in delegation and identifies authoritative servers;
  • TXT can carry text used by several application protocols.

DNS does not store a whole website, deliver an email, or prove that an application listening at an address works. A successful address lookup is evidence about the DNS layer only.

Registered domain

A registration grants contractual rights and responsibilities for a name under a registry policy; it is not permanent ownership of the string. ICANN separates the registrant, registrar, and registry operator in the registration process [3].

A registered domain can exist without a working website. A working service can also use a hostname below the registered name, such as api.example.com.

Hostname

“Hostname” is used inconsistently. In operational work, record the complete name—such as www.example.com—instead of assuming that “host” means only www. A URL host can also be an IP address, so “URL host” and “domain name” are not perfect synonyms.

Web host, origin, and CDN

A web host runs or stores the application that answers web requests. An origin is the upstream application or server from which a reverse proxy or CDN obtains content. A CDN can answer at the edge, terminate TLS, cache responses, and hide the origin address.

DNS can point a hostname toward infrastructure used by a host or CDN. Once a client has an address, TLS and HTTP determine what happens next. If DNS returns the intended answer but the page redirects incorrectly or presents the wrong certificate, continue at those layers rather than repeatedly editing DNS.

Email provider

An email provider operates mailboxes or message transport. DNS can publish instructions used by email systems—such as MX destinations and SPF, DKIM, or DMARC policy—but the DNS records do not themselves receive or deliver mail.

This is why “the website works” does not prove “email works.” They can depend on different records, providers, credentials, and application paths.

Use the layer boundary

When diagnosing a problem, ask the narrowest useful question:

  1. Is the registration active and controlled by the intended registrant?
  2. Is the name delegated to the intended DNS host?
  3. Does authoritative DNS publish the intended record?
  4. What did a named recursive resolver return, and when?
  5. Did the client establish the intended TLS and HTTP, SMTP, or other application session?

Each answer identifies the next owner and prevents a working layer from being changed merely because a different layer failed.

Next step

Map each layer to the person or system that controls its settings.