Yesterday, Today on the Cloudflare Community

** вrushing music ** Welcome to Yesterday Today on the Cloudflare Community. I'm your host, Tim Clunan, and join us every Friday for a new edition of Yesterday Today on the Community. Each week, we start with this Community Day and the Community Traffic Report at 10 a.m. It's followed by a review of the top issues from last week, using the ever -informative Community Tip, and occasional interviews with a Community MVP or Cloudflare Support Engineer. We conclude every week with In Class with Cloudflare, where we learn a few things about troubleshooting on the Cloudflare Community. Before we get started, I'm delighted today to be joined by one of our Community MVPs. Together, we're going to be digging into some posts on the Community a little bit later in the episode. But first, we'll go through and we'll start talking about the most popular categories and the most popular areas of discussion on the Community last week. The most popular area for discussion was security, with questions about performance and feedback around Cloudflare Access leading the pack. The most popular area for discussion last week was security, with questions about 1020 errors and the Cloudflare Access feedback leading the pack. Other popular areas were performance, with routing and rules leading the category. Overall, traffic was flat to the Community the prior week, with new posts up significantly, while new topics held steady over the prior week, basically indicating that we're having more conversations about a fewer number of topics. We're talking about them in greater depth. The top three searches last week on the Community were for WAF, speed test, and name server issues. We wanted to dig a little bit deeper into the specific issues around name servers, because there was a number of different aspects that were expressed, a number of different problems that folks had. We're going to go through and we're going to troubleshoot some of the more sticky issues associated with name servers, as well as something else that hits a lot of folks when they start out on the Community, which is email. We'll talk a little bit about email and name servers a little bit later on in the day. Before we get started, we're going to be referencing a number of Community tips, tutorials, and links to the Help Center. If you follow along at the link that you see displayed on the screen, you'll actually be able to go through and you can recreate the test that we're going to be running, or you can reference that later, or if you'd like to share it with some of your colleagues. First, let me welcome back to our program one of our Community MVPs. Dom was on our episode last week. Dom, thank you very much for taking the time to drop into the Community and answering some questions. No problem. Thanks, Tim. It's great to be back. I really appreciate you coming in. What we're going to be doing today is we're actually going to be using this tip to guide our conversation. We're going to start out and we're going to dig into some name server issues. As we think about the name server issues, we want to make certain that we deal with the things that really affect folks. There are 10 ideas in this tip that are based on easy ways to fix pending name server updates. What we're going to do is we're not going to focus on 1, 4, or 8 through 10. The reason being is that they're just not terribly interesting and they're not necessarily very challenging to be able to deal with. We're going to go into the other tips in great detail. We're going to answer some questions on the Community that have come up about those specific issues. Let's do talk to at least some of the things that we're not going to deal with in a lot of detail so that you have them for reference. Number one is you don't see any name servers listed on your DNS tab of the Cloudflare dashboard. That's a really good indicator that you're probably signed up through a partner. You don't need to change your name servers. If you've received a message saying pending name server update and you think you're signed up through a partner, it actually means that you need to probably look at the DNS tab of your Cloudflare dashboard because normally what you'll see signed up through a partner is your DNS is hosted by and then it'll have a partner name, so there's no need to change the name servers. Number four is your name servers were set to Cloudflare and then you move the domain to Cloudflare Registrar and your old Registrar trains change them on the way out the door. We see this quite frequently. In most instances, it's going to be fixed automatically. If it's not within 24 hours, then contact support and they'll be able to reset it for you. Number eight is you added the name servers at your Registrar, but you left the other ones there as well. Now you have three or four name servers. We've seen as many as a half a dozen different name servers show up, it seems, sometimes. A dig against the name server from a terminal window is going to show that and all you need to do is to remove the non-Cloudflare name servers at your domain Registrar. Point nine is timing. It's the Internet. Sometimes things take a little bit longer than what you anticipate to be able to propagate globally. And there are a number of tools that we show on the community to be able to test these. You can kind of follow along on the propagation of the name server change. Finally, point 10 is you just pick two name servers out of the air and you decided you were going to use those or you use two of them from one of your other Cloudflare accounts. In instances when you do that, your domain is not going to become active on Cloudflare. You're going to still run into issues with the pending name server update, even though you see Cloudflare name servers. So make certain that you're using just the two that are assigned on the DNS tab of the Cloudflare dashboard and that you add the domain to Cloudflare before changing the name servers. So those are the ones that really aren't terribly interesting. The issues that are terribly interesting, really we're going to focus on the threats. And that's where we're going to spend the bulk of the conversation today before we flip to talking about email. The first instance is exemplified by what I think is a really good post here, which is it's basically saying that you change the name server records, but the effect hasn't taken place. What's happened here is that rather than changing the name servers at the domain registrar, sometimes you'll actually add a name server record. And so what we're dealing with is we're looking for authoritative name servers. And I was quite impressed with this particular post. Dom, you took all of the fun out of it because you had basically a response just a few minutes after the original question that indicated the problem. How did you know? How can you tell this and troubleshoot it? So in this case, in this particular thread, the user actually said in their post that they changed NS records, which immediately made me think that they might have added NS records in their DNS rather than changing the name servers at their registrar. So in that post, there was a clue in the original post that led me to believe that that's probably what they'd done. And then using the dig command in a terminal window, you can quickly confirm that that's what the issue is when you still see the authoritative name servers and you see cloudless name servers in the NS records instead. Oh, that's fantastic. That is fantastic. And we see this not infrequently. It's probably not the most common problem that folks have. But it almost feels like people are overthinking it or putting too much effort into making the change sometimes. Yeah, for sure. Definitely. That's a fun, that's an interesting one. So the next one, we're going to take a look at this one. This is DNSSEC. And this is also one that seems quite troublesome because you're familiar with Cloudflare. You've added a number of domains to Cloudflare. You added this domain, and now you're not getting any sort of results out of it. DNSSEC needs to be disabled before you change the name servers. You can re-enable it afterwards, but it needs to be disabled beforehand and then make the change. DNSSEC is becoming increasingly more common as a problem. You can do a simple whois, and you'll usually see some information about DNSSEC. There's a number of visualization tools that you can use that we show on the community that you can use. And I think later in the episode today, we're going to be looking at the diagnostic center from Cloudflare, and DNSSEC can also be tested on that. So we'll take a look at that as well. This is the next one, which is the classic gotcha. There is a typo in your name servers. You're certain you typed the name servers properly, but the update still is pending. Your site's not becoming active on Cloudflare, and it's really, really difficult to troubleshoot and to track down. This example post has a really good instance of a typo because it's one that's hard to see. In fact, it took a number of people contributing on the conversation to be able to point out. And if you look at the name servers, they look fairly straightforward. It's Adele and Rocco, and everything's fairly straightforward. They look quite fine. They have a name server. They say Cloudflare and .cm. And so typographical errors like that are difficult to find. The difference between an L and an I are difficult to find. The pipe bar versus an L is difficult to track down. So typographical errors are just a pain. And the reality is that the best solution to solve them is the classic copy -paste. So rather than worrying about typing the names correctly, because sometimes they're really simple names like Tim, and you think you can type it quite easily. But when the typos get introduced, they're hard to go back and to find later. And so it's one that you will want to see. And, again, the test against it is just copy-paste, and that way you don't need to worry about it. This is another example of one that comes up increasingly frequently on the community. And there are particular considerations for EU registrar domains. The registrars in Europe are attempting to validate the name servers before they make the change. If the domain was active on Cloudflare beforehand, what typically happens is the old name servers will respond. This post is a great example of it. So it's using Jerry and Lina, but Bella and Darla are what have been assigned. So the issue here is that the old name servers are still responding. So you've only got a couple of different choices in terms of how you're going to deal with this. The first is you need to contact your domain registrar and see if you can encourage or cajole them to make the change for you. The next is to contact Cloudflare support. And the community can't assist you with this, but Cloudflare support can. Contact Cloudflare support and ask them to purge the domain, the old domain with the old name servers. And that will take a little bit of time, but then you'll be able to add the domain successfully into Cloudflare. Again, we're seeing this increasingly more often. And it's one that if you're based in working with the European registrar, you're going to hit this quite frequently. Another one that folks hit, and this one we actually talk about a lot, it probably comes up every day on the community, is there was something that was going on with the domain registrar, and there was some sort of a hold on there. And typically these will be expressed as a client hold from ICANN, and it prevents it from being changed. So in order to clear these, you need to clear the ICANN hold before you're going to be able to add the domain to Cloudflare. You can find this again through a Whois, and it will actually even give you a link to the ICANN page that's going to explain why that error is there. But these are sometimes difficult to spot because you don't think that there's necessarily an issue with the domain. It's not something that folks are used to interacting with on a normal basis, so it's not something that you're going to check. If your domain isn't becoming active on Cloudflare, it's not necessarily the first thing you go through. Generally, between a DIG and a Whois, you can isolate most of these problems pretty quickly in the community. At this point, what I'd like to do is we would like to go back and we want to start talking to some of the email issues that we had. And we'd identified a bunch of the email issues, and we want to talk through some of those. Don, do you want to talk through some of the email issues with us and see if we can figure out what folks do in these instances? Yeah, so questions about email do come up a lot on the community. It can happen where people set their domain up on Cloudflare and they change the name servers, fine. But usually due to some kind of misconfiguration, their emails don't work as expected. And we have a community tutorial on the community on mail troubleshooting. And this is actually the second most popular tutorial on there, and it's referred to a lot. So I'm just going to briefly run through the points in the tutorial and go into some detail on how you can find the issues and how to fix them. The first two steps in the tutorial cover MX records. So mail exchanger or MX records needs to tell the sending mail server which mail servers accept incoming mail to your domain and where it should be routed to. The Cloudflare's diagnostic center is actually really good for the first stage of the troubleshooting. In this example, you can see if we scroll down to the check for MX records, it's returning the domain does not have an MX record. So this is a great first step to take is that if you don't have an MX record, then emails to your domain aren't going to be going anywhere. Because that record is needed to tell the sending mail server where the emails need to go. Hey Dom, if I have a Gmail account, and I see that error, am I to be concerned about it? Is it really an error? So if you've got a Gmail or if you've got an account that's not on your domain, then it won't be an issue. It's just if you move your domain to Cloudflare, and you've got some at your domain emails, whether they're hosted by a provider like G Suite or Microsoft 365, or you're hosting them on the same server as your website, then unless you've got MX records, then the email isn't going to be delivered. So if we look at this example, which is the one I showed in the diagnostic center, you can see that we've got a records, but there's no records with the type MX. So in this case, we would need to add one or more MX records to this domain, and we can do this really easily in Cloudflare. You just click on add record, and you change the type to MX so that it's a mail record. And what goes in the name box depends on what you want after the at symbol in your email address. So if you just want it to be at your domain.com, then in the name box, you put your domain name, or you can use the shorthand, which is the at symbol. But if you want your emails on a subdomain, such as if you want at sales .yourdomain.com email addresses, then you would need to change that name accordingly. And then in the mail server field, this will usually be provided by your email host. And if you're using something like G Suite or Microsoft 365, they will give you a list of multiple MX records that you need to add with different server names in here. And they will give you the priority that you need to set for each one. So and then once you've added the MX records, you might need to add more than one for some hosts, it might just be one. So that's the first thing to check with email is if you've got an MX record, and if you have is whether it's pointing to the right place. The next thing to check is if your MX record points to a host name on your domain or on a domain that you control, then the sending mail server needs to get the IP address of the host name that the MX record points to. So in this case, you can see that we have an MX record for the domain name. And the content of it is pointing to mail dot and then in this case, it's my domain name brokenmail2.cf. But you can see that in this list of DNS records, we don't have a record with the name mail. So this host name of mail isn't going anywhere. So in this case, we would need to add an A record with the name mail pointing to the IP address of the server that's going to be receiving our email. So I'll just use a demo IP address in here. And then one of the most important things second consideration is Cloudflare specific in that you need to ensure that mail related DNS records are not proxied. You can see in this case that by default, the proxy status is proxied. And what that means is if it's proxied through Cloudflare, then the public IP addresses for this host name are going to be Cloudflare and not those of your mail server. So it's important for mail to work that you change this proxy status to DNS only before you add the record. And that is one of the most common things that we see is sometimes people have the right DNS record, but it's proxied. And so when a sending mail server comes to send an email, they're seeing Cloudflare's IPs and not the right IP address for your email server. And in this case, you can see that Cloudflare gives you a warning that the record exposes your origin IP. And if you host your email and your website on the same server, then you are going to have to expose your IP address to be able to receive email. If you use a service like G Suite or Microsoft 365, then it won't be exposing the IP address of your web server. But if you're using shared hosting and you've got both the website and your emails on the one server, then if you have to set it to DNS only, which you do for email, then the IP address is going to be exposed. The final thing is if you've checked that your MX records are correct and you've got the right DNS records and that you've set them to bypass Cloudflare's proxy, you should usually be good to go with email. In a very small number of cases, though, we've seen problems that continue after these steps have been taken. If we just have a look at this example thread, this user had already followed the email troubleshooting tutorial and they'd let us know what they tried, which is really useful. So we know where to start with troubleshooting. And the next stage that I recommended in this case was that they paused Cloudflare on the website, which just means that Cloudflare will still be handling the DNS, but the proxy and Cloudflare services are disabled while we troubleshoot. And in this example, the mail worked OK with Cloudflare paused, but no mail would go through when Cloudflare was enabled. And in this case, it was interesting because, like I showed in the previous example, the proxy usually only causes an issue if the content of your MX record points to a host name of your own domain. But in this user's case, they were pointing to an external email service, but the emails were still not going through when Cloudflare was enabled. So this led me to believe there must be some conflict between the proxy elsewhere on their main website and something on the server side that was affecting the email. And so in this case, their hosting support were really helpful. And they found that the problem was actually with a specific spam routing module that they had installed that was expecting to see the origin IP address when querying the root domain. And so this isn't that common, but in this case, when Cloudflare was enabled, it was seeing Cloudflare's IPs instead of the server's IP, which was stopping the email from coming through. And so the solution here was to update the host name specified in the spam module to one that was not proxied through Cloudflare and which pointed directly to the server. And this is just an example, and there might be another uncommon reason why your emails might not deliver after following the standard troubleshooting steps. But in this case, a discussion on the community combined with assistance from the hosting provider, we were able to get this issue solved. Fantastic. So when folks start talking about email issues, Dom, what are you going to look for? Like, what do you listen for? Like, what are the keywords that you're looking for to try to troubleshoot? The first thing is really to see what they've already tried. So if they've already found the email tutorial and they've already made sure that they haven't got anything proxied, they've got an MX record. The first thing is just to check that those basic things are in place. They've got the MX record to tell the sending mail server where the email needs to go, that they're not proxying it. And just to make sure that they've got that general idea that they need to make sure that it's not proxied through Cloudflare. So that is the key thing. And a lot of users are able to post screenshots of their DNS settings, which is really useful to see because we can quickly see what records are proxied and what aren't. And so that is probably the most common issue. And so the keywords I look for there are just whether they're already talking about the proxy, whether they already know that the proxy needs to be disabled, or whether they haven't done those first few troubleshooting steps that we need to work through. So that's interesting. And I know that the proxy question comes up, and actually it looks like we've gotten a couple that have come in. One was, I don't understand what proxy means. And the other was, and I think this is what the question is being asked from us, but I know that we see it on the community, which is how do I change it? And I think it was expressed a little differently, but we see this come up in the community a lot. And so what do folks do? What does this mean, and what do you do to fix it? So the proxy versus the DNS only is the first thing to understand. And if it's DNS only, then Cloudflare is still providing your DNS. But what it means is that they are sending everything straight to your origin server, and they're not adding any services. They're not adding the firewall. They're not adding their own SSL TLS. Cloudflare are not adding any of their services to that if it's set to DNS only. So the proxy will hide your origin IP. It will display Cloudflare's public IPs instead of the IP address of your origin server. And it will then enable all the Cloudflare settings that you've got set up on your account. So it will enable things like the SSL TLS, the firewall, and any other settings like page rules that you've got configured. So the proxy means that it's going through Cloudflare. And if it's not proxied and it's set to DNS only, then it means it's bypassing Cloudflare and going straight to the server. And the way to change that is if you go into the DNS section of your Cloudflare dashboard, you'll see the list of records. And you'll see a column that says proxy status. And if you click on the record that you want to change, you can click on the orange cloud, which will turn it gray. So orange cloud means it's proxied to Cloudflare. And then the gray cloud means it's set to DNS only. So you click on the orange cloud, and it turns gray. And then you can click save to save that. And there are lots of great resources in the support center and on the community to find out what you can and can't proxy. Because there are certain services like website traffic that Cloudflare can proxy. And then there are other services that by default Cloudflare won't proxy, things like email and that kind of thing. And they're always educated, things like the enterprise plan, you can proxy other protocols. But in general, for most people, it's fairly clear as to what you can and can't proxy. If it's web-based traffic, then you can proxy it. If it's another service like email or FTP or something like that, then it should be set to DNS only. Gotcha. And when folks are setting this up, and I know we see this a lot, and I don't use email on any of my Cloudflare domains. So I've never hit the problem myself. But we do see it come up. Is checking for the MX record the first thing that folks should do? Or do you look at your DNS tab? I set it up on Cloudflare. My email stopped working. What's the first thing I look for? The first thing would be to check whether all your DNS records match the ones that are required. So when you actually configure the domain on Cloudflare, Cloudflare will try and import all your DNS records. And it will check a lot of the most commonly used records. But there might be something that it missed. If you've got an MX record to receive email on an obscure subdomain that perhaps Cloudflare doesn't scan, then you'll need to add that manually. And so when you signed up, you should hopefully have checked the list of DNS records that Cloudflare has imported against the list of your previous providers. If you're using your web host's DNS or if you're using your registrar's DNS, then you just check that the ones that they have configured before you started with Cloudflare match the ones that Cloudflare has imported. And if there are any missing, then to make sure that you add those manually. In the case of mail, an MX record is the first thing to check for because you're not going to get any emails to your domain if you don't have an MX record. Because that is the first thing when a mail server goes to send an email, they will query the name servers for the MX record for that domain to find out where they need to send the emails to. So if you don't have that MX record configured, then no emails are going to be going anywhere. So that's definitely the first thing to look at. Fantastic. Dom, thank you. This is incredibly helpful. I appreciate it. Thank you for joining us again today. Look forward to everyone watching us today, joining us next week on Yesterday Today on the Cloudflare Community. I'm your host of Yesterday Today and a Cloudflare Community Manager, Tim Clunan. Join us next Friday for a new edition starting at 10 a.m. We'll see you here next week at 10, and until then, we'll see you at community.Cloudflare.com. Thank you. Microsoft Mechanics