Issues with DNSSEC has shutdown my website - again

This is a follow-up to an earlier post about issues with implementing DNSSEC that was discussed in this forum https://community.cloudflare.com/t/could-cancelling-a-dnssec-request-cause-me-to-be-locked-out/337807 Through that post SDAYMAN got me on the right track in implementing DNSSEC.

After doing a backup restore on my WordPress site ( https://mikeschaffnerphotography.comyesterday I got it operational again back to the initial status. Specifically, DNSSEC was shown as enabled on my hosting provider, Blue Host (BH) but not on Cloudflare (CF). The site was operational and accessible but truly not on DNSSEC as verified by 3 sources: https://dnssec-analyzer.verisignlabs.com/ , https://gf.dev/dnssec-test and https://dnsviz.net/ After reloading the cache by viewing the various pages all remained accessible overnight (12 plus hours).

As the site seemed stable, I re-tried enabling DNSSEC on CF. I hit the enable button on CF got the necessary information and updated the DS records and added them to the Blue Host settings.

A few moments later, CF indicated that DNSSEC was successfully enabled. I also verified on the 3 sites noted above. All showed as now having DNSSEC enabled.

For a period of about 2 hours after doing this the site remained up, stable and fully accessible. Sometime between 2 and 5 hours after enabling DNSSEC the site became completely inaccessible. This was both the site itself and the WordPress admin dashboard.

At this point, I disabled DNSSEC on CF and removed the DS record from the DS settings on BH. CF indicated that DNSSEC was not enabled as did the 3 verification sites.

After disabling DNSSEC I waited over 6.5 hours before taking action. My thoughts were this might be all caused by DNS propagation issues and I wanted to give sufficient time.

I did a restore from backup, cleared the cache on BH and CF. When clearing the cache on BH I saw a notice that said “Please redirect your DNS mikeschaffnerphotography.com A records are not pointing to Bluehost. To fix this, please log in to the DNS provider associated with this domain. Then redirect your A record to point to Bluehost IP: xxx.xxx.xxx.xx” However, the IP address matches the A record on CF.

Is DNS propagation the cause for the delayed effect?

What would cause BH to believe that A record on CF is pointing to them when it really is?

Other CF setting that may or may not come into play are:

  • Full (strict) SSL/TLS
  • Always us HTTPS
  • HSTS enabled
  • Minimum TLS 1.2
  • Opportunistic encryption enabled
  • TLS 1.3 enables
  • Automatic HTTPS Rewrites enabled

At this point my site is still down and inaccessible. Any ideas on how to get it back and what I may have done incorrectly in establishing DNSSEC? Thanks for your help.

Mike

It looks like your registrar is not setting the correct DS records for your domain. At this point, I suggest you leave it off for a while. Cloudflare has no control over this since the Cloudflare end has remained consistent.

Thanks, I will try leaving it overnight again. If they are not setting the correct DS records how would it pass verification that DNSSEC was successfully enabled? Thanks again for your help.
Mike

I suspect it’s reverting to incorrect values. You’d have to keep an eye on those DNSSEC tests to confirm it was properly set, then see when it goes bad.

At this point once I get the site back I’d be very hesitant to retry DNSSEC since there is a fair amount of downtime to recover. Just a bit snake-bit at this point.

You’d have to ask Bluehost what’s going on. They might think they’re DNS for your domain and have some DNSSEC reset process going on.

1 Like

Their site shows that the name servers are Cloudflare’s and specifically states " Notice Your site is using DNS settings that are not connected to Bluehost."

But it can’t hurt to ask. I’ll contact them and ask. Hopefully, I’ll get someone that knows what they’re doing. Wish me luck.

1 Like

Okay, chatted with BlueHost.
He had me disable DNSSEC on BH side. My site became available. What I can’t figure out is that originally before I started any thing DNSSEC was enabled on BH side, disabled on CF side and my site worked fine. When I reset to the original config site would not come up. Now has to be disabled on both BH and CF which seems logical but it is different than what worked before.
He walked me through the process of enabling DNSSEC which is exactly as I did before and as before DNSSEC was enabled and verified by all test sites and CF.
It’s now about midnight so going to bed soon - the big question is will the site be up in the morning or not. Last time I went through this exact process it went down a few hours later.
Guess we’ll see in the morning. Will report back on the status then.
Mike

1 Like

Okay, it has now been 7.5 hours since following Bluehost’s support instruction that brought the site back up and DNSSEC was re-tried and the site is down again.

CF and all 3 verification sites show DNSSEC as still up and working. However, the site is down.

To recap from last night

The starting point:
- Site was down
- DNSSEC was disabled on CF
- DNSSEC was enabled on BH but the custom DS record from CF was deleted
(Note: the DNSSEC setting mismatched as they are were what I had for nearly a year with the site running ok).

Instructions for BH
- Switch the DNSSEC on BH to disabled
- Site came up

Re-try DNSSEC
- went through the process again
- enabled on CF
- enabled and entered custom DS record on BH
- site was up
- verification sites confirmed DNSSEC is enabled

7.5 hours later
- site is down
- verification sites confirmed DNSSEC is still enabled

Verisign says there are four DS records: three that aren’t Cloudflare, and one that is. My sites have only one. The Cloudflare one.

I’m no DNSSEC expert, but if there are conflicting DS records, it wouldn’t surprise me if this would cause some problems.

There’s nothing else we can assist with at this end. It’s purely a Bluehost issue they need to figure out.

1 Like

On chat with BH now.

I can add/delete new DS records but can’t delete/change the original 3 of BH

I’m asking them about SSL/TLS setting - I was on Full (strict) to confirm this was right
They had me switch to flexible but so far no effect

That has nothing to do with DNS and is a terrible idea for them to suggest. It opens a security hole for your site.

That’s no good, and I don’t know why they’d force that. Again, I’m no DNSSEC expert, but I can’t imagine that’s without issues.

Maybe another @MVP knows DNS and DNSSEC well enough and can say if multiple DS records are problematic.

2 Likes

As mentioned by @sdayman it leaves a security hole open for your site! It’s basically like digging a big hole in the ground, then not covering it! Sooner or later, you’ll fall through the hole! The same thing applies for your website, the flexible option is basicly the “hole” in the ground! If that’s too confusing, here’s a document below explaining on why you should choose Full (Strict), and only Full (Strict)

1 Like

But you have had or not, an DS and DNSKEY recrod at the DNS tab of Cloudflare dashboard? - I doubt you had it added (given from Bluehost).

Usually, the process is to enable DNSSEC at Cloudflare and provide all the needed information to your domain registrar.

I remember for one.eu TLD domain which have had bit “misconfigured” KSK <-> ZSK, but worked fine for few months.
Later on, DNSSEC got broken and I just had to disable it at Cloudflare dashboard.
The TLD registrar was a bit strange, due not accepting Algorithm 13 so they somehow managed to found a temporary workaround.

Does BlueHost interface have got some DNS management, or rather some DNSSEC option “enable/disable”?

Maybe you are trying to enable DNSSEC on a hosting interface, rather than the domain interface?
Which would mean, you might get DNSSEC enabled for hosting and somehow in between you are given the DS records which become active? and would somehow appear on your domain interface? - as the BlueHost is your web hosting provider and also your domain name registrar, correct?
In that case, you might want to add those records to the DNS tab of Cloudflare.

Again, I doubt this would work. And I would not advise you to do it that way.

I am sorry to hear this suggestion, but that’s really not a way to go with the SSL:

Currently I see:
No DS records found for mikeschaffnerphotography.com in the com zone

Which brings me tu guess scenarios:

  1. DNSSEC disabled at Cloudflare dashboard, but no DS record at domain interface of BlueHost
  2. DNSSEC enabled at Cloudflare dashboard, but no DS record at domain interface of Bluehost
  3. DNSSEC enabled at Cloudflare dashboard, DS record added, but not yet propagated

UPDATE: Isn’t your domain name registrar fastdomain.com rather than Bluehost?

Kindly, may I suggest looking into the similar topic from below, as the OP had issues with DNSSEC at BlueHost and help from their “support” was doing a bit wrong steps for their customer:

A post was merged into an existing topic: Page cache

Sorry for not responding sooner - I had to step out for a little while.

Before I left I did the following

  • reset SSL/TLS to Full (strict) “flexible” didn’t seem right and I appreciate everyone’s confirmation that Full(strict) is the one I need.
  • they wanted me to change the A record with the domain name to @ instead of the domain name. I tried that on CF and it would not accept it, so it remains with the domain name in the A record
  • I disabled DNSSEC on BH and CF
  • after all of that the site is back up and accessible but without DNSSEC

@fritex on the BlueHost site they show themselves as registrar. WHOIS indicates FastDomain Inc. is the registrar. All my dealings have been with only Bluehost including domain renewal. I don’t have access or an account with Fast Domain and they want money to establish one. It appears that everything has to be done through Bluehost

BH does have DNSSEC option to enable/disable which is what I’ve been using. There are only 3 options. Here is a screen shot

I leave the first 2 options DNSKEY and NSEC as shown and add a DS record using the information from CF.

It is interesting to not that the form shows " *No current DS records" However, when I enter the info from CF and enable there are 4 DS records. I only have the ability to add a new one or delete the one I created with the CF info - I can’t do anything with the other 3.

The issue @fritex referenced is exactly what I’m experiencing (I’m also on Comcast). However, I did test it when DNSSEC was enabled at my daughter’s house with different computer and internet provider and the site was down.

Is it correct I should only have 1 DS record and not 4?

Okay, thank you for feedback information.

Yes.

From the screenshot above, from what I do understand and as far as I see:

  1. I would you not click the button enable under the “DNSSEC Status” section, as I believe it would generate it’s own DS records (as it states) from hosting and add them to your domain on BlueHost, despite the Cloudflare - here is the trick I think.

  2. DS Records section is empty - okay, for now.

  3. Under Add Custom DS Records section:
    You only make sure Add Custom DS Records - here you enter the values from Cloudflare dashboard - > at Cloudflare dashboard you click “Enable DNSSEC” and wait for few secs, then you got Key Tag, Algorithm, Digest Type and Digest which you enter in the fields from above screenshots and verify the DS Record is having that one (from Cloudflare).

@fritex Yes that is what I’ve been doing. Once I get the Key Tag, Algorithm, Digest Type and Digest info from Cloudflare I enter it in the boxes shown in the screenshot then hit enable. Shortly after CF says DNSSEC is enabled as do verification sites such as Verisign. At that point everything works fine for a while but after a few hours my site is not reachable. If at that point I disable DNSSEC at both BH and CF the site becomes accessible again (but without DNSSEC)

At Bluehost interface? - do not.

Only “Add” after you enter the values, so they become present and shown later at the Bluehost interface under “DS records”.
Cloudflare then can verify if they exist and they should be okay.