CNAME Setup or Full Setup: The How and the Why

All right. Hey guys, Chris Scharff here with Cloudflare TV. Today, the most exciting hour, the hour everybody's been waiting for, the topic nobody asked for, CNAME setup or full setup. We're going to talk about how to set up DNS at Cloudflare. I'm Chris Scharff, Solutions Engineer. I work with our enterprise customers to help them onboard onto Cloudflare. I have probably onboarded 20 ,000 to 30,000 domains onto Cloudflare at this point and have had this conversation a number of times. It comes up quite a bit in early conversations with customers. Do we want to do a CNAME setup? Do we want to do a full setup? And I figured this is a great opportunity for us to talk through this, talk through some of the differences between the configurations, the pitfalls, advantages, disadvantages. And if time remains at the end, I'm going to tap dance through the end of the hour by actually moving a couple of domains over. So let's get started. First thing to think about as we're thinking about DNS is what's the right setup for my environment? And I guess even more fundamental than that is why Cloudflare for DNS? DNS is really core to everything that we do here at Cloudflare. We're a DNS-based proxy, so all the other services that Cloudflare provides build on top of our DNS services. It's something that we're quite good at and have quite a bit of experience with. So, you know, I think there's definitely things that we provide that perhaps some folks aren't familiar with. From a recursive standpoint, some of you may have already heard of 1.1.1.1. This is our authoritative DNS service. It's free, available for anybody that wants to use it. We also have a version of 1.1.1.1 for families, and this provides filtered DNS for malware, adult content that's available. For our enterprise customers, we have Cloudflare for Teams, and within that, a gateway product that allows organizations to set organizational DNS policies, block content categories such as gambling, get full access to logging data, and manage their internal infrastructure and security concerns that may derive from that. As I was putting this session together, I started thinking about, well, which should customers choose? CNAME, full, you know, what really are the options? And what I realized was when I came up with this type of session and passed it on to the folks that were putting together the schedule, that I hadn't actually thought this problem through. At Cloudflare, we do quite a few other things besides just providing full or CNAME setup. For our enterprise customers, you can also bring on a single subdomain, and it's child nodes to be managed on Cloudflare. We also offer secondary DNS, so you may be running your own DNS infrastructure and you want Cloudflare to provide redundancy for you in your environment as publicly listed DNS servers. We also provide a service that can run a hidden primary, so you make changes in your DNS environment and then those replicate to secondary servers that are managed by DNS. And then finally, we also offer DNS firewall. So for folks that have their own existing DNS infrastructure, but are looking to protect that infrastructure, Cloudflare provides services where we can provide caching layer and other services that go along with that. So let's jump in here and start talking about the advantages of each. But before I go there, I wanted to just give a quick shout out to the Cloudflare community. The Cloudflare community is available at community.Cloudflare.com. And if you have questions coming out of this, if you're looking to set up your environment, understand how Cloudflare works. A lot of folks on previous webinars here on Cloudflare TV have mentioned our support. And I think earlier tonight, one of our support engineers was giving some debugging tips for troubleshooting errors. We also have an amazing team in the community that's available to answer questions at any point and try to provide you with some help as well. And I think you'll also find that there's some differing opinions from some of the things I'm going to say here today that may surface in the community. That's great. It is a marketplace of ideas. Some of them are better than others. Mine are clearly the best of the ideas, but there's room for everybody. So let's talk for just a moment about a full setup. Full setup, what you do as a customer to add a zone to Cloudflare, and then you're going to be prompted to change your neighbors from wherever they point today to Cloudflare. You're going to make that change at your registrar. Don't make it straight away. There's a few things that we're going to do before those changes. But the change is made at the same place that you purchased your domain. So that could be Cloudflare. If you purchased your domain through us, you could have purchased your domain through somebody like Network Solutions, or I'm going to walk through and use a free domain for a demo if we have time here at the end using a free DNS provider. When you change your DNS to Cloudflare, only the Cloudflare name server pair should be listed. So you'll want to add the two new Cloudflare name servers that are provided to you, and at the same time remove the any previous name servers that you had listed. With every registrar I've ever dealt with, that's an atomic operation. I can blank out the current name server pairs, add news, and click submit, and it all takes place in one atomic action. But if there is an order of operations with your registrar, what you want to do is add the new pair first and then remove the previous pair. Once you've made that change in your registrar, then Cloudflare becomes authoritative for your DNS for that zone. What does that mean? That means any third party that goes to do a lookup to find your website, say www .example.com, they're going to ask the root hit servers, who are they going to ask the top level domain, something like .com, and then .com is going to know that example.com has had its name server pair delegated to Cloudflare. Cloudflare is going to answer those questions for you. Overall, I find this setup to be the easiest to manage for customers. It's the easiest to get your head around. It introduces the fewest challenges when dealing with disparate teams within an organization, and all other things being equal is generally the setup that I'll recommend. There's some caveats to that, and we'll talk through some of the reasons that you might choose one over the other, but I want to make sure that we just kind of get through what a full setup looks like, and then talk about some of the differences with CNAME setup before we talk about the pros and cons. The other thing that Cloudflare provides for DNS is straightforward DNSSEC support. So if your registrar supports DNSSEC and your TLD supports DNSSEC, enabling DNSSEC at Cloudflare is a simple mouse click, and what this does is it provides some records for you that you'll copy into your registrar, same place that you change your name servers, and now when validating resolvers go to do a lookup on your records, they're able to check to make sure that they're signed properly to know that there wasn't a man in the middle or some other type of DNS cache poisoning attack for your environment. So if you're a customer or organization that cares about DNS security, it's a great feature, something that we provide on all of our plant types, and something that I highly recommend for zones where making sure that the right results are returned are important. So maybe not as important to go through that effort for your marketing domains, but for your core kind of primary business domains, definitely worth doing the work. A full setup also supports CNAME flattening at the root. This is relatively nerdy, but if you have ever read a DNSRFC, then I guess you probably needed to get to sleep, and that was the reading material you had available. But the DNSRFCs say you can only have an A record at the root of a domain, and so when people want to do an alias at the root of their domain, that APEX doesn't support it. So what Cloudflare did was we built a solution that allows us on our back end to resolve whatever the CNAME target for your root is, and when the DNS server asks that question, we return the IP address that it maps to, rather than the CNAME, since that would make us a non-RFC compliant resolver and might cause issues with DNS servers. There's some other folks that have done similar things. There's an RFC that proposed a DNS record type called an ANAME record, and so there are some providers out there that support that, but at this point, adoption is relatively low for what is an incredibly handy feature. With a full setup, you also are only reliant on Cloudflare's DNS when you're making changes in your environment. So we typically expect DNS replication to occur sub-30 seconds in our environment. I believe our P50 is something like five seconds, so very quick when you're making a DNS change. Having worked with a number of my customers that were moving from other legacy platforms to Cloudflare, that fast replication is something I really take for granted, and we spend a lot of time talking about the weather, current events, sports, waiting for DNS to replicate on their side. The full setup, I think, also gives you the most straightforward management interface if you're looking to do DevOps and Terraform, and we provide you with analytics for your environment. In a CNAME setup, instead of changing your name servers, what you'll do is you'll add a text record to your existing DNS zone, so not your Cloudflare zone, but the zone where you're hosting authoritative DNS to verify or prove that you have positive control of DNS for your environment. Very similar if you've ever signed up for a third-party service such as a mail service, they'll have you put text records in place to prove that you control the domain. CNAME setups are a little bit more complicated. There's a record that has to be in your authoritative DNS, and then you need a similar record in Cloudflare DNS as well, so you're managing records in two places. In your authoritative DNS, you'll have a record that looks something like www .example.com, and you're going to point that to, as a CNAME record, to www.example .com.cdn.Cloudflare.net. So cdn.Cloudflare .net is the super secret formula that you append to any fully qualified domain name in your zone to get it to ultimately resolve to Cloudflare's name servers. And then within Cloudflare, similarly, you're going to add a record for, in this case, www.example.com that's going to point to your origin server. And when a user queries for that, if you've proxied that record through Cloudflare, we're going to return Cloudflare IP addresses that correspond to your edge, depending on the plan that you're on, the time of year it happens to be. That's typically either two or three records that'll be returned when somebody does a query. But it's a little more complicated, right? Because you have to manage those records in both places. If that record is gray clouded in Cloudflare, then we're going to return the true origin IP address. We'll also return the true IP address if your zone is not yet active, or if you've paused Cloudflare on the main website. So I mentioned the community earlier. One of the head-stumpers that comes up is somebody appears to have their DNS set correctly. It points to Cloudflare's name servers. Folks in the community go in and verify that everything looks right. The end user insists that they have the record orange clouded. A lot of head scratching. And then somebody pulls this one out and says, yep, you probably have Cloudflare paused. And 99 times out of 100, that's what it turns out to be. But it's a pretty obscure thing. There's no support when we're in a CNAME setup for Cloudflare providing you DNSSEC. And also, proxying the root record is unsupported. And so here, I want to stop for just a second and talk, at least from my perspective, about what that means from an unsupported standpoint. It doesn't mean that you can't do it. You can absolutely proxy a record directly to Cloudflare for example.com with no subdomain. But the RFCs say that you can't do it. So you're going to have to, if you're doing that, you're going to put the Cloudflare IP addresses that are returned for other records into your DNS. And you're going to hard code those. The challenge is, unless you're an enterprise customer who's either paid for dedicated IP addresses or has brought their own IP addresses to Cloudflare for us to advertise on your behalf, there's a chance that those records could change. So you're pointing to a pair of IP addresses that it may not be able to serve your website in the future. And so that's a risk. If it's your personal recipe blog, it may not be that big of a risk. But if you're running a business and you're pointing to Cloudflare and those IP addresses change and it impacts your business, that's a challenge. So we don't guarantee, other than the couple of scenarios that I mentioned, that your IP addresses won't change or that will continue to serve SSL for you on your old IP addresses after a period of time. So if you are going to do that, my recommendation is generally, when you hard code those IP addresses, write a monitoring tool that will notify you if the IP addresses Cloudflare's returning ever change. If those records change, you can either manually go in and update your DNS in your authoritative DNS, or you can write a script to do it. The other scenario is you may be using a DNS provider. There's only a handful of them in the large DNS provider space that support A records. And if you're talking to one of those or using one of those services, then you can create an A name record in their DNS and that allows for Apex proxy. But beyond that, it's not something that Cloudflare supports. So if it breaks, we're going to be very sympathetic, very empathetic. But they will point back to this timestamp where I say, I told you so. So it's more of a use it, you're on risk, then we won't, it's not that we won't provide the legitimate troubleshooting for other issues that you might encounter. We fully expect from a from a mechanic standpoint that proxying the route will work. But we're not going to support or your environment at the IP addresses change and you haven't updated them. The other problem potentially with C name records is there's the potential for record drift. And what that means is you may have imported a bunch of records into Cloudflare at the very beginning when you first signed up for the service. Over time, records that you work proxying may have changed in authoritative DNS and you've decided, oh, now I want to bring that application on to Cloudflare. Not only do you have to change to the super secret formula that I pointed out, where you append cdn.Cloudflare.net into your environment. But you also need to make sure that the origin that Cloudflare is pointing to is in fact what you're pointing to today in your authoritative DNS. Or if you're in the process of doing migration, that is pointing to where you want it to point when you make the change and flip over to proxying through Cloudflare. There's nothing in our system that's going to tell you this record didn't match something in your previous DNS service, there might be a problem. That is incumbent on you as the administrator to make sure that you've got it set up correctly. We also don't provide DNS analytics for partial or C name setups. We're not gathering enough data, enough meaningful data to be able to provide those. They're really pretty robust and useful. But since we're not your authoritative DNS provider, we can't tell you if there was an NX domain for records that don't point to Cloudflare. Sorry, NX domain is an error code that's returned when a record doesn't exist. So those analytics you want to get from your existing DNS provider. You can also potentially have a slightly more complicated DevOps automation workflow here because now you may be managing records in two different locations, your authoritative DNS as well as in Cloudflare. This is certainly not insurmountable. We have a number of customers who have written really robust automation around this. But it does take a little more thought to make sure that you're doing it the right way. So I think maybe my bias for a full setup came through perhaps. So let's talk about some reasons that customers might choose a C name setup instead of authoritative DNS. I have a number of customers that do this today. I tend to deal with larger organizations. There's a lot of legacy and historical challenges that can exist. So it's not, I don't think as simple of a decision as it might be for a home user, professional user, small business user to make that change. So I think probably the most legitimate reason that I typically encounter when talking to customers is they've already done a significant amount of automation around DevOps with their existing DNS infrastructure. That doesn't mean that they may not ever migrate to Cloudflare. What I've typically seen from my customers is they figure out that Cloudflare is really actually pretty robust and easy to manage. And eventually they may do more integrations with Cloudflare or deprecate their previous automation. But as a barrier to getting maybe a single marketing site on, that's a lot of heavy lift to ask of an organization just to swap DNS servers. The other common scenario that I come across is customers that really are only planning to migrate a single site or a small number of sites, but they're part of a larger organization. So I have some customers that have thousands, tens of thousands of DNS records, some even more than that. Asking that organization to flip their DNS to Cloudflare just so that we can host their holiday party marketing website might be a bit much of an ask. So in those scenarios, setting it up in a CNAME setup can certainly make sense long-term. Again, there's still the opportunity to switch the setup type and move the entire organization to Cloudflare for DNS, but that seems to be legitimate to me as well. This also has a lower change control threshold. So if you're an organization that has a change control review board that you go through when you're going to make changes in your environment, migrating all of your DNS may make that a two-week, three-week project plan to get DNS migrated over. That may be an unnecessary blocker to doing other work, such as migrating a single site or a single test site over to Cloudflare initially to get some parallelization of the migration process underway. And so setting up in a CNAME setup, proving that you have authoritative control of DNS, working on setting up your web application firewall, your caching strategy, implementing other Cloudflare features such as polish or minimization tools while you're still talking through the process of migrating the entire zone, perfectly acceptable strategy from my mind. I've worked for a number of large organizations. I worked for companies that have 100,000 plus employees. I understand their internal politics that sometimes preclude people from making this type of change. It may be that the entire team wants it. It may be that huge parts of the organization want it, but the political realities may not allow for that change. Frustrating, both for myself as a solutions engineer working with the customer as well as for the customers themselves, because I think in general in those scenarios to recognize the advantages that Cloudflare brings to bear, but we do what we have to do to get things done. And then I think I already mentioned the plan to convert subdomains more quickly in the future. So let's go ahead and talk about best practices for when you're onboarding a domain to Cloudflare. Five tips based on my experience, and there are six tips. Somebody didn't approve of the slides. I'm going to blame my dog. All right. First tip, we have a wizard. It imports records. What it does is it does a scan of approximately 2,000 common record types that we've seen in the past, checks for certain kind of base records, such as a text record for the root of the domain, MX records. Based on that, there's some other logic to kind of do a little more of an exhaustive search for certain record types. We'd expect if record A, record B probably exists as well. It is a handy tool. It is great if you have a recipe blog. It is great if you have a small number of sites. It is great for a simple marketing domain that you might be just setting up to do forwarding. For enterprise domains, for any kind of domain with any kind of complexity, this tool is absolutely going to miss important records in your environment. In general, other than setting up a first test domain to kind of do testing with, if I'm working with a customer that has more than 10 or 20 domains that they're going to onboard, my recommendation is that they skip that completely and script the addition of domains, bypass the wizard, which does the scan while they're adding the domain, and instead import a bind file or other set of records that have the authority to put all of their DNS records into Cloudflare. You're much more likely to get everything into your zone if you have any kind of complexity at all. That being said, the first zone that I brought to Cloudflare when I was planning to interview as a solutions engineer, it's a personal domain. It had a moderate amount of complexity. As far as I know, it got everything. I don't have any recollection that it actually missed anything. So, certainly okay way to start and adding domains via the UI, not complicated. My feedback, though, will be spot check those key records in your organization to make sure that they exist and that they're resolving correctly. So, your MX records, your record for your web mail server, any type of VoIP or other critical services for the organization, you really want to make sure that those records are in place, that you did a basic due diligence, that made sure that Cloudflare was going to resolve them the way you expected them to to be resolved before you do the migration. Next tip, once you've actually verified that all the records exist in Cloudflare and you're ready to activate, especially in a full scenario, do that as quickly as possible. Put the request in, push to get it done as quickly as possible. The potential is there that there will be DNS drift from the time you bind file import until you go live. And if you do an updated bind file import, if a record already exists, we're not going to overwrite it. We're only going to add net new. We're going to assume that Cloudflare had a record that you intended to keep. There's a lot of good logic reasons for that because the alternative is potentially extremely bad in a number of scenarios. So doing that as quickly as possible is hugely important. The other part of this is, before you go live, both on Cloudflare and on your previous authoritative DNS, export your existing records. Export a bind file from each. You can do that in the Cloudflare DNS control panel under advanced. There's an export option. Having a backup, storing that somewhere securely, incredibly helpful. I've been in the IT industry now for 30 years. I've had to go to backup for a number of services over the years where systems failed. Fortunately for me, DNS has never been one of those places I needed to go to for a backup, but having never needing it, vastly superior to the alternative. Then finally, my tip, generally speaking, and this is some type of marketing site where you know you're going to want everything to be proxied through Cloudflare and it's a relatively simple setup, is I typically will gray cloud everything in Cloudflare to set it to not be proxied before I start bringing traffic on. Some exceptions to that, if I've already done testing in advance and a proof of concept or pilot with a customer, then I might suggest that they leave those records on. But in general, when I'm switching DNS over, if I've just changed my name servers, the old name servers will still answer for anybody who was previously doing DNS resolution against cached values, because I haven't deleted it there yet. Cloudflare will start picking up new records, so it will be a seamless migration. But if you only change one thing at a time, so in this case, changing your name servers, checking to make sure that your previous DNS and Cloudflare DNS are giving the exact same answer to a DNS query can eliminate Cloudflare as the problem if you're trying to troubleshoot something weird that happened. Certainly, okay, add in orange plotting, proxying, web application firewall. It just means you potentially have more moving parts and can make things a little more difficult to troubleshoot initially. As you get experience with the system, as you're more comfortable troubleshooting Cloudflare, understanding how it works, I think changing things to be gray Cloud only becomes less important. But I'm talking to a really general audience here, and no offense, I just don't know the skill level. So with that, we've got half an hour left. I'm going to walk folks through actually migrating a couple of things, if that works for folks. So I'm using a site here called Freenom. And earlier today, I registered a couple of domains. And so we're going to go through the process of migrating those over to Cloudflare just so that we can work through all those pieces that we talked about. All right, so I've got tbdemo.ga. And we're going to manage this domain. This one first is a full setup. So I'm going to go to my management tools, and I'm going to go to name servers. So again, this is my registrar. This is where I registered the domain. This is not necessarily who is hosting my DNS. In this case, it actually happens to be the same, but they're managed in two different places. So this is the default name servers and custom name servers that I can configure. There's also a section to manage my DNS records. And we'll flip over to that here as well so we can see it. But notice if I added name server records here for Cloudflare as a type, they actually don't allow that here. So they're preventing you from shooting yourself in your foot, but there are some providers that will. You need to make sure that you're making these changes in the right area. So we've got tbdemo.ga. Let's go ahead and I'm already logged into my personal Cloudflare account. So we're going to add a site. This, unless you're an enterprise customer intentionally adding a domain, you're going to want to go with the root domain. We're going to do an authoritative DNS. Secondary DNS is an optional feature for our enterprise customers. A little bit out of our scope for discussions today. So we're going to add this site. This is going to go through the wizard. So you're going to see that it's going to automatically import these records. I'm going to flex just because I can and choose an enterprise plan. And we'll see in the background Cloudflare scanning for existing DNS records using that algorithm that I described previously. So this is being scanned. Once it comes back from its list of records, it's going to give me an opportunity to edit, delete, remove things. I'm doing a full setup here. So I'm going to want to leave all of the existing records. If Freenom supported a bind file, or if I had planned ahead more than five minutes before I came to give this talk, I might've had a sample bind file so I could show that to you all. But here I've got a couple of records. I've got my root record, my dub-dub-dub. We're going to go ahead and follow my best practice and set these to be gray clouded initially. Continue. At this point, Cloudflare is going to provision me a free universal SSL certificate once my name servers have been migrated. And it's given me a pair of name servers that I need to update in Distinct Provider. So by far, the most important thing you can do when you're setting up your name servers is make sure you copy and paste. Typos are, for a large organization, by far the biggest risk to getting DNS set up correctly. So if you do everything else correctly, having a typo here can be a huge problem. You laugh. I laugh. I tell all my customers this. The other day, one of my customers was having a problem. We did a dig. The name servers look just fine until I realized they'd accidentally put a one at the end of one of the servers as a typo and they added them. So I'm going to double check this, go back to my origin. I'm going to copy this record as well. We're going to paste that in. We're going to change our name servers here. And so this change is made in my registrar. When I first started working on the interwebs, that could take up to 24 hours to propagate. Most major DNS providers these days, so the .com, .net, .org, TLDs, and some of the other government-run TLDs will oftentimes make this change in sub five minutes. So we're going to flip back over here. We're going to tell it, done, check my name servers. I actually don't expect my name servers to have replicated yet. So if they are valid when we get through this last bit, I'll be very happy. So earlier today, a little discussion about troubleshooting SSL, setting configure environment. I'm going to point out the default configuration here is set to full. What this means is once we have an SSL certificate in place, if you're proxying traffic through Cloudflare, you can force users to Cloudflare's edge to use SSL, and then we'll make an SSL connection to your origin. This requires that you have an SSL cert on your origin. There's going to be a few talks for Cloudflare QBE in the next few weeks where we'll talk about a number of ways that you can get this done. But talking flexible to your origin is not secure, right? So it's encrypted to Cloudflare's edge, but Cloudflare's edge is talking to your origin server over HTTP. There's no encryption. It's like sending a postcard on the Internet. I guess if you have a marketing site, this isn't a problem, really, maybe. But doing it in full using a Cloudflare certificate, highly recommended, full strict, even better. For enterprise customers, we also have authenticated origin pools. Since we do want to take advantage of Cloudflare's SSL, I'm going to go ahead and services, and we're not just doing DNS in my scenario. We're going to go ahead and tell Cloudflare for anything that comes in on HTTP, let's go ahead and globally upgrade those connections to HTTPS. I might want to minimize my JavaScript and CSS and HTML, but I'm going to pretend that I'm a competent developer and that I've already minimized all of my code on my origin, so not necessary. For those of you who have ever watched me write code, you know how much I'm pretending right now at being a competent developer. If you've heard of GZIP, Broadband Compression Setback, it's just a new compression algorithm that Cloudflare implemented and is available on our edge for clients that support it. And then we're going to go ahead and tell it we're done. So, here I've got my name servers that need to be changed. I can recheck. Before I do that, because this is live TV and I don't want to have to force this, I'm going to dig up the name of our domain, guys. What's our domain? tvdemo .ga. We're going to look for the name servers and we'll see what it brings back. Oh, look, Rachel and Oswald. These are the only two name servers that are listed. So, the old ones were removed. So, this matches. We're going to double check and we're going to click recheck now. It's queued up to be rechecked. It should show up here in just a moment. I've got my DNS records. If I look up, flipping back to DNS here again, www.tvdemo.ga. That's not at all what I meant to do. Let's just take the error. We're going to see it returns 192.0.2.1. This is technically a non-routable Internet address used for documentation. So, all of you who are planning to hack my server by going to 192.0.2.1, I like the way you think, but it's not going to work. All right. So, we've got our name servers here. If I want to enable DNSSEC, I can click this. It'll give me back the information that I need to do that for my environment. Let's go back to the overview page. We'll just go ahead and hit refresh here and see if this has changed at all. Again, there's not a problem here. My old servers are still answering for Cloudflare. Even if the new servers wasn't activated, I had the right records on the Cloudflare side. We can see that we're active here now. I've got my records. Now, if I wanted to come back and return an IP address, we're going to return an IP address on Cloudflare's edge. So, let's save that change. We're going to flip back over to my DNS. dbdevo.ga. And look, instead of that 192 address, we're instead given two Cloudflare IP addresses that correspond to our edge. So, that is a setup. Now, let's go back and we will add another site. Go back to my domain list here. And we've got dbdevo.cf. So, let's manage this domain. We're going to do this one in a CNAME setup. So, overall process is going to be fairly similar. I'm going to go to my management tools. Eventually, we're going to be changing the name servers. So, I'm just going to get us on this page and this is dbdevo.cf. Let's grab that. We're going to add this as the domain that we want to add. Deceptively authoritative DNS. Technically, we're authoritative-ish. But we're going to go with that again. We're going to add this site. In the background again, it's going to be doing that scan. So, CNAME setup. I guess I didn't mention this before. Only available on the business and enterprise plans. I'm sure there's some very rational reasons that Matthew and team came up with. My personal belief is it's much more expensive to support because there's enough subtle nuances there. If customers open enough tickets, it shows that some of those subtle nuances are really difficult for folks to grasp. So, we're going to go with enterprise here. Someday that may change. Yeah, it's a feature. My page has gone crazy. Let's go back. All right. That's awesome. How about we reopen a new tab here? Nothing like live demos. Click in. Hopefully this works. If not, we'll try an incognito window. All right. So, our TV demo here is in the setup stage. Let's go ahead and select it. Confirm our plan. Sorry about that feature. Again, we're doing that scan of DNS records in the background. For this domain, I've created the exact same two records. The www and the root. So, that's going to be pretty similar for us here. While that scan's completing, you can go get yourself a cup of coffee, adult beverage of your choice. So, now we've got our new records here. We've got the root domain and we've got the www records. Now, if you remember correctly, we can't, well, it is unsupported to proxy the root. So, I'm going to remove this. By the way, I guess I should have mentioned previously, I talked about doing automation around DevOps to update the DNS records here. The other option a customer could do for an Apex domain is if you have a dedicated or static IP address somewhere else that has a web server, it's under your control. You can instead point to that server and just have it do a 301 or a 302 redirect to your www site. So, that's also something I see customers do quite often. So, okay. We've added this record. You can see again, we've got a SSL certificate that we're planning to make available. We've got the server there, but we want to do a partial setup. So, bear with me. It's on a later screen. We don't give you the option to do it now. We're trying to be very persuasive, but we can change it. So, I'll show you exactly where you can do that. We're going to say, don't check my name servers. Again, I've got full from my SSL here, no flexible, full. We're going to set it to HTTPS because we want our users to be secure. I'm going to keep pretending I'm a competent developer. We're going to leave that on. We're going to leave on a broadly support, and we're going to click done. So, now I have my name server pair here, but we mentioned we don't want to change our name servers. We have reasons that we need to be able to leave our existing name servers in place, and we only want to do C names over to Cloudflare's edge. So, we're going to scroll all the way to the bottom, right-hand side, where we've conveniently hidden convert to partial DNS setup. Click this. So, you can see this means I cannot approximate my root DNS record through Cloudflare, cannot benefit from the speed and resilience of Cloudflare's global DNS network. I guess I would also point out that if you're authoritative DNS servers or somewhere else, and you're C naming to us, you're doing at least one more DNS lookup once it gets to Cloudflare's edge for us to do a lookup. We're also not providing DDoS protection for your authoritative DNS. So, in a C name setup, you're getting fewer of the benefits that Cloudflare has available. So, I'm going to confirm that I want to press the scary confirm button. At least we didn't write JavaScript, so you have to chase it around the screen to actually get it done. By the way, if you're doing this via API, you can also choose the setup type as partial while you're provisioning those zones. So, if you're doing this in mass, you can absolutely do that in your environment. So, now we see that we need to add a record to our DNS. So, typically, all you need to do is add just the root or just the node name. So, I was on the name server page, wrong spot to be. I need to manage my DNS. So, I just about made an error, but yeah, we're going to come here. We're going to add, we're going to switch this to be a text record. We're going to paste in the value here of Cloudflare verify. I'm working in the tvdemo.cf zone. So, similar to the www here, I don't need to add the fully qualified domain name to this, and then we're going to grab this content, copy that out, flip back over. So, this is the record that will be returned. So, we're going to save those changes in our environment, and then what will happen here is Freenom will create this record for us. You can see they did a two upper, which I guess is fine. We've got the value here. Those numbers are clearly uppercase and not lowercase, and it's also fine. I'm not even sure what a lowercase number looks like. I'm not nearly as funny as I think I am. Okay, so let's grab, we're looking, uh, Cloudflare, so we're going to dig verify.tvdemo.cf. Nothing more exciting than watching somebody type on live TV, especially when they can't type, and we're going to look for a text record. And so, assuming I typed that all correctly, looks correct, you can see that it hasn't propagated yet. So, let's switch back. Let's make sure there's not typos, since there's nobody looking over my shoulder. Cloudflare verify.tvdemo .cf. Text record explicitly, and not there yet. So, this is one of those advantages to, uh, to using somebody else's DNS. I'm not at all trying to, uh, rag on Freenom at all. It is free DNS. It is a free zone, um, useful for the purpose I'm using it for. Um, there is a very different set of, uh, of criteria for what we built. So, uh, let's go then, and we're gonna just go ahead and make sure our DNS is set up correctly here. So, if you remember, one of the things that I said is I want to make sure I don't have any DNS drift, right? So, I want to approximate my www record. I pointed that to, uh, 192.0.2.1. Um, I'm gonna go ahead and grey cloud that initially. Um, I'm gonna save that. I'm sure this is going to the right spot. I'm gonna come back to my client area, uh, and now here's the challenge. I've got www, uh, but I need to change the record type. So, uh, we need a CNAME target for that. So, uh, there's no atomic operation here. So, we're just gonna, actually, let me point something out. I mentioned the best practice, copy out your DNS records. You should really know where things are pointing, because once I delete this, there's no audit log. I can't go back and figure out what this used to be, uh, unless it's been recorded somewhere else. So, even if it's just taking a screenshot of what your current DNS records, uh, by far, uh, preferable to just making changes. I'm sure you all have CCRBs. So, you go through change control. You've already documented what the previous value is going to be, and you've documented what the new value is going to be. It's not going to be a problem. So, yes, I'm really going to delete this entry. Uh, then we're going to add, add new entry. We're going to choose a CNAME record, and it is going to be www, and it is going to point to www.tvdemo.cf, and then, um, cbn.club, where that is my target. So, I'm going to save that, because I might need it for later, and I'm going to save my changes. So, I've added this new record here. Uh, hopefully, these atomic changes are relative, or these changes, since they weren't atomic, were, were, uh, happened fairly close to one another. Uh, but you can see my target here is the fully qualified domain name, and we've added cbn.club.net. Let's look back over and see if my text record is propagated. It has not. That's always fun. Uh, all right. Yeah, this might be less of an exciting demo than I think it's going to be. Uh, and then, we're going to come back over here. This still points to the right origin. Flip back over here. First thing we're going to do is we're going to dig for www.tvdemo.cf. We're going to see what comes back as an answer. You can see this points to 192.0.2.1. So, just like the text record, this hasn't yet propagated at the previous DNS provider. So, again, one of the challenges, you may have two different teams making these changes. So, you could have somebody in corporate making a change for you. They send an email, tell you it's done, an indeterminate amount of time for that replication to happen. You go to look it up. You're expecting to see Cloudflare headers. You're trying to figure out why Cloudflare's broken something. In this case, I don't think it's us. So, let's see. Let's do, the problem is going to be, because this zone isn't active, it's also going to return the root record. But because it's gray cloud, that's exactly what we wanted to do anyway. So, if I look this up directly, I should get the same one to answer, right? Record's not proxied. Zone isn't active. Let's just go back over here. We're going to click on the overview tab, see if we can make this work. Generally happens pretty quickly in the background. There's an exponential back off. So, we will continue to check in the background. You can recheck once every 24 hours. It doesn't look like that. But that's the basics of this record. So, now comes a scenario, hey, we got it done. We also want to cover the findings record. So, we're going to do the same thing here, right? I'm going to add a record. So, in this case, let's make it a CNAME Cloudflare. So, this is going to be finance, is the name of the server, and this points to find, right? So, I've got a third party server that I'm pointing this to that provides the service and the solution. I've added this to Cloudflare. And if I flip back over to my DNS query here, and I swap out for finance. Oh, see the record's active. Okay. So, the zone's active at this point, and you'll see that this works because it's returning Cloudflare IP addresses. But there is a problem. This won't actually work as I expected. So, let's do a search for finance, and you'll see there's no record. That's because we haven't added it yet to authoritative DNS, right? We got the order of operations right, but it is two distinct operations that we've got to undertake here. So, we've added it to Cloudflare first, so that we know where to resolve that, and where to send the traffic that comes to it. But we need to come in to our other DNS control panel, wherever that might be, and we've got to add a CNAME for finance. That's going to point to CF .CDN.CLOCK. So, now I've added this record to my environment. And once this propagates, finance should be available. So, doing this online, it looked like it was about two minutes or so for that to propagate globally. So, we'll clear here again, just to make it easier to read, and do a DNS lookup for this. All right. So, see, that record still hasn't propagated. It's a feature, but again, because you're utilizing two systems, your configuration becomes a little bit more complex in your environment. If in the future, I decided that I wanted to switch this CNAME setup, so I've go back to my overview here. You can see, I'll hit shift refresh, just to show this zone is working as we expect it to. Interesting. It doesn't think that it is here. That's probably just a caching issue. But if in the future, I want to take Cloudflare, and I want to convert from full DNS setup, to, or from partial to full, I can do that. And again, it's sort of an interesting order of operations. On the Cloudflare side, what you want to do is a full setup. So, on the Cloudflare side, you make this change. This starts a timer. At this point, your name servers don't match. So, we've assigned you a new one. These don't match what Cloudflare is checking on our side. So, you need to make sure that you do update your name servers to point to Cloudflare within 30 days. Otherwise, the zone can go to moved, and eventually be deleted from Cloudflare. But I need to switch to full, because otherwise, in my DNS tab, I only have a limited set of record types that I can add when I'm in a CNAME setup. And there's a bunch of different records that I may need to add that aren't supported in a CNAME setup, such as NS records or MX records for an environment that are being maintained in the parent DNS instead. So, I can run in this state. Everything will continue to work. There's an SSL certificate on the edge, WAF rules, all those things continue to function. But if I do decide that I want to move to a full setup, then I can either via API, or I can come here to the UI, and I can import a bind file. You can drag and drop a bind file onto this. I only have one monitor. I work full screen. Dragging and dropping is really hard. So, I instead just click select a file and import. And then, as I mentioned, we also have the ability to export your data. So, you can export your existing bind file. It's basically a text file. We'll open that up here just for fun. Literally, everything here with semicolons is not really needed, and neither is this first line. I'll just pull it out for clarity. You can see the way the bind file is formatted. We have some comments here that say these are A records, and the 182.0.2.1. And you can see I also have a CNAME record that points to finance.demo.doc. So, you can do this in an automated fashion. There are third -party tools that will connect to Cloudflare, export this data. You can do like I used to do when I first became a sysadmin. There was a batch file that I had to go to a server and just log in and double click the button every Monday morning to run it. And then, every Friday when I left work, I just made sure that it completed successfully. And then, once a quarter, theoretically, we tested those backups and made sure they worked. For those of you that have worked with backups, you know how often that actually probably happened. And so, with that, we are coming up to the top of the hour. I really want to thank everybody that came and hung out with me today. I hope this was useful for folks. Tomorrow, we're going to spend a half an hour just talking about transferring your name servers and best practices there. What it will really boil down to is copy and paste your name servers. I'm just going to say it over and over and over again for half an hour. And then, Friday night, if you're interested in live train wrecks, join me for Trivia at 5 p.m. Central. And I look forward to hanging out with you all again. Coming up after a short update to the system, Steve is going to talk about serverless storage strategies. I assume that means a USB thumb drive that you plug into your laptop. But I'm going to stick around and watch it to try and figure it out. So, thanks again, everybody. Really enjoyed you all taking the time to hang out with me today. I appreciate anybody that's hung out this far. You are clearly getting gluttonous for punishment. Join us in the community. Have a chat. Make fun of me. It's all good. Really happy that we've launched Cloudflare TV. Really enjoying all the feedback we've been getting about it and the opportunity to try and create something unique with each and every one of you. And so, with that, I will say goodbye.