DNS brain teaser for your engineering brain

I just spent a few weeks wrestling with a domain issue that could have been solved in a couple of hours max (not a literal few weeks, but half an hour here and an hour there over a few weeks). Let me walk you through what happened and the technical details I learned along the way about DNS and domains.

For context, I was trying to connect a subdomain of my primary domain (richstone.io) to my ClickFunnels account. I already have this blog here that you can navigate to with richstone.io and I wanted devs.richstone.io to point to ClickFunnels, which I currently basically use like TypeForm and sometimes like a Stripe Checkout.

The setup required verifying certain TXT records, and this is where things got strange: some TXT records were verifying just fine, while others stubbornly refused to work.

In my Namecheap dashboard, I could see all the records clearly but ClickFunnels wasn't cool with them at all:

• Google verification TXT records ✓
• ClickFunnels verification records ❌
• Some additional mail TXT records ❌

The user mindset combined with engineering pre-assumptions

Here's where I went wrong. Instead of just thinking like an engineer, I got stuck in what I call the "user mindset."

To my engineering brain, a TXT record was a TXT record and should always be visible when the DNS registrar is queried. But when it comes to DNS, nothing is as it seems. 🔮

So I kept being a user and tried to make the system right:

1. Deleting and re-adding the same TXT records
2. Double-checking my entries for typos
3. Waiting longer for "propagation"
4. Wondering if it's a ClickFunnels verification issue
5. Talking to others about it (looking at you fellow "engineers"! 🫵)
6. Removing and re-adding the subdomain
7. Trying it with a new subdomain

I literally did this dance for weeks. I'm such a "user"! :/

The one command

Now that I was out of options, heavy weaponry was taken out. Luckily, I have access to the ClickFunnels codebase. So I started digging into the source code. After like 10 minutes of looking, it became clear to me that ClickFunnels is just looking at the public domain registrar that anyone can lookup. I knew immediately that salvation was near.

I've asked the LLM gods for a terminal command to look up DNS records and dug out dig TXT richstone.io

▶ dig TXT richstone.io

; <<>> DiG 9.10.6 <<>> TXT richstone.io
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 10487
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;richstone.io.                  IN      TXT

;; ANSWER SECTION:
richstone.io.           1799    IN      TXT     "google-site-verification=FCyHG3GsXOhByyGS_uEpWNSFQyMOXQVIXrL9ujdrKeE"

;; Query time: 46 msec
;; SERVER: 1.1.1.1#53(1.1.1.1)
;; WHEN: Sun Mar 23 17:49:10 CET 2025
;; MSG SIZE  rcvd: 252

The TXT records I tried to add weren't visible in the DNS registrar. So, I had enough material for a chat with the Namecheap support. Which was pretty stellar, by the way:

The Technical Culprit: CNAME Record Priority

When I finally connected with Namecheap support, they identified the issue. According to their support.

I had a CNAME record for my bare domain (using the @ symbol) pointing to the server where richstone.io is hosted. According to Namecheap CNAME records have the highest priority in the DNS hierarchy and will suppress other records for the same hostname.

So even though I was adding the TXT records correctly in Namecheap, they were essentially being overridden by the CNAME record at the public DNS level.

The support agent explained something fascinating about DNS priority:

"The CNAME has the highest priority and suppresses all other records (like TXT record, MX record etc) for the host @. That is why your TXT record is not working for the host @." - 🤯

I still only half-believe it, because he wasn't able to explain why then I was still seeing the google-verification TXT record. But whatever, the solution below worked.

The Solution: CNAME → ALIAS

Instead of using a CNAME record for the bare domain, I was told to use an ALIAS record:

ALIAS @ richstone.serveriorelwham.com

The key difference is that ALIAS records don't suppress other record types. As the support agent explained:

"The main difference between CNAME and ALIAS records is that the ALIAS record does not suppress A, MX, TXT, CAA records for the same host, unlike the CNAME record."

Maybe this is specific to Namecheap, maybe not. But right after doing that, the weeks of userness were gone:

▶ dig TXT richstone.io

; <<>> DiG 9.10.6 <<>> TXT richstone.io
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 26277
;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;richstone.io.                  IN      TXT

;; ANSWER SECTION:
richstone.io.           1799    IN      TXT     "clickfunnels-domain-verification=jWMWXZ"
richstone.io.           1799    IN      TXT     "google-site-verification=FCyHG3GsXOhByyGS_uEpWNSFQyMOXQVIXrL9ujdrKeE"
richstone.io.           1799    IN      TXT     "v=spf1 include:mailgun.org include:mailer.myclickfunnels.com ~all"

;; Query time: 40 msec
;; SERVER: 1.1.1.1#53(1.1.1.1)
;; WHEN: Sun Mar 23 18:21:13 CET 2025
;; MSG SIZE  rcvd: 252

Technical lessons for fellow domain managers

1. Understand DNS record hierarchy - CNAME records at the root domain suppress all other records (apparently).
2. Use ALIAS records for root domains when you need other record types to work simultaneously.
3. Always verify public DNS status with tools like dig rather than trusting what you see in your registrar dashboard (!)

All the fish

The next time you're facing a technical issue that seems inexplicably difficult, try running some diagnostic commands first. Five minutes of engineering thinking can save weeks of user-level frustration.

P.S.: I love "users", I'd just prefer not be one when I could have avoided that.