So You Want to Change Your Nameservers
Learn the process of changing your nameservers — including common pitfalls and gotchas.
All right, it's that time again. Time for another exciting episode of Cloudflare TV. My name is Chris Scharff.
I'm a solutions engineer for Cloudflare. Welcome to an episode of So You Want to Change Your Name Servers.
Today we're going to talk about, interestingly enough, changing your name servers to Cloudflare.
I know it sounds very exciting, and I'm glad you could all join us.
First, I want to take a step back, similar to other DNS talks that I've had, and talk about why Cloudflare for DNS.
Honestly, DNS is core to what we do. Everything we do at Cloudflare revolves around DNS.
We are ultimately a DNS-based proxy, so getting DNS right, making that available to our customers, and making it performant is really important to us.
Most people talk to us about authoritative DNS, but I did want to just point out a couple of other offerings that Cloudflare has available.
We have our free 184.108.40.206 service, or Quad One, which is much easier to say.
We also have Quad One for Families, which provides filtering against adult content and malware.
And then for businesses, enterprise, guest Wi-Fi networks, we have a product as part of our Cloudflare for Teams product called Cloudflare Gateway.
So if you're interested in any of those, I encourage you to check them out.
On the authoritative DNS side, a number of products, full setup and CNAME setup, we talked about those on an episode yesterday.
If you missed it, I'm telling you some of the best Cloudflare TV that happened during that one-hour slot.
We also have support for subdomains, secondary DNS, hidden primaries, and DNS firewall.
Today, we're going to focus just on a few of those as it relates to changing your name servers.
So that's really a full setup, subdomain setup, and hidden primary.
So why Cloudflare for DNS?
Performance matters. Cloudflare runs the fastest authoritative DNS on the planet.
When you add your domain to Cloudflare, we're advertising your name servers from hundreds of co-loads around the globe using our Anycast network.
That means that for something like 99% of the world's population, they're going to be within 100 milliseconds of a Cloudflare co-load.
And when you make changes within Cloudflare DNS, that replication happens quickly, typically sub-30 seconds.
From a security standpoint, you get the advantages of our DDoS protection for your DNS infrastructure, the ability to roll out DNSSEC.
For our enterprise customers, we have role-space access control. There's auditing available.
We also have what I believe is one of the easier-to-use intuitive UIs.
So if you watched earlier today, we had a roundtable with some of our UI and design folks.
They spent a lot of time thinking about how customers use our products and incorporate that feedback.
We also understand that there are a lot of folks that manage hundreds or thousands of domains, millions of records.
And for them, we make a powerful API available.
And we also make it easy to support things like Terraform and other DevOps automation strategies.
So before we jump into changing out name servers, I just wanted to give a quick shout-out to the Cloudflare marketing team.
A lot of the graphics that you see on Cloudflare's blog, all of the assets that exist on our website, tools and cool graphics like this one that I pulled in here, our marketing team makes these available to us.
And it really helps to help us relay our message in a way that customers understand and is engaging.
They're a huge help to everything that we do. I know we're a very tech-focused company, but we couldn't do it without our folks in marketing, really.
They help us get that message out, and they're a huge help to all of us.
All right, so that's enough of a love fest with my marketing team.
Let's start talking about activation best practices for Cloudflare and stop opening sites that people probably shouldn't see while I'm on live TV.
This is going to end well. All right.
Sorry. Hit the wrong mouse key combination, clearly. All right, so you've decided you're going to bring your zone to Cloudflare.
You've added in the UI. Quick scan, all your DNS records appear.
We tell you to change your name servers. You're ready to go, right?
No. All right. We have a utility. It runs. It is a great utility. It scans the most common DNS records that we see, approximately 2,000 of the records.
It also checks for common record types like MX records and text records at the root, and it has some logic to follow down various paths.
If we see record type A, we should check for these other records to make sure that we can, for non -technical users, do our best job to automatically import the records into Cloudflare.
It's a great utility. My recommendation is that you should not rely on it to make sure that you have all of your records if you have an environment with any type of actual complexity associated with it.
So to that end, I often suggest customers either manually create any missing records or that they import from a bind file from their existing provider into Cloudflare any records that might be missing in their environment.
Within the UI, there's an Advanced button on the DNS tab.
You can click that to import your bind file. You can also do that via API as well.
So once you've imported all your records, you're sure they're in Cloudflare.
The next step is to triple check those, right? So you want to make sure that all of the key critical records are in your environment.
It's a little bit like Animal Farm.
All records are equal. Some records are more equal than others.
So you want to make sure your corp records are there, your MX records are there, any of the kind of key records for your business.
You just want to double, triple check those and make sure.
Then, because I'm sure we're all working in an environment where we have change control, we're first going to copy out all of our records from our existing DNS server along with name server records because we want to have a record of that.
We're going to file a change control ticket, letting folks know what we're going to do and when we're going to do it.
Honestly, changing your name servers is an incredibly low risk operation.
This is not something I tell my customers that you need to wait until 3 o'clock in the morning to do.
But you do want to document it. You want to make sure that people are aware that change is coming.
And then, really, the key to a successful name server migration, if you verified all of your records there, is going to be copying and pasting the name server records from Cloudflare into your registrar.
Copy and paste them.
Don't manually type them. I have seen more issues with customers mistyping the name of a Cloudflare name server or the name of Cloudflare than any other problem.
Maybe not all the problems combined, but by a far margin more than any other problem.
When you add the name servers for Cloudflare, that's going to be done at your registrar.
That may be the place where you're managing DNS, but it may be a different portion of the interface.
We're going to jump over in a minute.
We're going to take a look at a DNS management interface at a registrar and kind of walk through this process.
But you're making this change at the registrar.
If you make this change in your own authoritative DNS, that's not where we're looking for the change.
It's not going to allow your zone to activate. So, again, the change is made at your registrar.
We put it on the emails that we send.
It shows up in summary on the overview page. But people often overlook that or don't think about what registrar means and they just think in my DNS.
But truly, we're looking for the change we made in your registrar itself.
In order to successfully activate your zone at Cloudflare, only the name server pair should be listed that Cloudflare provides.
So you may have existing records in place already.
You're going to remove those and replace them with the Cloudflare name server pair.
Most registrars will allow you to do this in an atomic operation, but that's the change you're going to make.
And once that change is propagated, then Cloudflare is going to become authoritative for DNS queries for the zone, except where you've delegated another subdomain away perhaps to some other name server pair.
So you're going to want to make sure that any DNS records that are going to be queried exist within Cloudflare's DNS.
So you may have been managing this in another tool with a different DNS provider.
Eventually, you may be able to get rid of the records that exist there, but just leave them in place for now when you make the change with your migration.
And, again, you want to copy and paste the name servers.
I'm going to keep saying that over and over. In fact, if we end like five minutes early on this talk, I'm just going to chant copy and paste, copy and paste, copy and paste until I run out of time.
So it seems silly.
It seems ridiculous. Please copy and paste. It will save you so many problems.
All right. With that, I want to talk about a couple of issues that we see in customers' environments that are issues.
So before I get into the uncommon ones, let's talk through kind of the points here that customers run into and have problems with.
Again, hit the wrong keyboard combination. You guys really want to see stuff that you're not allowed to see.
So the only name server pair that should exist at your registrar if you're using Cloudflare for authoritative DNS are the Cloudflare name servers.
So if you leave your previous name servers in place and add the net new Cloudflare name servers, now maybe you have four name servers or even more, that's not going to activate your zone on Cloudflare unless you're using Cloudflare for secondary DNS.
And so that's the asterisk there next to that is if you're a secondary DNS customer with Cloudflare, then we do support you having other records in place in DNS.
It's an enterprise feature, so if you're utilizing that, we have knowledge-based articles on how to configure it, and you should follow those steps instead.
This is really meant more towards the standard setup that most customers will go through.
The other time, there is one time where you won't be making name server changes at a registrar potentially, and that's another enterprise feature that we call subdomain sign-up.
So for our enterprise customers, rather than signing up example .com to Cloudflare directly, we would support adding foo.example.com as its own top-level domain within Cloudflare to be managed.
When you make that type of change and you're adding a subdomain to Cloudflare instead, then you're going to want to do the name server delegation in your authoritative DNS to the pair of name servers that Cloudflare provides.
But like I said, both these features that have asterisks next to them, stars.
Both the features that have stars next to them are enterprise-only features, and if you're utilizing those, check in with your account team with any questions you might have.
But for everybody else, name server change at the registrar, only the Cloudflare name server should be there.
The other thing I should mention is if you already have DNSSEC enabled with your registrar from a prior DNS provider, currently you need to disable DNSSEC with your registrar prior to making the change.
If you don't make that change, then the move will fail, and even if it quote -unquote succeeded with Cloudflare, for DNSSEC validating resolvers, the lookups would fail.
So that is definitely a clue if your domain isn't migrating. DNSSEC is occasionally the issue there.
It's a little more obscure, but definitely is something that we occasionally see.
Some other slightly more uncommon issues that we come across, there are scenarios where your registrar may not allow that transfer to succeed or where it is basically failing DNS lookups at the time you're trying to do the transfer because of a hold status on your domain.
You'll typically see this if you do a whois from the command line or if you use an online whois lookup tool to look at your domain.
You may see either a pound client hold or pound server hold typically in the UI, and that means that basically there's a problem with your zone and you should contact your registrar and get that worked out before your zone is going to be able to successfully be migrated over to Cloudflare.
There are a couple of other scenarios that can happen. .DE and a couple of other European TLDs have some interesting checks that they do when you're making a name server change.
And in some cases, they'll do a query against Cloudflare when you're trying to update your name servers and they'll report back that Cloudflare is saying there's a different pair of name servers that are responding as being authoritative for your domain.
Should that occur for you, my recommendation would be to reach out to support by opening your ticket at support .Cloudflare.com or emailing them a valid account on Cloudflare to support at Cloudflare.com.
That is not something, unfortunately, the community or anyone else is going to be able to help you with, so you need to contact our team for that.
Occasionally, I've also seen an error around name servers not being registered.
Again, if you see an error that looks like that, every time I've seen it, it's been translated from a different language, so I'm not sure what the actual language is or which providers are involved there.
But if you happen to come across that error at your registrar when you're trying to add the pair of name servers that Cloudflare provided you, feel free to reach out to our support teams as well.
And then the other problem that we'll occasionally come across is there may be an issue with the top-level domain provider where they're seeing significant delays or errors in propagating the changes that you've made.
You can validate that those changes are propagated typically, again, using Whois as a lookup tool.
If the change is reflected there and you've taken all the other steps that we're discussing right now, then generally speaking, we would expect the name servers to propagate in short order.
And then we've also got a Recheck Now button within the UI. All right, so having talked to those things, I want to give a second shout out before we go into our demo to the Cloud community.
So if you have questions about changing your name servers, about using DNS at Cloudflare, in addition to a great knowledge base, we also have a robust community with a cast of characters who would be more than happy to answer your questions, provide feedback on Cloudflare usage and best practices, and tell you how everything I've said for the last 16 minutes is completely wrong, and they'll tell you the right way to do it.
So community.Cloudflare.com, check it out when you get a chance.
So now comes the fun of a live demo.
This can't possibly end badly. All right.
So here we go.
So this is my demo zone that I'm using here today, and we're going to be logging in and changing the name servers for it.
I used the same domain yesterday, partial setup, so today we're converting it from a partial setup to a full setup.
So I've logged into my registrar here. This is the ‑‑ actually, this is not the domain that we want.
We're going to go to my domains. We're going to go back, I believe, Cloudflare demo.cf.
Yes. Let's go ahead and go into manage domain.
So when we look at our management tools, I have name servers, registrar glue records, URL forwarding.
I also have managing my DNS within Freenom. So they have a DNS interface here that you can use to manage your records, but we're about to change our name servers.
So, again, we're not going to make any changes within this section.
Instead, what we want to do is update our name servers. So today we're using the default name servers at the registrar.
So if I do a dig from the command line, I can look this up and it will return the current name servers.
There are also online tools for DNS lookups.
You can do this with things like NS lookup as well.
But here I've just checked to ask for the name server records that are currently in place for tbdemo.cf, and we can see that those are registered at Freenom.
So instead I want to use a pair of custom name servers. So we're going to flip back over to my test environment here.
And you can see I have two domains here, Oswald and Rachel.
And you'll notice there as I click the copy button.
So we are going to copy this to the clipboard because it's all about the copy and paste.
We're going to add the first name server. I know the second one is Rachel, but look, it's a funky spelling of Rachel.
I would have spelled that incorrectly.
So now I'm going to go back over here. And I would update that with Oswald and Rachel.
I'm going to double check these. I'm going to flip back over even though I did a copy and paste because I want to make sure I didn't leave the last letter off, that there's no straight characters.
Once I'm sure of that, I'm going to go ahead and change my name servers with my registrar.
So at this point, if somebody was visiting this website and they already had the previous name server pair cached and I've just switched it out from under them, that's fine.
The name servers that were in place are still running. They're still functioning.
They will continue to answer queries while the clients that may have cached data are being updated and picking up the Cloudflare information.
If I want to accelerate the propagation around the Internet, I can do something like 1 .1.1.1.
And hopefully that will come up. Yes, so Cloudflare has a tool. If I wanted to, I could come in here and I could say tvdemo .cache.
Tell it the type of record that I want to purge from cache. In this case, name server records.
I can purge that. Perhaps I also want to, if I'm using Cloudflare now for proxying and I wanted to come in and purge the www record, I could choose the appropriate record type for that.
I think I have that in as a CNAME.
I could do that as well. So all the major DNS providers have a tool like this. Google with 220.127.116.11 is the other one that I'm relatively familiar with.
But updating that can sometimes help refresh things.
I'm going to come back to my environment here.
We're just going to hit refresh and see if it's noticed on its own in the background that I've updated the name servers because oftentimes this can be pretty quick.
But I am waiting on a combination of my environment to understand what's going on as well as the name server.
So let's go ahead and see if the same name server pairs being returned.
So you can see it's updated here in DNS. So I'm going to flip back over to Cloudflare.
I'm going to ask it to recheck the name servers.
It's queued up a job for us to push that through, and that should just take a couple of seconds here.
If I hit refresh.
Okay, not quite active yet.
But in general, it should be working. If I want to check to make sure that Cloudflare is answering properly for the authoritative records, I could do something like this.
I'm going to be copying the wrong stuff out again.
I'm going to take the error again.
Okay, I almost typed the wrong name server in.
All right, look at that. And because it's being hidden, I can't even fix it.
So this is why I copy and paste, not to mention the pain and suffering of doing a demo on LightD.
So this knows that this is the case. Double check my name servers again. It's definitely reporting back the right thing from there.
Refresh Cloudflare. Go to our overview page.
Oh, good news. Cloudflare is now protecting my site. So Cloudflare is active.
My DNS records are now active. So if I wanted to take advantage of Cloudflare's proxying services, I can do that for my environment.
You can also see if you were wanting to take advantage of Cloudflare's SSL.
I've got this in full so that both my origin and my connections to the edge are encrypted.
If I look at my edge certificates, you'll see that I have a pending validation here for my environment.
This should probably validate within the next few minutes.
And then I'll be able to serve SSL traffic on this as well.
So honestly, that's really the process for getting things set up. Again, just to kind of cover a couple of highlights so that I don't have to start chanting copy and paste over and over again, as promised.
We're making this change in our registrar, and thus we're doing a subdomain delegation.
Make sure you've got DNSSEC disabled if it's already enabled in your existing zone prior to the transfer.
And then I think the real key for any type of complex environment is to make sure that your records are in place.
If you need to manually create those by hand, you can do that here within the interface.
But you can also import a bind file from Cloudflare or into Cloudflare from your previous provider, and we'll import those.
And then when you're finally finished with your migration to Cloudflare's name servers, I would go ahead and export your existing DNS records as a bind file.
Keep a copy of this somewhere as well. While Cloudflare has a very highly available infrastructure and redundant infrastructure, backups are always a good idea.
Exporting this so that you have a copy of any of the records that exist in your environment, doing that on a periodic basis, is to me just a really sound practice for an environment.
And so with that, I am going to start chanting copy and paste until somebody comes and yanks me off the air.
Copy and paste. Copy and paste.
Copy and paste. Copy and paste. Copy and paste. Copy and paste. Copy and paste.
Yeah. All right. Now that's it. This is awesome. I appreciate everybody having joined me today, taking the time to learn a little bit about changing your name servers.
This is a great experiment that we're doing here at Cloudflare. Folks have come up with all kinds of creative ideas.
I'm really excited to see what people are doing.
I may be leading some yoga next week and talking about technology at the same time because there's nothing more relaxing than nerding out and talking about yoga at the same time.
Who knows? It is going to be a huge and wonderful experiment.
Thank you all for tuning in. I hope that you continue to tune in with us and that you have enjoyed yourselves as much as I have.
Thank you all and take care.
Hi, we're Cloudflare.
We're building one of the world's largest global cloud networks to help make the Internet more secure, faster and more reliable.
Meet our customer, Wongnai, an online food and lifestyle platform with over 13 million active users in Thailand.
Wongnai is a lifestyle platform, so we do food reviews, cooking recipes, travel reviews and we do food delivery with Lineman and we do POS software that we launched last year.
Wongnai uses the Cloudflare content delivery network to boost the performance and reliability of its website and mobile app.
The company understands that speed and availability are important drivers of its good reputation and ongoing growth.
Three years ago, we were expanding into new services like a chatbot.
We are generating images dynamically for the people who are curing the chatbot.
Now, when we generate image dynamically, we need to cache it somewhere so it doesn't overload our server.
We turned into a local CDN provider.
They can give us caching service in Thailand for a very cheap price, but after using that service for about a year, I found that the service is not so reliable.
We turned into Cloudflare and for the one year that we have using Cloudflare, I would say that they achieved the reliability goals that we were expecting for.
With Cloudflare, we can cache everything locally and the site will be much faster.
Wongnai also uses Cloudflare to boost their platform security.
Cloudflare has blocked several significant DDoS attacks against the platform and allows Wongnai to easily extend protection across multiple sites and applications.
We also use web application firewalls for some of our websites that allow us to run open source CMS like WordPress and Drupal in a secure fashion.
If you want to make your website available everywhere in the world and you want it to load very fast and you want it to be secure, you can use Cloudflare.
With customers like Wongnai and over 25 million other Internet properties that trust Cloudflare with their performance and security, we're making the Internet fast, secure, and reliable for everyone.
Cloudflare, helping build a better Internet.