What feature, service or problem is this related to?
DNS records
What are the steps to reproduce the issue?
I registered this domain two days ago and configured the nameservers. As you can see in the screenshot, the nameservers have been updated to those specified by Cloudflare! I have also configured the DNS records, but surprisingly, even after 24 hours, Cloudflare still cannot recognize that the nameservers are correct.
Additionally, there’s a security bug: even though the status in the Cloudflare panel for this domain is set to proxy (as shown in the screenshot), when you ping the domain, the original IP address is revealed. In fact, Cloudflare is exposing the IP!
Please be cautious. I noticed this bug years ago, yet it still hasn’t been fixed, and it’s unclear under what conditions it occurs. It seems they are not taking this issue seriously
When zones are in a pending state, DNS records are not proxied (even if set to be). This is to prevent downtime when switching nameservers to Cloudflare…
Both nameservers are fully set up. I’ve checked this using the dig tool on Linux and also Google’s online dig tool at https://toolbox.googleapps.com/apps/dig/#NS/. The responses confirm that both nameservers are correctly configured.
Even with this tool at DNS Checker - DNS Check Propagation Tool, it shows that both nameservers are correctly configured. However, Cloudflare still hasn’t recognized this status, and the main server IP is still exposed
Regarding the IP leak, this is a security issue. The main purpose of using Cloudflare is to prevent DDoS attacks by hiding the server’s real IP. When the proxy is enabled, the server IP should not be exposed! If someone wishes to avoid downtime during nameserver changes, they can simply disable the proxy option. If this feature is meant to avoid downtime during nameserver changes, it should be clearly mentioned on the DNS page, so users are aware of the IP exposure risk. For many services, if their IP is leaked, they’ll need to restructure and set up a new IP, which can be costly and time-consuming for individuals or companies
Domain Name: HEQAKD11A9.FUN
Registry Domain ID: D501441192-CNIC
Registrar WHOIS Server: whois.apiname.com
Registrar URL: http://www.apiname.com
Updated Date: 2024-11-12T02:52:44.0Z
Creation Date: 2024-11-12T02:51:05.0Z
Registry Expiry Date: 2025-11-12T23:59:59.0Z
Registrar: Atak Domain Bilgi Teknolojileri A.Ş.
Registrar IANA ID: 1601
Domain Status: serverTransferProhibited https://icann.org/epp#serverTransferProhibited
Domain Status: addPeriod https://icann.org/epp#addPeriod
Registrant Organization: Privacy Protect, LLC (PrivacyProtect.org)
Registrant State/Province: MA
Registrant Country: US
Registrant Email: Please query the RDDS service of the Registrar of Record identified in this output for information on how to contact the Registrant, Admin, or Tech contact of the queried domain name.
Admin Email: Please query the RDDS service of the Registrar of Record identified in this output for information on how to contact the Registrant, Admin, or Tech contact of the queried domain name.
Tech Email: Please query the RDDS service of the Registrar of Record identified in this output for information on how to contact the Registrant, Admin, or Tech contact of the queried domain name.
Name Server: LADY.NS.CLOUDFLARE.COM
DNSSEC: unsigned
Billing Email: Please query the RDDS service of the Registrar of Record identified in this output for information on how to contact the Registrant, Admin, or Tech contact of the queried domain name.
Registrar Abuse Contact Email: [email protected]
Registrar Abuse Contact Phone: +90.2623259222
URL of the ICANN Whois Inaccuracy Complaint Form: https://www.ic
And as I said, your misconfiguration means your domain is still in a pending state in Cloudflare so the proxy is not enabled, and this is by design as in the link I posted.
You must add the second Cloudflare nameserver to your registrar for your domain to go active.
If users are moving to Cloudflare, their IP was already exposed from their previous DNS, which is how Cloudflare can auto-detect DNS records to add.
It seems there may be an issue with the setup, as WHOIS information appears correct on some sites, but only one name shows up on others. I’ll change the nameserver information to something else and then, after 24 hours, reset it to Cloudflare to check again.
Regarding your point about IP exposure when moving to Cloudflare, I disagree. Anyone familiar with Cloudflare would know that migrating to it requires changing the IP; otherwise, the proxy feature would be pointless. Additionally, this doesn’t apply to new domains. In my case, this is a new domain with no prior IP set for it, so there shouldn’t be an exposure issue here
You just need to add the second nameserver. There’s no descrepancy, the root servers report a single nameserver (which then responds, when queried, with the 2 NS records)…
dig +trace heqakd11a9.fun ns +nodnssec
; <<>> DiG 9.10.6 <<>> +trace heqakd11a9.fun ns +nodnssec
;; global options: +cmd
. 515719 IN NS a.root-servers.net.
...
. 515719 IN NS m.root-servers.net.
;; Received 239 bytes from 127.0.2.2#53(127.0.2.2) in 22 ms
fun. 172800 IN NS b.nic.fun.
fun. 172800 IN NS f.nic.fun.
fun. 172800 IN NS a.nic.fun.
fun. 172800 IN NS e.nic.fun.
;; Received 290 bytes from 2001:500:12::d0d#53(g.root-servers.net) in 80 ms
heqakd11a9.fun. 3600 IN NS lady.ns.cloudflare.com.
;; Received 79 bytes from 2a04:2b00:13ff::72#53(f.nic.fun) in 35 ms
heqakd11a9.fun. 86400 IN NS augustus.ns.cloudflare.com.
heqakd11a9.fun. 86400 IN NS lady.ns.cloudflare.com.
;; Received 102 bytes from 2a06:98c1:50::ac40:207f#53(lady.ns.cloudflare.com) in 24 ms
Only if you want to keep the IP secret. And for that it would have to be new when you add the domain to Cloudflare; most people won’t be changing their IP when they go behind the Cloudflare proxy.
It is important that a pending domain does not proxy since it’s possible site visitors could be returned a Cloudflare nameserver before Cloudflare sees the nameservers are set (such as in your case as you have misconfigured) and the domain goes active. That would mean the user site would be down as the proxy and SSL are not configured at that point but the client would get a Cloudflare proxy IP address from the DNS.
If you’d have just set the nameservers correctly you wouldn’t have had this issue.
The issue is that both nameservers have indeed been correctly added, as verified through dig and other online tools. However, it seems there’s some inconsistency on the registrar’s end. In some WHOIS services, both nameservers are displayed, while in others, only one shows up. If only one nameserver had been added, it should display as such consistently across WHOIS and dig results. Since both nameservers are visible in dig and WHOIS, but only one is picked up by Cloudflare and certain other services, it suggests a synchronization issue in updating the nameservers.
For anyone looking to use Cloudflare automatically via API, this situation highlights the importance of building a solution into their code to handle such issues, so they don’t encounter similar setbacks
Additionally, given Cloudflare’s policy of exposing the original IP before the domain verification is complete, I’d recommend avoiding DNS configuration until the zone activation status is confirmed. This can help prevent premature IP exposure
Sure you can verify it with dig using the correct command, but that will reveal the same result as the Whois query (and @sjr demonstrated earlier in this thread).
It does as evidenced by the query @sjr provided. Otherwise, no your assertion is oncorrect because you misunderstand what dig is doing.
This works just fine if the domain isn’t being used in production. Otherwise it will result in an outage.
Both nameservers were not visible in whois, and the issue was the mechanism twofold. One a problem with your mechanism to set the nameservers and also for checking the assigned nameservers in your automation.
I’ll disagree… plenty of scenarios where you are moving from one cloud proxy (aka Akamai) to Cloudflare where the origin IP address hasn’t been exposed previously. In that scenario making sure you’re adding the values correctly at the registrar is key assuming one isn’t interested in downtime.
