I've got an either/or, but need both/and

I have a DNS conundrum. Most of my client’s site is hosted at dreamhost, however the blog is hosted at Google Blogger. I can get either one or the other integrated with Cloudflare, but not both. Without the 4 “A” records and 2 “CNAME” records I add at Googles direction, the blog page will not display. With these 6 DNS records added, the blog displays but all the dreamhost pages get 404 errors.

Other settings that may be having an impact on this are:

  • Suppressing www at Dreamhost
  • Flexible SSL through Cloudflare for the dreamhost pages, SSL through Blogger for the blog page
  • Suppressing HTPP through a Cloudflare Page Rule for dreamhost pages, and through Blogger for the blog page

The two relevant URLs are brockmanfamilyfarming.com and blog.brockmanfamilyfarming.com. Currently I have removed the six Blogger DNS records, so the rest of the pages are working, but not the blog.

To clarify:

You’re putting A records only for the naked domain and ‘www’ prefix, to dreamhost’s server IP - and one CNAME from blog.brockmanfamilyfarming.com towords Blogger’s CNAME that they gave you?

I count 2 A records and one CNAME. Where are the 2 other A’s and additional CNAME?

Just to make sure - be aware that the same hostname cannot simultaneously have a CNAME and any other record type at the same time (nor does it make sense when the two record types are CNAME and A).

Maybe it would be best if you just posted a screenshot of the DNS settings of the non-working setup…

Thanks for responding @shimi
Here are the DNS settings used when the blog works, and the rest of the site gets 404 errors.
Remove the circled additions I made, following Blogger support instructions on how to configure a custom domain with the subdomain name “blog”, and the dreamhost pages work and (of course) the blog page doesn’t. The 4 “A” settings are universal, as noted one of the CNAME items has the name of the subdomain, and the other CNAME name and value is unique to the blog.
All the uncircled DNS settings are listed as “non-editable” on Dreamhost’s c-panel.

What do you mean “Universal” ? is a Google’s IP, not Dreamhost. You have a 5th, censored line; Since I know how it works, I would assume that the line you censored ends with 9, right?

You’re not supposed to add Google/Blogger IPs for your main (naked) domain if what you expect on your naked domain is not a site hosted by Google/Blogger!

Can you remove the 4 redundant A records at the top, and leave the CNAMEs as is? Here’s what I get when I mimic this configuration locally on my machine:

By “universal” I meant that precise record is used to link any Blogger custom domain blog to a website.

What do you mean by “censored”? If you mean edited, I did not intentionally edit any line, and did not intentionally add any line other than the ones circled. Though looking at the 5th line, the “A” record with the naked site name, its IP address does end with 59, and that line is not one that is on the dreamhost non-editable list. So I don’t know how it got there and it sounds from your comments to be wrong. Perhaps deleting it would be part of a solution?

Your image shows the blog. At the same time you were able to access the blog, were you also able to access all the other pages? Am trying to diagnose this and if possible fix it without bringing down the rest of the site. I’ll be implementing the suggestions later in the evening to avoid potential disruption to users.

You ask if I can remove the 4 “A” records at the top, each of which has a slightly different number, so not completely redundant. They are currently removed, along with the two Blogger CNAMES, to keep the non-blog part of the site working.

I want to be sure of your recommendation. It sounds like I should restore the two CNAMES that are now removed. Should I also delete line 5? Then see if both blog and dreamhost site function? Or perhaps try three things:

  1. deletion of line 5 and inclusion of all six lines now circled (which may best match Google’s recommendation)
  2. deletion of line 5 and inclusion of only the 2 circled CNAMES
  3. forget about changing line 5 and include the 2 circled CNAMES as your last response suggests

By “censored” I meant redacted by a grey box.

I am not Google/Blogger, but I find it strange that they would give you IP addresses to point to. That’s very inflexible - what if they want to change IPs? They’ll have to have all their customers update, and need to manage that. It makes much more sense that they would give you a hostname to CNAME to (and they do, that’s your ghs.google.com which you did use for blog). Anyway, nevermind… it’s not relevant for us to solve the issue.

The whole first 4 are redundant not because they’re different from each other - they’re redundant because they’re on the naked domain - and they don’t point to the service the naked domain is supposed to provide - the site served from DreamHost’s servers. Maybe the word redundant is not the right choice, but I am not familiar with a better one to describe this.

Imagine that you’re in your car, and you’re driving to work. You punch your work address to the car’s navigation system, every morning, and you blindly follow the turn-by-turn instructions to get to work. Then, one day, you go to visit friends, and follow the same procedure - you punch in the friends’ address, and get there. But, from that point, when you go to work, you do something strange: 1 out of 5 of times, you punch in the work address as usual. At 4 of 5 times, you, from some reason, punch in the friends’ address, and expect your car to get you to work. But no matter what you do, when you get to your destination, the building looks different and you can’t find your boss there! So the 4 additional wrong destinations you’ve added for the “work” destination, how would you call them?

If it wasn’t clear at this point - in the above allegory - your work is your naked domain (and www), and you work at DreamHost. Whose address is the one ending with 59. Your friends’ house is the blog, co-located in your friends’ house, at Google/blogger.

When you added your friends’ address to the work address, the system did what you wanted: It sent the traffic destined to work - to your friends. Your boss, not surprisingly, was not there (and you got 404 errors). You did manage to get to your friends at blog.brock… because, well, that address was unique and correct.

As for line 5 - this is your work’s address - the site on DreamHost. How did it get there? It is there because the site was served by DreamHost, and always pointed to DreamHost’s servers. When you added your customers’ domain to Cloudflare, they automatically imported all DNS records from the old DNS server, so when you cut-off the DNS service to Cloudflare, things will continue to work normally. And they did. So, you DO NOT remove line 5. That’s the line that points the naked domain to DreamHost. If you look at the ‘www’ line, you’ll see it also points to the same IP.

If I am right, then the solution is as I mentioned above - delete the first redundant 4 records, as they’re causing the traffic to the naked domain to go to Google instead of DreamHost. Leave the CNAMEs that point blog.brock… as they are, and test. Sounds like your #3 (which doesn’t say anything about deleting lines 1-4 - which you still must do; though that if the site now works - they’re not there - so just don’t re-add them, as they were redundant to begin with).

Thanks so much for all of your help. Adding back the two “CNAME” records but not the 4 “A” records did the trick!


(I realize now that these are implementations that do not need to include content from outside Blogger.)

In any case, when adding the 4 static ids, the blog worked and it allowed me to add https and http suppression. But the rest of the site disappeared That’s when I started this thread.

I can’t see how adding those IPs helps with the SSL. The SSL cert is automatically sent for generation by Cloudflare the second your nameservers change to Cloudflare’s. (Though it can take a few hours before the cert is issued; That’s why you don’t try to enable HTTPS before the SSL/TLS app tells you that the certificate is active - and of course after it’s active, all relevant hosts in the DNS must have an orange cloud on them, so traffic will pass through Cloudflare’s servers and get their SSL certificate…).

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