What Actually Happens When You Point a Domain to Someone Else's Server

On the internet, a domain can point almost anywhere. A company might own a domain like: theircompany.com. But the actual website might be hosted on someone else's infrastructure.

Recently I worked on a feature that enables exactly this. The goal was to let clients use their own domain for websites hosted on our platform. So instead of visiting: saurav.dev/events/conf users could visit: theircompany.com

Here's how it all works.

Our platform lets event organizers create a complete website for their event. They can add agendas, speakers, registrations, and other event pages.

By default, every event gets a URL like:

saurav.dev/event/conf
saurav.dev/event/tech

It works fine, but the platform's brand is part of the URL.

Some clients don't want that. A large company hosting its annual conference would rather send attendees to something like:

theircompany.com

instead of a link containing someone else's brand.

This is called white-labeling a domain. That is the feature I built.

What sounded like a small task quickly turned into something much deeper. It involved DNS, domain verification, Cloudflare infrastructure, SSL certificates, and a few security concerns I had not thought about before.

---

What White-Labeling a Domain Actually Means

Let’s break it down.

When a client adds a custom domain, this is what happens:

1. A visitor types theircompany.com into their browser

2. The visitor lands on the same event website that we host

3. The URL shows the client’s domain, not saurav.dev

From the client’s perspective, it is purely a branding improvement.

From an engineering perspective, the situation is different.

Our server receives a request for a domain that we do not own. We must:

• Identify which event that domain belongs to

• Serve the correct event website

• Do this securely (since anyone who controls a domain can point it to any server).

---

How This Works Behind the Scenes

Before getting into the implementation, let's first see how this works.

DNS, or Domain Name System, is essentially the internet’s phone book.

When you type:

theircompany.com

your browser does not know where that is hosted. It asks a DNS resolver to translate the domain into an IP address as domains are easier for humans to remember, while computers use IP addresses to locate servers. Their are two types of IP addresses IPv4 and IPv6. IPv4 is bascially

Two DNS record types matter here.

A Record

Maps a domain directly to an IP address.

theircompany.com -> 192.455.1.1

CNAME Record

Maps a domain to another domain.

theircompany.com -> saurav.dev

That target domain eventually resolves to the real server IP.

For white-label domains, we ask clients to create a CNAME record that points their domain to our platform.

CNAME records are often used when one domain should resolve to another domain. For example, a company might configure www.company.com as a CNAME that points to company.com, so both domains resolve to the same infrastructure.

Sometimes companies also redirect old domains to new ones after a rebrand. For example, visiting fb.com redirects to facebook.com. In this case the redirect happens at the HTTP level after DNS resolution.

And when the client's domain points to our domain then this ensures that requests eventually reach our infrastructure.

Why CNAME Instead of an A Record?

Our infrastructure might change IP addresses over time, especially when using load balancers or Cloudflare.

If clients pointed directly to an IP address, they would need to update DNS every time the IP changes.

By using a CNAME that points to our domain, clients automatically follow our infrastructure changes.

---

The Verification Flow

The implementation happens in two phases.

Phase 1: DNS Check

When a client submits a hostname in the dashboard, we first verify that the DNS configuration is correct.

We check whether the domain actually points to our platform.

This is done with a DNS lookup using Ruby’s Dnsruby library.

resolver = Dnsruby::Resolver.new
response = resolver.query(domain, "CNAME")

domain_names = response.answer
  .select { |r| r.type == "CNAME" }
  .map(&:domainname)
  .map(&:to_s)

if domain_names.length == 1 && domain_names.first == "saurav.dev"
  @context.hostname_verification_status = "VERIFICATION_IN_PROGRESS"
  @context.save!
end

What this does:

1. Query the submitted domain for a CNAME record

2. Check whether it points to our platform domain

3. If it does, we mark the hostname as VERIFICATION_IN_PROGRESS

At this point the domain is not fully active yet. It has only passed the first step.

---

Phase 2: Registering the Domain with Cloudflare

Once DNS is confirmed, we register the hostname with Cloudflare using Cloudflare Custom Hostnames feature.

resp = CloudflareGateway.create_custom_hostname(@context.hostname)

if resp[:success]
  @context.hostname_verification_status = 'VERIFICATION_COMPLETE'
  @context.save!
end

Once Cloudflare accepts the hostname:

• The domain becomes fully verified

• Our platform can safely serve requests for that domain

• Once the hostname is registered, Cloudflare automatically generates an SSL certificate for the domain. SSL enables HTTPS by encrypting the connection between the user's browser and the server, ensuring that data sent over the internet remains secure.

The frontend only serves event pages when two conditions are true:

• hostname is set

• hostname is verified

Both checks must pass.

---

The Security Side of the Problem

While building this, one question kept coming up:

If anyone can point a CNAME to our server, what stops someone from abusing this?

This leads to domain takeover.

A domain takeover usually happens when:

1. A domain points to a service

2. The service is no longer configured for that domain

3. An attacker claims the unregistered hostname

If the system is not careful, the attacker can serve content on that domain.

Our system prevents this in a few ways.

1. DNS Verification

Clients must prove control of the domain by creating the CNAME record.

Only someone who controls the domain’s DNS settings can do this.

Typing a random domain into the dashboard is not enough.

---

2. Cloudflare Custom Hostnames

Cloudflare acts as the authoritative registry for allowed domains.

When we call:

create_custom_hostname

Cloudflare registers that hostname inside our Cloudflare zone.

If someone points a random domain to our servers but it is not registered with Cloudflare, the request never reaches our application.

---

3. Verified Hostname Check

Even inside our application, we add another safeguard.

Event pages are only served if:

hostname_verified == true

Unverified hostnames are ignored.

---

4. Automatic SSL

When a client adds a custom domain, Cloudflare automatically issues an SSL certificate for that domain. SSL enables HTTPS by encrypting the connection between the user's browser and the server, which protects data sent over the internet.

Once the domain is registered:

• Cloudflare issues an SSL certificate for the domain

• HTTPS starts working automatically

• Clients do not need to manage certificates themselves

So the client can simply use:

https://theircompany.com

---

And that’s what happens behind the scenes when you point a domain to someone else’s server.