What a Website’s DNS Records Reveal About Who Built It

A website can hide almost everything in its page: the badge, the generator tag, the credit line. What it can't hide is where it lives. To put a site on a custom domain, the owner has to point that domain at a host, and the host decides what those records look like. Anyone can look them up. Sometimes the answer names an AI builder outright. More often it names a general-purpose host, and then it proves nothing about AI at all. This post explains how to tell the two apart.

Three record types worth knowing

• A points a name at an IP address. For a root domain (example.com), it's usually the only option, so builders give customers a fixed address to use.
• CNAME points a name at another name, such as www.example.com → something.host.com. Because the target is a readable name, CNAMEs are the most informative records of all.
• TXT holds free text. Services use it to confirm you own a domain, and many ask you to leave the record in place permanently.

How to look them up

Any free online DNS lookup tool works. If you have a terminal, dig is faster (on Windows, nslookup -type=A example.com does the same job):

dig +short A example.com
dig +short CNAME www.example.com
dig +short TXT example.com

Check both the root domain and the www version. Owners often set them up differently, and the www CNAME is frequently the more revealing of the two.

The records we've verified

We only list values we confirmed in the platform's own documentation or by looking up real sites in November 2026. Hosts change their addresses from time to time, so treat this as a snapshot, not a permanent list.

• Lovable (custom domain) · A

  185.158.133.1

  Specific to Lovable

  Every Lovable custom domain we looked up that wasn’t behind a proxy

• Lovable (its own subdomains) · A

  185.41.148.x

  Specific to Lovable

  Address block registered to Lovable

• Base44 · CNAME

  base44.onrender.com

  Specific to Base44

  Base44 docs, and Base44 apps we looked up

• Bolt.new · CNAME / ALIAS

  site-dns.bolt.host

  Specific to Bolt.new

  Bolt’s domain setup guide

• Replit · TXT

  replit-verify=…

  Specific to Replit

  Replit docs: the record must stay for certificate renewal

• Shopify · A / CNAME

  23.227.38.65 / shops.myshopify.com

  A store platform, not AI

  Shopify help center

• Vercel · A

  76.76.21.21

  General-purpose host

  Vercel docs

• Netlify · A / ALIAS

  75.2.60.5 / apex-loadbalancer.netlify.com

  General-purpose host

  Netlify docs

• Render · A

  216.24.57.1

  General-purpose host

  Base44’s docs list it for root domains, but it’s Render’s shared address

The trap: shared addresses

Some builders document two ways to connect a domain: a CNAME to a name of their own, and an A record for root domains that points at the company actually running their servers. Base44's root-domain address belongs to Render, and one of Bolt's documented addresses belongs to Netlify. Both serve thousands of sites that have nothing to do with AI. Finding one of those addresses tells you the host, not the builder. That's why our detector matches only values a single builder uses, and ignores the rest.

The same applies to Vercel and Netlify themselves. Many AI-built apps are deployed there, and so are many hand-built ones. We give those hosts a small weight in the score, never a verdict.

When DNS shows nothing useful

If the A records come back as Cloudflare addresses (they usually start with 104. or 172.6), the site sits behind Cloudflare's proxy, which hides the real host. Two of the seven Lovable custom domains we checked were set up this way, even though Lovable recommends turning the proxy off. In those cases, the page itself and its JavaScript are the place to look. The same goes for an app exported from a builder and deployed somewhere else: DNS will show the new host, not the tool that generated the code.

TXT records: a list of the site's tools

Even when TXT records say nothing about the builder, they often list the services a business uses, because each one asks for its own verification record. Common examples:

• google-site-verification=…: the site is registered in Google Search Console.
• facebook-domain-verification=…: the domain is verified for Meta business tools.
• v=spf1 include:_spf.google.com: email runs on Google Workspace (include:spf.protection.outlook.com means Microsoft 365).

None of these say anything about AI. They're still useful context: a domain with no mail records and no verifications at all is often a quick side project, while a long list usually means a business that has been running for a while.

What DNS can and can't prove

DNS tells you where a site is hosted today. When the host is an AI builder's own platform, that's strong evidence the site was made there, and it stays visible even after the badge is removed. When the host is a general-purpose cloud, it's neutral. And it can never tell you how much of the site a person wrote or edited afterwards.

Since November 2026, every scan on our AI website detector looks up a site's A, CNAME and TXT records alongside its page and JavaScript files, and shows the exact record when one matches. The methodology covers how it's weighted, and the 10-check guide shows where DNS fits among the other checks.