DNS record seem to not being propagated properly

I have done the standard fare.

  • In my registrar dash panel, I changed my nameserver to the one Cloudflare has provided to me.
  • Waited a few minutes, then from my Cloudflare panel see “Congratulations…”.
  • Remove and double check all the records. I remove all but two. An “A” record that I set to my Linode server IP, and a “CNAME” for “www” that points to the “A” record. Both are proxied.

It has been a couple hours now, and is I do a ping/traceroute on the domain is comes back with the previous provider’s IP.

The thing is I did the same thing yesterday with another domain and is currently running perfectly. It was done from start to finish less than 5 mins. Today no so luck.

Any suggestions or explanations would be appreciated.

Thank you kindly.

What’s the domain?

1 Like

the one that works is “s-o-n.info” and the one that doesn’t “s-o-network.com

When I open it, I got Cloudflare 525 error. Obviously, Cloudflare tries to connect to your host/origin over HTTPS, but either you do not have a compatible port open at your host/origin server, or do not have an SSL certificate installed for your domain (including sub-domain(s) if so), and possible maybe the Cloudflare is not allowed to connect neither to the host/origin (the Cloudflare IP addresses are not being allowed to connect), all that while the SSL option could be set to Full SSL at your Cloudflare dashboard.

Due to 525 error, may I ask if you have re-checked with the steps as written on the below article?:

The “network” one is showing Cloudflare IP addresses. Other than the IP address, are you noticing anything about the site itself? @fritexvz just tested it and got an error.

well niether has SSL, yet so not sure why that would be an issue

So are you saying I need to setup SSL to get to fix the issue, because I am the DNS setup first so I can setup LetsEncrypt. So that I don’t get too manly failed attempts.

“Manly” ??? Freudian slip ??? I guess

If you do not have an SSL certificate installed at your host/origin, it shows up this error due to having Full SSL option selected at Cloudflare.

More information how Cloudflare works can be found at the below article:

Yes, correct.

Could you try following the steps from below to generate an Let’s Encrypt SSL certificate for your domain (and sub-domains like www, etc.), either using acme.sh or Certbot or some other way on your host/origin server?:

  1. To generate or renew your Let’s Encrypt SSL certificate while using Cloudflare, you can temporarly switch the A www and A yourdomain.com records from :orange: to :grey: cloud at Cloudflare dashboard for your domain (or a CNAME record if you have one).
  2. Wait for few minutes for changes to apply.
  3. Start the generation or the renewing process for your Let’s Encrypt SSL certificate at your host/origin (having :grey: temporarly it should resolve to your host/origin IP address and you should be able to generate or renew it via DNS/TXT/web host method).
  4. After a successfull generation or renewing process, switch back from the temporarly :grey: cloud to :orange: cloud to make sure your Website is proxied via Cloudflare.
  5. Make sure you have selected the Full SSL or Full SSL (Strict) option at Cloudflare.

True, s-o-n.info resolves and opens up correctly from my end.

Okay, now when I just tested, it throwed me redirection errors, and got back to HTTP (was on HTTPS when I tested it few minutes ago).

Moreover, do you have Always use HTTPS and Automatic HTTPS redirection options both enabled at Cloudflare dashboard under SSL settings (tab)?

In case if you would get some redirection loops, check here:

And hopefully, you do not have Flexbile SSL option enabled as well?

Sorry about I playing around with it.

1 Like

s-o-n.info was set to “Flex” under SSL
where are s-o-network.com was set to “Full”.

So I set both to none for now, to see if I could get both to work, then I was going to start playing with SSL tut you linked.

And for the record, I did not play with anything in SSL tab, or any tab for that matter, until just now.

1 Like

So I don’t know what to tell you at this point

curl -svo /dev/null https://www.s-o-network.com --connect-to :: 2>&1 | egrep -v "^{.*$|^}.*$|^* http.*$"

* Connecting to hostname:
*   Trying
* Connected to ( port 443 (#0)
* ALPN, offering h2
* successfully set certificate verify locations:
*   CAfile: /etc/ssl/certs/ca-certificates.crt
  CApath: /etc/ssl/certs
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* TLSv1.3 (IN), TLS handshake, Server hello (2):
* TLSv1.3 (IN), TLS handshake, Encrypted Extensions (8):
* TLSv1.3 (IN), TLS handshake, Certificate (11):
* TLSv1.3 (IN), TLS handshake, CERT verify (15):
* TLSv1.3 (IN), TLS handshake, Finished (20):
* TLSv1.3 (OUT), TLS change cipher, Change cipher spec (1):
* TLSv1.3 (OUT), TLS handshake, Finished (20):
* SSL connection using TLSv1.3 / TLS_AES_256_GCM_SHA384
* ALPN, server accepted to use h2
* Server certificate:
*  subject: CN=autodiscover.s-o-network.com
*  start date: Feb 13 11:37:00 2021 GMT
*  expire date: May 14 11:37:00 2021 GMT
*  subjectAltName: host "www.s-o-network.com" matched cert's "www.s-o-network.com"
*  issuer: C=US; O=Let's Encrypt; CN=R3
*  SSL certificate verify ok.
* Using HTTP2, server supports multi-use
* Connection state changed (HTTP/2 confirmed)
* Copying HTTP/2 data in stream buffer to connection buffer after upgrade: len=0
* Using Stream ID: 1 (easy handle 0x55e856105c80)
> GET / HTTP/2
> Host: www.s-o-network.com
> user-agent: curl/7.68.0
> accept: */*
* TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
* TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
* old SSL session ID is stale, removing
* Connection state changed (MAX_CONCURRENT_STREAMS == 100)!
< HTTP/2 200 
< date: Sun, 04 Apr 2021 02:46:47 GMT
< server: Apache
< last-modified: Thu, 20 Jul 2017 20:21:08 GMT
< accept-ranges: bytes
< content-length: 0
< host-header: c2hhcmVkLmJsdWVob3N0LmNvbQ==
< content-type: text/html
* Connection #0 to host left intact

Here is a stupid question…

Would it help to change the nameserver back to the original provider, wait and then reset them to Cloudflare.

In effect, turning it off, and back on again?           (for The IT Crowd fans out there)

Because I have spent an hours going over the cPanel over at the other provider, trying to refer back to the link for the 525 error page, and I don’t see where the the point of failure could be.

And like I said, both site were registered with the same registrar, both pointing to the same nameservers with virtual hosting. Now after changing the ssl setting for both to “none” in Cloudflare, the two are exactly the same. I don’t see why one would work and the other wouldn’t. Mind you, one had a lot more (s-o-network.com) records than the other, when both were basically parked, and they were not done by me, if that was not obvious enough.

This should work. And you’ve spent a lot of time on this. I suggest you open a ticket and see if they can track this down. Be sure to post the ticket # here.

To contact Cloudflare Customer Support, login & go to https://dash.cloudflare.com/?account=support and select get more help. If you receive an automatic response that does not help you, please reply and indicate you need more help.

This would be hilarious if it was not so frustrating.

I switched the nameservers back to my previous hosting provider.
Log into my Cloudflare panel and waited, refreshed, even purge cache, and the while it keeps telling me, " Great news! Cloudflare is now protecting your site"

Ok, I switch the nameservers back to Cloudflare after a half or so. All the while Cloudflare panel kept saying,“Great news! Cloudflare is now protecting your site”.

Anyways, I open a ticket 2125497. Hopefully this can get resolved, somehow.

Thank you all for your time.

p.s. Haha, can this get any worse. I got message when I tried to post this original message that, “You’ve reached the maximum number of replies a new user can create on their first day. Please wait 9 hours before trying again.” So if you are reading this just know its been at lease 9 hours since these actions were take.

Going around a second time:

I see that the “network” hostname resolves to the origin IP address and responds. This is not the IP address in your ‘curl’ example. It’s a 172 address that belongs to Linode. The 162 address in your example belongs to Unified Layer.

The ‘www’ subdomain also resolves, but is proxied. It responds.

Neither respond to HTTPS, so this means the server is not properly configured for HTTPS.

1 Like