Yuto Takashi

Posted on Jan 18

Setting Up Custom Domains in Lovable: Subdomain Design & A+TXT Records

#dns #lovable #webdev

TL;DR

When setting up a custom domain in Lovable, you'll encounter A + TXT records instead of the usual CNAME. This post covers:

Subdomain design: tool.service vs service.tool
Why Lovable uses A+TXT records (not CNAME)
How DNS routing actually works behind the scenes
Why "looking things up" is a healthy engineering practice

The Setup

I recently configured a custom domain for a service I built with Lovable: https://car-sharing-vs-rental-car.tool.tielec.blog/

I already had tielec.blog running, so I wanted to set up a subdomain for this new tool. DNS setup isn't something I do every day, so I figured I'd double-check things as I went.

Turns out, that was a good call.

Subdomain Design: Getting the Hierarchy Right

First decision: subdomain structure.

Should it be:

tool.car-sharing-vs-rental-car.tielec.blog
car-sharing-vs-rental-car.tool.tielec.blog

What the Hierarchy Actually Means

At first, I was leaning toward the first option. But then I paused and thought about what it actually represents:

Pattern 1: tool.car-sharing-vs-rental-car.tielec.blog

tielec.blog
└─ car-sharing-vs-rental-car
    └─ tool

This means "tool inside car-sharing-vs-rental-car" — which is backwards.

Pattern 2: car-sharing-vs-rental-car.tool.tielec.blog

tielec.blog
└─ tool (category)
    └─ car-sharing-vs-rental-car (individual service)

This means "car-sharing-vs-rental-car inside the tool category" — which is what I actually wanted.

Why It Matters

The second structure makes it easier to scale:

tool.tielec.blog
├─ car-sharing-vs-rental-car
├─ cloud-cost-simulator
└─ pricing-compare

It's a small detail, but getting the hierarchy right from the start saves you from awkward migrations later.

Wait, A+TXT Records? Not CNAME?

Once I had the subdomain design figured out, I added the domain in Lovable.

I expected to see a CNAME record (like most hosting services), but instead, Lovable showed this:

RECORD TYPE	HOST NAME	VALUE
A	`car-sharing-vs-rental-car.tool`	`185.158.xxx.xxx`
TXT	`_lovable_verify.car-sharing-vs-rental-car.tool`	`lovable_verify=xxxxxxxx...`

Wait, A record instead of CNAME?

I know how to set it up, but I was curious: why not CNAME?

How DNS Routing Works in Lovable

Here's what I learned.

Does Each Service Get Its Own IP?

At first, I wondered: does Lovable assign a unique IP address to each service?

Short answer: No.

Multiple services share the same IP address (the Lovable edge/CDN).

car-sharing-vs-rental-car.tool.tielec.blog
            ↓
      185.158.xxx.xxx   ← Lovable's edge (shared)
            ↓
   Routing via HTTP Host header / TLS SNI
            ↓
     Your specific project

DNS just points to the entry point. The actual routing to the correct project happens via:

HTTP Host header
TLS SNI (Server Name Indication)

This is the same approach used by Cloudflare, Vercel, and Netlify. If every service needed its own IP, we'd run out of IPv4 addresses pretty quickly.

Why A+TXT Instead of CNAME?

A few reasons:

Root domain support

CNAME doesn't work on root domains (example.com). A records do.
Flexibility

A records don't conflict with certain DNS setups (like CNAME flattening).
Domain ownership verification

The TXT record proves you own the domain, preventing someone else from hijacking it.

The Actual Setup Process

Here's how I configured it (using Onamae.com, but the process is similar for other DNS providers).

Step 1: Add Domain in Lovable

In your Lovable project settings, add the custom domain. You'll see the A and TXT record values.

Step 2: Configure DNS Records

A Record

Type: A
Host: car-sharing-vs-rental-car.tool (don't include .tielec.blog)
Value: The IP address Lovable provides (e.g., 185.158.xxx.xxx)

TXT Record

Type: TXT
Host: _lovable_verify.car-sharing-vs-rental-car.tool
Value: The verification string (e.g., lovable_verify=xxxxxxxx...)

Important: The TXT value must match exactly. Copy-paste carefully.

Step 3: Wait for DNS Propagation

DNS changes can take anywhere from a few minutes to a few hours (sometimes up to 48 hours).

You can check propagation with:

# Check A record
dig car-sharing-vs-rental-car.tool.tielec.blog

# Check TXT record
dig TXT _lovable_verify.car-sharing-vs-rental-car.tool.tielec.blog

Step 4: Verify in Lovable

Once DNS has propagated, click "Verify" in Lovable. If everything's correct, HTTPS will be enabled automatically.

On Looking Things Up

Here's something I've been thinking about.

I've been an engineer for over 10 years (testing → infrastructure → SRE lead → HR → startup founder). But I still look things up when doing tasks like this.

For a moment, I wondered: Am I lacking skills?

But then I realized: No, this is completely normal.

Why It's Okay to Look Things Up

Technology keeps changing

DNS setup 10 years ago isn't quite the same as DNS setup today. Every hosting service has its own quirks.
You forget things you don't use often

I do DNS configuration maybe a few times a year. Of course I don't remember every detail.
"Knowing but not checking" is riskier

Having experience can trick you into thinking "I know this already." Taking a moment to double-check is actually the safer approach.

Looking Things Up Is a Healthy Practice

"Looking things up while working" isn't a sign of skill gaps — it's a sign of good engineering habits.

Taking the time to verify assumptions helps you:

Catch mistakes before they happen
Deepen your understanding
Stay current with how things actually work today

I almost went with tool.car-sharing-vs-rental-car instead of car-sharing-vs-rental-car.tool. If I hadn't paused to double-check, I would've had to redo the setup later.

Pausing to ask "Wait, is this right?" is valuable.

Takeaways

Here's what I learned from this experience:

Subdomain design matters: Think about hierarchy (role → individual service)
DNS is just the entry point: Routing happens via Host header / SNI
TXT records prevent hijacking: They verify domain ownership
Looking things up is healthy: Don't let experience trick you into skipping verification

If you're working with Lovable (or any hosting service), take a moment to understand the design decisions behind your subdomain structure. It'll save you headaches down the road.

I write more about engineering decisions and reflection processes at:

https://tielec.blog/

DEV Community