0:02Hey, guys, how are you doing? 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, 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.

0:52Guilty. I've done that. Now, put your finger down. down if you were working in the office, everything worked 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.

1:13And 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 changed 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.

1:43So to begin, let's see some of the applications that you run on internal DNS. So the first thing is, are we Kubernetes services. Those that have the services, we know that DNS changes every hour. Then we also have our HR, we have our payroll systems, and those systems don't change. 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.

2:33You 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.

2:57All right, so internal DNS.

3:01One 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. You're not working at different enterprise companies. I spent 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, 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 US, there is a trip for those uncached zones.

3:56Then 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.

4:13So 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 you have to come across for those on cache queries to be able to get to the answer. Then you have the complexity. with my put your finger down game a little while ago. So when you go to your office, 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.

4:59So one is going to be responding to one IP address. The other one's going to be responding to another IP address. And then the risk that if your internal DNS goes down, there is people struggling trying to figure out if, you know, where are things working. 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. What the idea is that you manage your internal and external you know, public and internet. 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 managing that box that's sitting in the closet in your office.

5:49So how does it work? Internal DNS runs in the same private space as Squad One Network. So you get the 340 data centers to be able to respond to this query. Now, that doesn't mean that you're in 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 legacy when someone problem comes from across the country.

6:35With this, you don't have to have that, because you're answering the query wherever it's closer to your user.

6:43So 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 one, IPsec, any tunnel to get to it. The client tells the gateway resolver. Hey, gateway resolver, this is my user. this user to go here. And I'll show you. I'm going to do a live demo, by the way, so you 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 matches, they either can block the policy as well, or there's Spoiler alert, if it doesn't match anything, it would just go routed to the public resolver.

7:37Now, there are three things that we need to look into. The internal zone, so that's the zone that you're creating within Cloudflare to be able to hold your internal DNS. That's where you add your A records, your CNames, 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.

8:09All right, so let's go and do a demo really quick. If you can switch me over.

8:25One second, we'll share.

8:40All right, just get in there.

8:44All 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 the world. So we're going to be talking about employees coming from the U.S. 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 U.S. a policy for the employees, say, in Germany.

9:25Very 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 And the first thing I'm going to do, I'm going to create the 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 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 gonna be creating internal zone when I call this apta connect as well once we do that we're going to add the records so the first record we're going to add it's going to be a record it's going to be up

10:19and we're going to send it to a private network or a private IP. So in this case, 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 is a view for our employees in the US.

10:46So 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 we click Save. Now we have the specific view. Now once we have the view, so we 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 you're 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.

11:32Select domain name, and it's is. And then from there, we're just going to use app.

11:44Now we're just going to use ConnectDeveloperAcademy.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. is United States.

12:13Now, once we do that, so we 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.

12:39We're going to create a policy.

12:43All 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 the 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.

13:17So the other thing we're going to do is we're going to create a policy for our employees in Germany. Just go here.

13:29Actually, just show you that the view is not linked to our Connect. a policy over here.

13:42I'm going to create a second zone.

13:48Actually, 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 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 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 are 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. So what we're going to do next is we're going to create the view.

14:35So we are going to create or connect Germany view.

14:48And we're going to assign that specific zone to the view that we just created.

14:56So 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, S and get the same domain name. And in this case, for a geolocation, we're going to be selecting Germany.

15:32For the resolver, we're going to select the other view that we just created. So Germany, great policy. Oh, we're going to go out the name in the description as well.

15:52All right. So far. Or we have a public view. So for those external users that 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.

16:38In this case, we're just going to call it Connect Unmatched. So this is for those users that are 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 the policy.

16:56So we add the policy. Again, we're going to pick the domain.

17:05Want it to be in. Just going to select that.

17:17It doesn't matter. So we're just going to give it a name. Once we give it a name in a description,

17:27I'm just going to do this over here. I'm going to create a policy. So now we have two different policies. And the way resolver 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. to go into the Connect demo on Match.

17:54And 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 horizontal scenario.

18:13Right. And if we can switch back to the presentation.

18:20Thank 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.

18:31Any questions about? Oh, you're at the . The servers work. Yeah, it will work the same way. So if you have, again, so internal DNS of APIs and you use . use it the same way. If you have a server that's connected to a client, use a warp or use a tunnel, it will redirect to where you want it to go from, wherever 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. Like where is the my server at? Where is the IP address? Yes, there is an IP address that we used to do that. Yes, look at that. depending on where you have your own ramp that's where you used to be able to get there yeah yes

19:21yeah

19:26so the cool thing is that internal dns uses the same api uses the same technology through that we use our public dns so if you do it through api 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. S2 call out to about there. 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 a standard DNS group call. It's about there. Right, you still have to go through the gateway to be able to get to our stuff.

20:13Again, so those internal DNS, it doesn't ever public our zones 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. 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 has 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.

20:52Any other questions?

20:56Can this replace the VPC resolver that I run, let's say, on Amazon VPC? Can this replace 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 cloud fair tunnel inside my VPC and then route that DNS traffic through the... So the gateway resolver is the one that makes all the decisions. You don't have to run anything. We do it through our gateway resolver and the policies that we create based on how do you want to answer your users.

21:53Is this related to ZTNA or is it a different product? So, good news uh if you have uh enterprise gateway resolver uh internal dns comes with it you don't have to pay any for it so if you're enterprise customer with the gateway resolver internal dns should be available in your accounts already no extra money no extra fees you know we take care of it through the gateway resolver how does it handle um dynamic updates from active directory for when sorry active directory active we done 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.

22:40In a similar vein, can you choose to use a separate DNS server returned besides Cloud Flare's public or internal? Like, if you had a separate internal server, would you be able to?

22:58If 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, okay, 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 you end up to, if it's going to be on a private server in Australia, to be a private server in the U.S., that's up to you and your DNS settings.

23:30Is it an efficient way to migrate, like, buying or info box to internal DNS? Sorry, can you repeat that one more time? So, like, for a lot of organizations, we have, like, buying or info box. It's a way to efficiently migrate. Absolutely, yes. So that's a perfect segue. Because there is a triggering that allows you to stop using your bind box in your offices, the staff 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 will still work and somehow you have to patch.

24:19so often as well so that will replace anything that you have internally using you know your internal dns yes i apologize if you already covered this because i couldn't hear some of the first few questions but um so i assume these these gateway boxes live on your um in your network somewhere locally if can you speak up a little bit sorry what's that can you speak up a little bit 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 so that your DNS doesn't go poof? Yeah, absolutely. So again, we build internal DNS on the same features and functions that we have for our public DNS.

25:08So that will include caching. That will include everything that our public DNS has. Obviously, in Cloudflare, we've been doing this for a past. 20 years, so we have all the features that will also apply to internal DNS as well. So, yes.

25:31Good question. Yes. So it depends. It depends what forwarding you're talking about. Can you tell me a little bit more? So you're thinking about an HTTP to an HTTPS or... What are you thinking about? Like, if there's an express route, we either ask her or able to store it, we come to internal Yes, so that will also be included, and you do that to a gateway resolver as well. Gateway with the records. 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, you know, we do it with the policy, with the gateway resolver and the policies that you create in Vue as well. Someone needs to... listen you are Christian so on yes sir the question was is if it includes the conditional forwarder options any other questions I saw your created domain so where is the routine policy so there again a routine policy writing 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.

26:47Good news, you use Gateway Resolver, our 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 whatever you want it to go internally within your organization.

27:10All 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 the zone. You create the view. 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's this going to be responding. Cool thing. that it uses the same API, it uses the same system as our 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.

27:54All 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. happy to help you with internal DNS.