Internal DNS: The end of the appliance era

Hey guys, how are you doing? Good. Great. Good to see everyone. Thank you for enjoying lunch with me today. We're going to be talking about something really cool. I think so. I've been in the DNS industry for the past 12 years, and every time I hear about internal DNS, it's all about the crazy difference that you have when you run an internal DNS versus your public DNS. So before I get started, let's talk about a little bit, let's do a game. So the game is put your finger down. So for those that have been running DNS for a little while, put your finger down if you blame the networking team, you say, hey, something's not working. But then you quietly went back to your DNS provider and changed the DNS record. Guilty. I've done that. Now, put your finger down if you were working in the office, everything working as expected, then you go home and everything break. But then suddenly you started looking into how you solve DNS because something changed in your internal DNS. And then lastly, put your finger down if you made a change, went to production, everything's working as expected, and then you forgot that you have to do that change in three other places. So that's crazy. And this is pretty normal. You know, we haven't been there. But the idea is that with internal DNS, you just have to think about some of the applications that you're running. So to begin, let's see some of the applications that you run on internal DNS. So the first thing is our Kubernetes services. Those who have the services, we know that DNS changes every hour. Then we also have our HR, we have our payroll systems. Those systems don't change. You know, you set the DNS, you forget about it, 10 years later you have to make a change. So when you think about internal DNS, you need to be able to support these two, not just changes that happen dynamically, but you also have to look into those changes that you have to do every so often as well. Then we have the internal wiki, so where your company data lives. Internal wiki, you need to be able to serve that in the office. You also need to be able to serve that in your home, you know, employees are working from home. The idea is that you don't want to, you know, as a DNS administrator, you don't want to think about where is this responding from. Is this going to internally, is this going externally? So we have a way to be able to do that. Anyone here uses these applications? Yep. Pretty normal. Okay, good. All right, so internal DNS, one of the crazy things is that it's the same protocol. The protocol that you use for public DNS is the same protocol that you use for internal DNS, but they are run in totally different ways. Working at different enterprise companies, I spend time running my internal DNS, one location, one box, and then just leave it running because you didn't want to talk about it. You just want to make sure that everything is running as expected. But then you have, you know, for those big enterprises, you have multiple offices. So what's happening is that the traffic that have to come across the other side of the world is now getting those responses with that longer latency. That means that if you go down all the way to Australia and you serve your internal DNS from the U.S., there is a trip for those on-cache zones. Then on the other side, we have public DNS. You use DNS for the past, I don't know, 20, 25 years. It's all in any cache network. So you answer your queries that's closer to the user. So there is a few things that you have to think about when you run your internal DNS in that way. So the first one is the latency. Again, so you're running everything in one box, and you can have resilience. You can have multiple boxes in the same location. But the problem is that the users, they have to come across for those on-cache queries to be able to get to the answer. Then you have the complexity. So just with my put-your -finger-down game a little while ago, so when you go to your office, you know, you answer the queries from internal DNS. When you go home, you can answer those queries for public DNS. The idea is that at some point in time, if you're using different systems, the answers are going to be different. So one is going to be responding to one IP address, the other one is going to be responding to another IP address. And then the risk that if your internal DNS goes down, there is, you know, people struggling trying to figure out if, you know, where are things broken. It's on the outside Internet, DNS, or the internal DNS. So that's why I'm really excited to introduce the Cloudflare internal DNS. It went GA a few months ago, so we've been working on it for the past few years. With the idea is that you manage your internal and external public and internal DNS in one place. So you use the same UI, you use the same API, everything in one place. You don't really have to worry about, you know, managing that box that's sitting in the closet in your office. So how does it work? Internal DNS runs in the same private net space as SQUAD1 network. So you get the 340 data centers to be able to respond to SQUAD. Now that doesn't mean that you're producing the query over to the public Internet. Everything stays inside. How do we do that? We have a gateway resolver that you get to it, and based on where the client is coming from, you should be able to answer that specific query. And then obviously you take advantage of the public DNS network. With the idea that it's all about managing everything in one place. So remember the issue about having that box and, you know, the latency when someone comes from across the country? With this, you don't have to have that, because you're answering the query wherever it's closer to your user. So how does it work? Very simple. We have three components, the client. So the client tells you, and you can use any of the Warp, Cloudflare 1, IPsec, any tunnel to get to it. The client tells the gateway resolver, hey gateway resolver, this is my user, and I want this user to go here. And I'll show you, I'm going to do a live demo by the way, so you'll see in a second. So the client will say, hey, I'm Enrique, and I'm going to go to my HR system that lives on my policy that matches this specific domain name internally. Now, the gateway resolver has three options. They either find a policy that match, they either can block the policy as well, or there's no match. Spoiler alert, if it doesn't match anything, it would just go routed to the public resolver. Now there's three things that we need to look into. The internal zone, so that's the zone that you create within Cloudflare to be able to hold your internal DNS. That's where you add your A records, your C names, all of the DNS records. Then you have the DNS view. So the DNS view is what tells your policy where you want to go based on where the user is coming from. And I'll show you that in a second as well. So the resolver policy will pick the view to where we want to send the user to. All right, so let's go and do a demo really quick. If you can switch me over. One second, I'll be sure. All right, I'm just getting there. All right, so for this demo, and before I jump into it so that you guys know what we're doing, think about a company that has multiple locations across the world. So we're going to be talking about employees coming from the US. We're also going to be talking about employees coming from Germany. At the same time, we're going to be running a split horizon. What that means is that we're going to be using the same host name so that we wanted to respond in the public DNS specific way. But if we notice that the client is coming from internal, we're going to be responding in a different way. So there's two things we're going to do. We're going to create a policy for the employees in the US and a policy for the employees in Germany. Very simple. The first thing I'm going to do, I'm just going to go into my demo account. We're going to be working with developeracademy.co as a domain name. The first thing I'm going to do, I'm going to create a public view. So this is normal. This is why if you have Cloudflare DNS, this is what you do. So we're just going to add a record really quick. This case is going to be app.connect. We're just going to send it to this specific public IP address. Click Save. And at this point, we created the public record. Now I'm going to go into internal DNS, and I'm going to create the same zone. So I go to internal DNS. We're going to create an internal zone. We're going to call this app.connect as well. Once we do that, we're going to add the records. So the first record we're going to add is going to be a record. It's going to be app. And we're going to send it to a private network or a private IP. So in this case, 10.10.10.10. So we save the record. And at this point, we have the public record. We have the internal record. And we are going to create a view. So the first view I'm going to create, it's a view for our employees in the US. So I'm just going to call it connect.us so that we can see where they're coming from. And now we're going to be assigning that specific zone to our view. So click Save. Now we have that specific view. Now once we have the view, so we've got two steps. So we created the public DNS. We created the internal zone. We assigned that zone to a specific view. So the last step is go to the gateway resolver and create a policy. So I'm just going to click in there, go to Gateway Resolver. Going to add a policy. Now here's where the fun begins. So you're creating a policy for a specific domain name. Select domain name, and it's is. And then from there, we're just going to use app. Now we're just going to use connect developeracademy.co. Now, so that's our first condition. So we want, for this policy, we want all the conditions that matches this domain name in connect .developeracademy.co. And then we're going to add our source IP geolocation. Again, we're creating the policy for the employees in the US. So it's going to click this, United States. Now, once we do that, so we've got our conditions. So the second part, it's how do we want it to resolve. There is a few options there. But in our case, we're going to pick use internal DNS. And we're going to select the view that we just created. So create the view. We're just going to add a name here, a description. We're going to create a policy. All right, so at this point, so you guys can follow where we are, so we have our public view, where if a user is not coming from internal, they'll go to that specific IP address. Now, we have a zone for the employees in the US. We created a view for the employees in the US, and we added a policy for the employees in the US. Now, every single employee that comes from internal network that goes through, that they have an IP from the US, is going to go into this specific policy. So the other thing we're going to do is we're going to create a policy for our employees in Germany. So just go here. Actually, just show you that the view is not linked to our connect policy over here. I'm going to create a second zone. Actually, I'm going to change that. OK, perfect. So now, we're going to create a second record. Now, this record is for our employees in Germany. So what we're going to do is we're going to change the IP address that we're going to be sending the users to. Again, so the 10.10.10.10 was for the US employees. 10.20.10.10 is for our employees in Germany. So that's telling us from the internal DNS, hey, I want all these users, if they're coming from Germany, go to this specific IP address. Obviously, there is reasons to do that. They have databases. They have systems that you allow employees to go through Germany or the US based on that specific role. So we save the record. What we're going to do next is we're going to create the view. So we are going to create our connect Germany view. And we're going to assign that specific zone to the view that we just created. So now that we have the view, we're going to go into creating the policy. Again, so this is create the policy, the rules that tells how to handle the user, depending where they're coming from. So again, just go to policy. We're going to select domain. It's in the same domain name. And in this case, for our geolocation, we're going to be selecting Germany. For the resolver, we're going to select the other view that we just created. So Germany, create policy. Oh, we've got to go add the name in the description as well. So all right, so so far, we have a public view. So for those external users, they'll go to our public Internet. We created two specific views, so two different zones for employees in the US and employees in Germany. The last thing we're going to do is create how do we want the internal DNS to behave if a user is coming from, let's say, Australia. So something like a catch -all. So if the user is not coming from the US or from Germany, we want to go to this specific address. In my case, I don't want it to resolve. I just want them to provide a specific answer. So to do that, we're just going to create a view. So create a view. In this case, we're just going to call it Connect Unmatched. So this is for those users that are not matching our criteria of the US or Germany. And we're not going to select any zone, because again, we don't want it to respond anywhere. And then from there, we're just going to create a policy. So we add the policy. Again, we're going to pick the domain. We want it to be N. I'm just going to select that. All right, Connect. Oh, it doesn't matter. So we're just going to give it a name. Once we give it a name and a description, I'm just going to do this over here. I'm going to create a policy. So now, we're going to create a policy. So now, we have two different policies. And the way it resolves our policies work, it's based on their order. So what I'm going to do is just going to keep the US at the top, then Germany as second, and then all the ones that doesn't match any of the previous policies, it's just going to go into the Connect demo unmatched. And that's it. So so far, we created our different zones. We created an internal view, the two internal views. And then, we also created how we wanted to respond in a scenario where it's going to be a split -heart scenario. And if we can switch back to the presentation. Thank you. And I know we only have a few more minutes. So I think I'd rather see if you guys have any questions before we get going. Any questions about? Oh, yeah, that's a good one. It said, what if the servers work? Yeah, it will work the same way. So if you have, again, so internally, in this app, APIs, and you just use it the same way. If you have a server that's connected to a client, you said warp or using tunnel, it will redirect to where you want it to go from whatever they're coming from. So policy has specific settings. So if this is a mail server or things like that, it will use the same policies to go through as well. Yes, there is an IP address that you will use to do that, yeah. Yes. Depending on how you have your own ramp, that's where you used to be able to get there. Yeah. Yes. You mentioned handling Kubernetes for that. How it's dynamically getting there, like you just saw how we did that. Yeah. So the cool thing is that internal DNS uses the same API, uses the same technology that we use at public DNS. So if you do it through API or if you do it through CI as well, you'll be able to get to those changes as if you're deploying in another server or so. So think about Terraform as to call out to about there. Right. Think about Terraform. Think about that specific way of how you handle it. It works the same way as if you're making a public DNS record. But not over standard DNS protocol. It's about their API. Right. Yeah, you still have to go through the gateway to be able to get to our stuff. Again, so those internal DNS, it doesn't ever public our songs to the Internet. You have to go through a client. You have to go through us to be able to get to it. Even though we do take advantage of having the 340 data centers to be able to get to internal DNS as well. The idea is that we want you guys to manage everything in one place. Rather than going back and having two different systems that you have to change, with internal DNS and public DNS, you can do it at the same time. So if something have to happen, use the same API. There's just a flag that says, hey, this is internal DNS. And then we'll go from there. Yep. Any other questions? Oh. Yeah. Can this replace the VPC resolver that I run, let's say, on an Amazon VPC? Can this replace a VPC resolver that I run inside? Yeah, absolutely. Yeah, it works the same way. Again, think about having all of the functions that you have with public DNS into your internal DNS. With the difference, we never publish that zone over to the Internet. It has to go through your client. It has to go through your connection. So then I would have to run a Cloudflare tunnel inside my VPC and then route that DNS traffic through the Cloudflare tunnel? So the gateway resolver is the one that makes all the decisions. You don't have to run anything. You know, we do it through our gateway resolver and the policies that we create based on how do you want to answer your users. Got you. Is this related to ZTNA or is it a different product? So good news. If you have an enterprise gateway resolver, internal DNS comes with it. You don't have to pay anything for it. So if you're an enterprise customer with the gateway resolver, internal DNS should be available in your accounts already. No extra money, no extra fees. We take care of it through the gateway resolver. How does it handle dynamic updates from Active Directory? For what, sorry? Active Directory. We don't do that just yet. If you're looking for a DDI solution, that's something that I'm especially working on. And we're going to be talking about that in the next few months or so. OK. In a similar vein, can you choose to use a separate DNS server returned besides Cloudflare's public or internal? Like if you had a separate internal server, would you be able to say? If you want to have the policies, the views in place, it has to be a gateway resolver because that's kind of the brain that decides. OK, so I know this user is coming from the US. And I want this user to go to this specific view. So to do that, I have to go through the gateway resolver, a Cloudflare gateway resolver. Now, where do you end up to? If it's going to be on a private server in Australia, it's going to be a private server in the US. That's up to you and your DNS settings. Is it an efficient way to migrate buying our infobox to internal DNS? Sorry, can you repeat that one more time? So for a lot of organizations, we have buying infobox. It's a way to efficiently migrate? Absolutely, yes. So that's a perfect segue because there's triggering that allows you to stop using your buying box in your offices, the stuff that you're managing internally. The idea is that you don't have to worry about that anymore. We're handling that for you. We want to make sure that you're handling the DNS queries. You don't have to worry about what runs the DNS, especially when we talk about having those specific boxes that were built 20 years ago that somehow still work and somehow you have to patch every so often as well. So that will replace anything that you have internally using your internal DNS. Yes? I apologize if I already covered this because I couldn't hear some of the first few questions. So I assume these gateway boxes live in your network somewhere locally. Can you speak up a little bit? Sorry, what's that? Can you speak up a little bit? Yeah, if the connection to the gateway boxes, the connection from there to Cloudflare gets interrupted, is there some level of caching or continuation that happens that your DNS doesn't go poof? Yeah, absolutely. So again, so we build internal DNS on the same features and functions that we have for our public DNS. So that will include caching. That will include everything that our public DNS has. Obviously, in Cloudflare, we've been doing this for the past 20 years, so we have other features that will also apply to internal DNS as well. So yes? Hi. So do you sell us for more DNS? Good question, yes. So it depends what forwarding you're talking about. Can you tell me a little bit more? So are you thinking about an HTTP to an HTTPS, or what are you thinking about? Like, let's say there's an express route, we either ask for it or we store it, we dump the internal DNS. Yes, so that will also be included, and you do that to a gateway resolver as well. Can you repeat the question? Yeah, she was asking about forwarding. So if you can do internal DNS forwarding, if you can do forward with internal DNS. The answer to that is yes, we do it with the gateway resolver and the policies that you create in Vue as well. Someone needs to listen to your question. Yes, sir. The question was if it includes the conditional forwarder options. Yes. Any other questions? I saw you create a domain, so where is the routine policy? Say that again? Routine policy. Routing policy? Yeah. So that's up to you. Again, so the policy is the brain that allows a user to decide how that query needs to be answered. Good news, you use gateway resolver, a product that runs everywhere as well with tons of policies that you can create. The idea is that we are utilizing that, and based on that, you can send the user to wherever you want it to go internally within your organization. All right, so just really quick, I think we're a little bit over time, maybe, but just a quick recap. So to create an internal zone, three steps, you create a zone, you create the Vue, then you write your policy, and that's it. You don't have to worry about anything else. You don't have to worry where is it running. You don't have to worry about how is this going to be responding. Cool thing that it uses the same API, it uses the same system as public DNS, so if you're running DNS with us, adding your internal DNS is super easy. And again, the good thing, too, is that it comes with your gateway resolver enterprise, and you don't have to pay us any extra money to that. All right, well, that's it. Thank you very much. Don't forget to give us some feedback. If you have any questions, I'll be here, happy to answer anything else, and if not, please reach out. I'm happy to help you with internal DNS.