DNSSEC Subdomains with Siteground


My CF account was setup originally via Siteground as a partner. But then I read an article asserting that DNSSEC was required to fully secure one’s domain. Siteground doesn’t offer DNSSEC, but Namecheap (my registrar) does.

I restructured my CF free account as follows:

following this post:

1 Deactivated my Cloudflare account via Siteground and deleted the website in CF.

2 Started over with my same CF account, pointing my Namecheap-registered domain to Cloudflare’s servers

3 added root domain to CF & enabled DNSSEC, following this tutorial: https://www.namecheap.com/support/knowledgebase/article.aspx/9722/2232/managing-dnssec-for-domains-pointed-to-custom-dns

CF automagically brought over (from Siteground?) several TXT files of acme-challenge, DKIM/domain key, and SPF/DMARC records for the main domain, but none for the subdomains.

I’ve tried adding the subdomains using A records, CNAME records, and combinations, none of which has worked.

I have searched the community, watched videos, and read all I can find about subdomain DNS records.

4 Latest configuration, I added DNS records for


It didn’t work (more below)

5 Checked my .htaccess file, removed allow,deny commands; removed force https; confirmed CF SSL is set to Full

6 Checked root domain according to this


The analysis at http://dnsviz.net/ matches the “Example without DNSSEC” in the linked post,** even though Cloudflare says “Success! smarterjoy.com iOS protected with DNSSEC”

This article says I must add DNSSEC to each subdomain:

But it appears this is impossible if registered at Namecheap & hosted at Siteground?

After spending 3 days trying to make this work, I found an article that argues against implementing DNSSEC in the first place:


Current Results:

Smarter Joy appears to work
courses subdomain redirects to root
pages subdomain - white screen of death
resources subdomain - white screen of death
tmfiles subdomain - “can’t provide a secure connection, uses an unsupported protocol”

I’ve also cleared my browser cache and flushed CF cache multiple times.

I am beyond frustrated. Should I go back to my original configuration? (DNS pointed to SG, add root & subdomains via the SG cPanel?).

Any insight or assistance would be appreciated.

1 Like

Your DNSSEC looks OK to me. If all your DNS records are in your Cloudflare account (i.e. you do not have NS records for subdomain.smarterjoy.com pointing to another DNS server) then I cannot see anything else you need to do with DNSSEC.

Cloudflare will attempt to scan for common DNS entries, but you need to verify manually that all the expected records were captured.

You currently have a Cloudflare firewall rule in place that makes it difficult to see why any of these are happening. can you temporarily remove any relevant firewall rules?

Some observations:

You have a DNS entry www.tmfiles.smarterjoy.com. With the normal Universal certificates you can only have one level under your domain. (www.example.com is OK, but staging.www.example.com is not). If you need to use www.tmfiles.smarterjoy.com you can purchase a dedicated or ACM certificate on the Edge Certificates tab of the dashboard.

The proxy status for ftp should be :grey:. Cloudflare do not proxy FTP in normal circumstances.

1 Like

Thanks, Michael, for your fast response!

I paused all the Firewall rules.
Also removed the DNS for www.tmfiles.smarterjoy.com
Changed the prox status for ftp to grey cloud

Looking forward to anything else you might say!
And I’m especially curious if anyone has an opinion one way or the other as to the value of DNSSEC. If it is important to have, is it important enough to move all content to the core domain and use subfolders instead of subdomains (assuming I’m correct in my conclusion that DNSSEC cannot be implemented on subdomains hosted at Siteground)?
I’m a newbie to all of this, except that I’ve been hacked a couple of times on other sites & hosts, so am a little paranoid about security. Just trying to get best practices implemented, but there seem to be many opinions about which practices are truly needed and I don’t have enough experience to know who to trust. :slight_smile:
Thanks again!

At some point in this part of the process, did you take a screenshot of all your DNS records?

Going down your list:

  • smarterjoy redirects to www and works.
  • courses redirects to root as you said. It’s a 302 redirect, so it’s a matter of tracking that down. Is ‘courses’ an add-on domain at your host?
  • pages attempts to load some CSS and images from www.pages, which is a no-go, as you’ve already discovered.
  • resources faces the same issue as ‘pages’.
  • tmfiles, you’ve already figured out…same ‘www’ problem.

So now we’re down to two issues:
1) ‘www’ for subdomains. You’ll need to comb through your site and edit any references to ‘www’ on that subdomain.
2) ‘courses’ redirects to root. Most likely at the server. Was ‘courses’ linked so something like Teachable?

DNSSEC is good because it authenticates queries for your domain to prevent any type of DNS hijacking of your domain.

Thanks very much for jumping in!

Well, not until today. I should have known better but I was so eager to get this done (foolish, I know).

  1. I haven’t been able to track down what I did to force ‘www’ for subdomains, and am thinking I might delete them and reinstall wordpress on them (I downloaded the crumbs of content already). Uncertain, because: I did this with the ‘Courses’ subdomain. It no longer redirects to root, and does not force ‘www’… but instead shows a 404 page from Siteground.
  2. CF DNS says my DNSSEC for SmarterJoy.com works, BUT it doesn’t appear to be true:
    When I analyzed it on dnsviz dot net, I got a png that clearly indicates “a working domain without DNSSEC”:

Notice, the example with correct DNSSEC all ends with “Cloudflare” in the bottom records:

I’ve followed the CF & Namecheap tutorials. Confirmed my DS record at Namecheap matches CF’s record. Purged caches and browsing history. Tried running the dnsviz analysis on Safari.

In case it matters, here are my current A & CNAME records:

I have three questions:

  1. What else can I try to make DNSSEC work properly on the root domain? Should I delete everything on the CF side and start over?
  2. Has anyone else successfully implemented DNSSEC on root & subdomains using Cloudflare, Namecheap and Siteground?
  3. Anyone care to recommend a hosting company that can implement DNSSEC? My SG contract expires in April, so I’m not totally opposed to switching.

Thanks very much for any insight.

Your DNSSEC looks good. Same as mine. And this “easier” test shows the same:

DNSSEC is generally Whole Domain, and does not connect down to subdomains. I admit that I don’t know what changes for subdomains that are delegated to different name servers from the root domain, but that is not applicable in your (or my) case.

As for the sites themselves, it would be worth the effort to dig in and fix the ‘www’ problem before resorting to rebuilding them. It’ll sharpen your skills. You can try a plugin that does a search and replace in your database. The following plugin is excellent, and I wouldn’t worry about the “not tested with recent versions” warning. It was updated 3 months ago, which is quite recent.

Courses is still a mystery. That one might be worth setting back to :grey: for itself and its www and get some semblance of a working site again, maybe with Siteground’s help.

Hosting has nothing to do with DNSSEC. It’s purely between the domain registrar (Namecheap) and your DNS provider (Cloudflare).

Now I’m confused…

Are you saying I shouldn’t worry about the dnsviz dot net analysis?

I’d like to dig in, but am unable to login to the backend. I’ve worked a tiny bit with phpmyadmin, but don’t know how to search tables for specific text. (I have used the Better Search Replace plugin and liked it very much, so thanks for confirming its usefulness and trustworthiness!).
It’s possible I set default ‘www’ with rewrite rules, so maybe I can reverse the rules to switch everything back? I will try that (after digging up my notes on what I did!).

There is no ‘www’ for Courses; I totally deleted the wordpress installation and files, then recreated it because it was basically an empty site anyway. Still, I tried :grey: and got this:

Which led me to this post:

Which reminded me to check my settings in Google Analytics. Sure enough, all subdomains were set with default ‘www’ in front. So I deleted the 'www’s for all subdomains, purged the CF cache, and cleared my browser cache.
After doing all that:
courses - still shows a Siteground 404 page
pages - still redirects to www.pages, and can’t be found
resources - redirects to www.resources and can’t be found
tmfiles - white screen of death.

Also, I renamed all the .htaccess files to .htaccess-old, in case there was something buggy in them, but I don’t know if that was a bad thing to do.

Any idea where I might learn how to do a manual search and replace in the databases?

DNSSEC is enabled for your domain. If something was wrong with it, your DNS wouldn’t work at all. But your site is reachable, so that’s a good sign.

You can’t log into wp-admin? That certainly puts you at a disadvantage. You may want to try this trick for setting the hostname via wp-config.php:

Courses is showing me a 404 right now. You really need to set it to :grey: until you get it working properly with HTTPS. If it’s set to :grey:, you’re more likely to get good help from Siteground without them blaming Cloudflare.

Yippee! Courses is working! I uninstalled WP a 2nd time, set it to :grey: then installed SSL on SG side. (I didn’t bother with this on the first reinstall because CF proxy will have full SSL, but apparently I needed SSL at SG first). It worked, so I took of the :grey: and it STILL WORKS! I’m so happy.

Thanks for this tip; I’ll tackle the other three in the morning. THANKS!!!

1 Like

Hooray! Changing the subdomains to remove ‘www’ via phpmyadmin fixed it! It did take a few minutes for changes to take effect; I purged the cache and cleared browsing data before everything worked.

Here’s a summary of what I plan to do for future installs, in case there are any other community members using Siteground & Namecheap:

1 Namecheap: register domain, set dns to Siteground

2 SG: create add-on domain & any related subdomains

3 SG: add Let’s Encrypt SSL for each one (wildcard SSL for the root domain so it will cover ‘www’)

4 SG: after SSL is in effect, install WordPress (install at www.rootdomain dot com and subdomain.rootdomain dot com, etc.)

5 SG: use .htaccess to force https (or you can use Siteground Optimizer plugin to do this)

6 Zoho: add email accounts for root domain (optional)

7 SG: access Advanced Zone Editor and screenshot current records

8 CF: add core domain, plus A records for subdomains & CNAME ‘www’ of core domain; copy ‘Digest’ field from DS Record (@DNS>DNSSEC); The proxy status for ftp should be :grey:. Cloudflare does not proxy FTP in normal circumstances.

9 Namecheap: reset DNS to Cloudflare, and enable DNSSEC (this is scary! but it does not change any files hosted at Siteground); configure w/Digest record (toggle other fields as shown in tutorial)

10 CF: after CF populates DNS records, manually add any that were not copied from Siteground.

11 CF: set SSL to Full

12 Confirm configuration with dnssec-analyzer dot verisignlabs dot com

Voila! Continue CF setup, and create your awesome websites!

Key Takeaways

1 “DNSSEC is good because it authenticates queries for your domain to prevent any type of DNS hijacking of your domain.” - @sdayman

2 Most of my subdomain trouble came from installing WP to ‘www’ subdomains, and setting ‘www’ versions as default in Google Analytics. Resetting GA, changing the site URLs via phpmyadmin, clearing browser cookies and purging the CF cache apparently fixed these issues.

3 When I tried to add a “fresh” unsecured subdomain CF integration only worked when I secured it first, i.e. started over with WP installed at https (hence, steps 3-5 above)

4 One DNS “zone” can include a root domain and subdomains. So CF changes to the root zone affect the subdomains too (firewall rules). I think this is true, but I don’t pretend to understand it all.

5 Confirm setup with dnssec-analyzer dot verisignlabs dot com

6 Or use “Dig” commands on the Mac terminal to confirm DNS, e.g.: “dig subdomain.mydomain dot com +short” should return Cloudflare IPs.

7 I will use the Better Search Replace plugin to remove ‘www’ references in all databases.

8 SG changes the hosting IP periodically, so if the site breaks you may need to reset A records in the CF DNS panel to SG’s new IP for your account.

Thanks, @sdayman and @michael, very much for helping me get this squared away. Y’all have been a HUGE help to this newbie! May your tribes increase!

1 Like

See? Super easy. :lying_face:

Key fact: do not “Force an HTTPS connection for this domain” - this may cause infinite loops - you will find a similar function on the Crypto page of your domain on CloudFlare

So please disregard Step 5 of summary.


Only if the site wasn’t properly set up for HTTPS in the first place.

Oh! That’s great to know! Thanks!

1 Like

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.