Damn CNAME

Today on "Things I learned", I get reacquainted with CNAMEs and how they, when they want to, will 'eff up your DNS records.

A client engaged me for a "quick" domain warming for a rebranding. After review, this wasn't really a warming. The volume was too low. For me, the most important thing was making sure they were technically set up to be successful: authentication, working DNS, working mailboxes, etc. etc. etc.

Yes, they had to be mindful of alerting their customers of their new domain in their email program, properly routing their current site to the new site and educating customers there as well. But most of their customers were already aware of the rebranding through direct 1:1 communications.

The task was simple, get the domain setup, make sure it sits for an appropriate amount of time (minimum 30 days) without email activity, set up the website, get the right DNS records added, test, and make sure it all works. I started with their corporate mail and, naturally, the fun/easy/quick review turned into much more than an "in-and-out" engagement.

On to my checks (many more were done, but no need to bore you with everything)...

• Domain set up ✅
• Domain rested ✅
• Domain authentication used branded SPF ✅
• Domain authentication used branded DKIM ⚠
• Domain published DMARC ✅
• TLS enabled ✅

Ok DKIM is easy. I got this in the bag! Fastest consult EVER.

I sent over O365 instructions to generate DKIM for their 1:1 corporate mail and that DKIM key went off to the DNS team for DNS publication. 

Side note: O365 requests two CNAMES be set up for DKIM (likely for DKIM key rotation when the mood strikes O365 to initiate a swap-er-oo). However, during the checks only one CNAME has a value, the other is more of a placeholder. That internally gave me a twitch because it's just sitting there...blank.

Anywho, back to CNAMEs...I swear I'll get there.

DKIM was set up. I had asked the client to meet when all was done so we could test and finalize everything. I never received a reply to my inbox so when my calendar suddenly had an invite, it caught me off guard.

I join the meeting and we start talking about the outstanding items I had for them. There was almost a look of annoyance. Rude much? 

Perhaps though it wasn't undeserved. 

Turns out they had done the items I sent over. They did update DKIM and they did reach out asking for a meeting. Instead of waiting on my confirmation, they put one on the calendar (the invite that caught me off guard) because they were on a time crunch.

As we were talking I took a peek into my spam folder and there were their communications. staring at me, "unread" and brimming with information. I never "received" them because I never checked my spam folder. Why would I? Our emails have been unhindered so far, literally just earlier that day in the wee hours of the morning.

It didn't take long to see why they were there. Newish domain and no authentication. However, I checked and they had SPF. I made a note of it. I sent them feedback that only DKIM was needed.

Where did the SPF go?

Through the conversation, we discussed the changes made. DKIM wasn't the only one. It seemed unrelated, but their website went live just before they emailed me all those lovely emails with their updates.

I began querying the DNS to find the where the SPF records went. I kept getting a CNAME result and occasionally getting the SPF. It wasn't until I was connected with their DNS team and saw the overall DNS entries did I see a CNAME record in it's full glory pointing to the Word Press web hosting site. I then began comparing the DNS from the day before to see what else may have changed.

Email and web most often operate independently. Changes to the DNS for email can be done without impact to the site and vice-versa. However, in this case, by followed the instructions from their web host as is, they inadvertently interfered with the necessary DNS records for email. I would love to say "How could you not think of email?" But it's easy, it's not their job to think of email. They are thinking of their site.

The directions given told them to post a CNAME to their apex domain to make any future IP swaps by the provider seamless. Ages ago, I had a discussion with the DNS lead at my old job. He taught me lots of things about the DNS and one was that CNAMEs should NEVER go on the apex domain - issues would abound if you did.

Issues like messing with DNS queries. Essentially a CNAME tells the DNS resolver to go look somewhere else for the DNS records. The problem is a CNAME cannot bring the NS or SOA record with it. It's existence on the apex domain creates conflict within the resolvers. It's like coming to an intersection of Main St. and Main St. Which way to you go?

This is likely why (besides some caching) I kept getting sporadic results where SPF was showing and then it wasn't.

Ok, so problem identified. Solution time! We removed the CNAME on the apex domain and instead manually entering the IP into the A record.

By the time I got to the marketing stream for review, the rest was easy, peasy. However, those urgent few hours of "Where the H did the entries go?" still got me shaking my head with the haiku ending in "It's always DNS." seeping from my lips in disdain.

DAMN CNAMES