Cloudflare does not see DNS server changes. More than a day has already passed. What to do?
You need to change your nameservers at your Registrar, who appears to be Hosting Ukraine LLC. You changed them in your existing DNS Nameservers, which won’t work.
~$ whois capitalhld.cloud
Name Server: ns218.inhostedns.net
Name Server: ns318.inhostedns.org
Name Server: ns118.inhostedns.com
DNSSEC: unsigned
2 Likes
Already replaced. I have attached a screenshot from the tests. Technical support for the domain registrar told me to contact Cloudflare because everything was fine on their end and the NS servers were registered correctly.
The only thing you have done is added Cloudflare Nameservers to your existing nameservers/DNS Host. Which is why you see it in dig, because it recursively resolves.
If you look at whois, you can see the output is not Cloudflare nameservers:
Name Server: ns218.inhostedns.net
Name Server: ns318.inhostedns.org
Name Server: ns118.inhostedns.com
DNSSEC: unsigned
If you query .cloud nameservers directly, you can see it as well:
dig capitalhld.cloud ns @ns1.uniregistry.net
;; AUTHORITY SECTION:
capitalhld.cloud. 900 IN NS ns118.inhostedns.com.
capitalhld.cloud. 900 IN NS ns218.inhostedns.net.
capitalhld.cloud. 900 IN NS ns318.inhostedns.org.
You’ll know when you have it set correctly when .cloud nameservers return Cloudflare nameservers instead of those currently set. (It may take a bit to update)
It looks like those are your default registrar’s nameservers. So there will likely be two locations where you can set nameservers, one somewhere under Domain Details, and another under DNS. The one under DNS is the one you have set currently and is the wrong one to change.
It looks like you could find the right one to change here: Нейм-сервери (NS) | Питання-відповіді на Wiki - Хостинг Україна and change them like so: Встановлення сторонніх NS | Питання-відповіді на Wiki - Хостинг Україна
If you have already set it like so, it’s either slow to update (but if it’s been a day, should be long enough) or something broken on your Registrar’s end you’d need to reach out to them about.
1 Like
It may be worth reviewing the DNSViz report. It looks like you might have some DNSSEC artifacts affecting your results.
2 Likes
I believe that’s just because Cloudflare is returning DNSKEY and signing their responses, which makes the responses from the default dns (inhostedns) “invalid”, should clear up once he gets his nameservers straightened out.
2 Likes
That makes sense and also explains why validating resolvers returned answers. It is interesting that the whois is wrong, but the 4 root servers for cloud all return Cloudflare NS. Hopefully it is just a matter of time while things catch up.
1 Like
That’s interesting, because that is definitely not what I’m seeing:
capitalhld.cloud. 900 IN NS ns218.inhostedns.net.
capitalhld.cloud. 900 IN NS ns318.inhostedns.org.
capitalhld.cloud. 900 IN NS ns118.inhostedns.com.
;; Received 147 bytes from 2620:10a:80aa::3#53(ns3.uniregistry.net) in 32 ms
capitalhld.cloud. 900 IN NS alan.ns.cloudflare.com.
capitalhld.cloud. 900 IN NS ariadne.ns.cloudflare.com.
;; Received 103 bytes from 2a06:6440:0:2c26::1#53(ns118.inhostedns.com) in 48 ms
That looks like a typical case of creating NS records instead of changing nameservers to me.
DNSVIZ may have problems because the nameservers respond with both NS and A records for the domain:
dig capitalhld.cloud @ns318.inhostedns.org ns +short
alan.ns.cloudflare.com.
ariadne.ns.cloudflare.com.
dig capitalhld.cloud @ns318.inhostedns.org +short
213.133.109.173
I’m also wondering why the Cloudflare nameservers are responding at all if the nameservers haven’t changed yet:
dig capitalhld.cloud @alan.ns.cloudflare.com a +short
213.133.109.173
Here are my results from the same root that you queried.
% dig @ns3.uniregistry.net. ns capitalhld.cloud. +short
alan.ns.cloudflare.com.
ariadne.ns.cloudflare.com.
I wonder if they use a distributed system that is out of sync and we are not actually reaching the same server.
1 Like
Ignore the results I shared that appeared to show correct nameservers at the root. The results were tainted by Linux on Chrome OS architecture diverting the queries to a recursive resolver. I will need to change my practices to mitigate this unwanted behavior.
3 Likes
This topic was automatically closed 3 days after the last reply. New replies are no longer allowed.