You CANNOT change nameservers for the apex / root domain / naked domain with domains registered through Cloudflare

Turns out, you can!

https://medium.com/@johnkennedy_11119/can-i-use-cloudflare-as-a-domain-registrar-and-still-use-3rd-party-nameservers-0701d38071d8

Cloudflare just ignores/doesn’t do anything with NS records you create like that as far as I know. I just sanity tested it on a CF Registrar domain and it did the same, just ignoring it entirely.

As from his comments at the end about Proxy status, it wouldn’t matter what it is in Cloudflare if that actually worked. It is kind of confusing it accepts that at all though if they just ignore them, for sure.

Even if that did work, that’s expressly against the Registrar terms of service:

Registrant agrees to use Cloudflare’s nameservers. REGISTRANT ACKNOWLEDGES AND AGREES THAT IT MAY NOT CHANGE THE NAMESERVERS ON THE REGISTRAR SERVICES, AND THAT IT MUST TRANSFER TO A THIRD PARTY REGISTRAR IF IT WISHES TO CHANGE NAMESERVERS.

You can of course still delegate subdomains to different nameservers.

1 Like

Will you help me understand how you validated that the NS records were/are ignored? In my testing, if the NS records were not setup with the 3rd party nameservers, the site did not come up.

I don’t know about you, but I can’t change the Cloudflare nameservers if Cloudflare is the registrar. With that, it is still within the terns of service. The Cloudflare nameservers still resolve as the authoritative DNS server.

I can’t do a packet trace on this obviously; however, to resolve the domain, it must hit the Cloudflare nameservers, which show there is a NS record and passes it through.

The guide is referring to the change of NS record(s), which are applied within your current name server set up, e.g. on the Cloudflare name servers, according to the guide.

DNS resolvers will have to reach Cloudflare name servers first, in order to be able to retrieve, and see these NS records.

Whether the DNS resolvers will ever follow or use these NS records, then becomes more of a implementation specific issue, depending on the specific DNS resolver being used.

One DNS resolver could for example (randomly) be using the NS records, where another DNS resolver may completely ignore them, and only use the data from the two *.ns.cloudflare.com name servers, that the domain is actually delegated to, according to the domain registry.

Unless you’re making sure that all your changes are applied on BOTH Cloudflare, AND the mentioned 3rd Party Custom Nameservers, you will likely see problems going forward.

Can you share a domain name, where you have already applied the suggestions provided in the guide?

That is my understanding.

Everything that I have read indicates that Cloudflare is and remains the DNS resolver. The Cloudflare name servers pass the request on via the NS record.

You could be right about the DNS resolver using the NS records and another using a completely different one. However, I have checked www.whatsmydns.net and the DNS resolvers are the *.ns.cloudflare.com name severs. This leads me to believe that any randomness is not proven itself yet. Without a packet trace, not sure how to validate this beyond what I see on the what’s my dns site.

I’ll have to think about sharing the domain I used. I’d consider a PM; however, I don’t see that as an option.

I can share the domain with the MVPs if you put it in here…
https://cf.sjr.org.uk/tools/check

1 Like

Just out of curiosity, I’ve checked RFC 1034 again. It is very clear that there can only be one delegation per label and that the apex of a zone must contain the authoritative name servers for that zone, it cannot delegate the apex to another nameserver.

I have no idea why Cloudflare even allows the creation of NS records for the apex, but I tried doing that and it had exactly no effect.

4 Likes

Per the RFC, that is consistent with what I am seeing. However, the initial propagation will likely use the NS record.

I am basing that off of the following article on Cloudflare www.cloudflare.com/learning/dns/dns-records/dns-ns-record/

At the bottom of that link it says this:

When should NS records be updated or changed?

Domain administrators should update their NS records when they need to change their domain’s nameservers. For instance, some cloud providers provide nameservers and require their customers to point to them.

Admins may also wish to update their NS records if they want a subdomain to use different nameservers. In the example above, the nameserver for example.com is ns1.exampleserver.com. If the example.com admin wanted blog.example.com to resolve via a ns2.exampleserver.com instead, they could set this up by updating the NS record.

When NS records are updated, it may take several hours for the changes to be replicated throughout the DNS.

Once the propagation occurs though, those nameservers point to Cloudflare

DNS lookup using the NS:

It says:

  1. example.com uses ns1.exampleserver.com

  2. blog.example.com is wanted to be using ns2.exampleserver.com

You’re wanting to add to the first, so that the apex / root domain / naked domain will use additional name servers, than just ns1.exampleserver.com.

That is done in the parent registry for the example.com domain, most often through your domain registrar.

And you CANNOT change these name servers for the apex / root domain / naked domain, in the parent registry, with domains registered through Cloudflare.

The option with #2 is however possible through Cloudflare Registrar, but that will only be effective for specific sub-domain, such as blog.example.com in the above example.

The NS, to use your own words, is the key here.

Your “-n ns1…” parameter is asking that specific name server for what it has of data for the given domain in the “-d …” parameter.

Any name server can hold data for any domain name they want to, but that DOES NOT mean that they are actually authoritative for the domain, or that they will ever be used at all.

Check this example:

$ dig +trace NS canadapost.ca

; <<>> DiG 9.18.19-1~deb12u1-Debian <<>> +trace NS canadapost.ca
;; global options: +cmd
.                       86400   IN      NS      g.root-servers.net.
.                       86400   IN      NS      e.root-servers.net.
.                       86400   IN      NS      h.root-servers.net.
.                       86400   IN      NS      c.root-servers.net.
.                       86400   IN      NS      j.root-servers.net.
.                       86400   IN      NS      k.root-servers.net.
.                       86400   IN      NS      b.root-servers.net.
.                       86400   IN      NS      m.root-servers.net.
.                       86400   IN      NS      f.root-servers.net.
.                       86400   IN      NS      i.root-servers.net.
.                       86400   IN      NS      l.root-servers.net.
.                       86400   IN      NS      d.root-servers.net.
.                       86400   IN      NS      a.root-servers.net.
.                       86400   IN      RRSIG   NS 8 0 518400 20240210170000 20240128160000 30903 . rzTu1J7dOtrLk77RI/+9Tg7ZBvV1onDc3f2jKsY3ErXU55E9WNKbkkcG RN/4Wm1TqdhqOmwBpJwuHwDV1z1zztF0+7FbVLYJi8OUGJXJXDGKBdxx NnG3CZqUK9YhDJZ/gGVbBmjbPtTL+cwB8oSM/5Ym7PCGGS32Yn+Kc74k ihAJDFbXjCUPMhOKrK2Pz8pIh8/GEJGUsuwzKFIPB4gVPRU2saHEYOj4 cJlwzzwsFccQdUw2UA0J5nyxEhzoFiZ47AMFQG1ERbu4kwg6uv161h4t cHQ2ugEFFQWMxXO9SCi7NaY/m3X0U6EczurRmyUtRAqcTIqEcbqJquhs hUmIhQ==
;; Received 525 bytes from 127.0.0.1#53(127.0.0.1) in 80 ms

ca.                     172800  IN      NS      j.ca-servers.ca.
ca.                     172800  IN      NS      any.ca-servers.ca.
ca.                     172800  IN      NS      c.ca-servers.ca.
ca.                     172800  IN      NS      d.ca-servers.ca.
ca.                     86400   IN      DS      18560 13 2 86EC28ED5BFF076186306DC8CE3B4E3EC0433D9D5D34C7CA8DAC7B19 34E8B324
ca.                     86400   IN      RRSIG   DS 8 1 86400 20240210170000 20240128160000 30903 . iJhQ/Hd7xu19UQdUYGb93TN6U2TdB7szAWx+fo9oWGiLiKDZIs7IJtMg me3j0/Vn1jiqjquzoVADBKa7c8+yhh925AMtl2Z3wuMW/ibWnAEXt42I kGwtGVON3i6+EnA7LvkgHiBmPXO/J6w5YhDgvbDePZk+T1hiX5VkwhtB ZB8zV6bhV3yaooJk8qPiBB9sUDlZtLU2pcdn1/svL6bCujyJxiSwRHt8 Fmag68xhb3FFsIUBdLvoQwFy9TqhendTKwe3mTsV/uzhBAL2fIts0cyH TIuNFXn+5SP4BI/xziVk03hTzo0RyMaWFaMdIEGpBLZw+JWVbTOd0V8H WdYljQ==
;; Received 660 bytes from 192.112.36.4#53(g.root-servers.net) in 28 ms

canadapost.ca.          86400   IN      NS      a1-226.akam.net.
canadapost.ca.          86400   IN      NS      a13-67.akam.net.
canadapost.ca.          86400   IN      DS      46432 13 2 D23830063BBA0BEB890017FFDDDA8D44B57A1BA1C920BF5F4858693D 1294A582
canadapost.ca.          86400   IN      RRSIG   DS 13 2 86400 20240201112552 20240125083752 56816 ca. iHRm9ZObQMimjy2yr6fSQOWRawza8i+jwhnbYWNSuwSngAjpslY6g1wA xWJW2XnHG2tdOVT0z4Lmm95HsOG73A==
;; Received 266 bytes from 45.142.220.101#53(d.ca-servers.ca) in 16 ms

canadapost.ca.          900     IN      NS      a6-65.akam.net.
canadapost.ca.          900     IN      NS      a1-226.akam.net.
canadapost.ca.          900     IN      NS      a8-67.akam.net.
canadapost.ca.          900     IN      NS      a7-66.akam.net.
canadapost.ca.          900     IN      NS      a2-64.akam.net.
canadapost.ca.          900     IN      NS      a13-67.akam.net.
canadapost.ca.          900     IN      RRSIG   NS 13 2 900 20240131001807 20240127231807 3166 canadapost.ca. rBT37WYeOZlOkcyd7mB+IiQOufa9qStCzHki8SO/O9gC+FzYTL0ujKCL +kuDIfrCz/OgDG6IOyPtr7/gs3QiVQ==
;; Received 281 bytes from 2.22.230.67#53(a13-67.akam.net) in 24 ms

In the parent registry here, canadapost.ca has only two name servers listed, being a1-226.akam.net and a13-67.akam.net, as you can see from the second last entry, received from d.ca-servers.ca.

However, in their actual zone file, there are four more, a8-67.akam.net, a2-64.akam.net, a6-65.akam.net and a7-66.akam.net.

Some DNS (health) checkers out there will also show these four name servers, a8-67.akam.net, a2-64.akam.net, a6-65.akam.net and a7-66.akam.net, but that doesn’t mean that they will ever be used, as there aren’t any reference to them from the parent zone (… the .ca zone).

The part of stuff that I said above regarding the specific implementations, -

It is my understanding that DNS resolvers that follow the root hints as supposed to, such as in the example with canadapost.ca, is going to stick to a1-226.akam.net and a13-67.akam.net alone.

In addition, from what I’ve seen in my time, all the six NS records in the child zone (on the akam.net name servers) could be deleted, and DNS resolvers would still be able to find the zone, because of the a1-226.akam.net and a13-67.akam.net name servers in the parent zone.

Such “strange” DNS setups (where the actual child zone doesn’t have NS records) have for example been seen very often with the arpa zones you use for to configure Reverse DNS (PTR) records for your IP address(es), although these zones were still working perfectly fine.

I cannot decide what you should do…

All I am saying is just, under my impression, you’re wasting your time on nothing.

1 Like

No, i’m not wanting to add more name servers. What i’m saying is that if you need to use third party nameservers when Cloudflare is your registrar, you need to use the NS record to point to them.

Based on that, you can change them for any apex/root/naked domain.

All I was showing in the screenshot is that if you entered the third party nameserver, it pointed back to Cloudflare indicating that it was no longer the authoritative nameserver.

That’s the point, the parent nameservers define who the authority is. What was mentioned by @Chaika, @DarkDeviL, @sjr, and @Laudian is spot on.

Would you mind adjusting your thread’s title, as otherwise there’ll be countless other people in the future who will reference this thread and will ask why their hack does not work?

Doesn’t look like I can update it.