Azure DNS Private Resolver Deep Dive

hey everyone in this video i want to talk about the azure dns private resolver capability solving a number of challenges we had in the past about resolving azure private dns zones from our own dns servers and forwarding from azure dns to our dns servers so we're going to address both of those challenges as always a like and subscribe is appreciated so take a step back if i think about in azure we have the idea of a virtual network so i have my v-net and for resources that deploy into my virtual network we have the nice azure dns service that is used by default now the way we can communicate to that is there is an ip address to every virtual network it's always this 168.63.129.16. so from within a virtual network if i talk to this ip address it's actually going to go and talk to azure dns this just built-in native dns service and one of the things we commonly do is we create azure private dns zones so i can create these as resources and this private dns zone could be some custom name that i'm creating x dot net whatever that is and then i have various records that are supported within there or maybe it's part of private link it's something dot private blob dot core dot windows dot net all the other services and azure is automatically gonna publish records into there as it creates private endpoints into our virtual network and of course dns is a core part of private link functioning and so what i can do is when i create those private dns zones well i link them to one or more virtual networks and then when i query azure dns well because it's linked to that v-net it will now resolve names that are part of that so all is well all is happy if i'm sitting within that virtual network i'm sitting in azure all is good what about though if i have my own custom dns as well maybe running active directory domain controllers and i have dns running on those well if that dns server that custom dns is running in azure it's really not that bad because i could change the v-net to use custom dns and point to the ip address of whatever this was and then it could forward to 168 63.12916 for all the things that azure dns knows about like my private dns zones so that's a very simple solution because it lives in azure so it can talk to this address so i can either do just forwarding i could do conditional folding all is well but what if that's not my scenario what if instead my scenario is hey i'm on premises so i have some on-premises environment and i've got some dns here which again has its own ip address in this network and it has certain zones that it is authoritative for now i've connected these together there's some connection between these networks this is going to be the case for all the things we talk about this connection could be a site site-to-site vpn it could be a point-to-site vpn that's probably not likely could be express rail private peering basically i'm enabling ip routing and a path between my on-premises network and azure but i can't forward to 1686312916 it's a special address that only exists in the v-net so if i wanted to have a custom dns to resolve records in my azure private dns zones that were linked to the v-net i have to deploy something extra i have to deploy for example a dns forder which has an ip address and then i configure my dns to either conditionally forward or forward to this and then it can then talk to the 16863 because it's sitting in the virtual network so there were ways to solve it but it was kind of ugly i'm having to maintain these various things and then maybe it's the inverse what if i wanted to use azure dns but i did have some zones that were hosted on my own dns servers that i wanted this to be out of 4.2 there was really no way to achieve that so what we're going to now look at is this azure dns private resolver that solves both of these challenges so what we're going to think about is this new type of resource and it's actually multiple new types of resources and what i want to do is actually as we go through this we'll create one in the portal so if i was to jump over to the portal super quickly this is the special because it's in preview as i'm recording this but we have this new dns private resolvers and i'm going to go ahead and create a new one so what we see straight away is okay i have to create it in a resource group i've done this before and i deleted it so my dns folder resource group i give it a name this is a regional resource so this is my south central dns resolver it lives in south central so it's getting deployed into a specific region and then it gets deployed basically into a virtual network so i'm going to use my v-net has to be in the same region in south central so it's its own object now the first thing we have the option of doing is adding an inbound endpoint so i'm going to say okay this is my inbound my bd dns you can see i've already done this before so i'm just going to reuse the same one i did before private dns in endpoint now it binds to a subnet and if i hit save so i'm creating an inbound endpoint so let's think about what we're doing so far so thing we're doing is we're going to create this new type of resource so we're deploying an object it's a resource a private resolver which is an azure dns private resolver and these are all regional so a key thing to think about the v-net and the other things we do make it a little bit bigger these are regional i cannot span regions with this today so these are regional they're all in the same region so i'm going to create this private resolver resource now in the portal it's actually going to go ahead and create a bunch of different resources for me if i was doing it for a template or powershell i'm creating each of them individually so the first thing it wants is an inbound endpoint so i have to have a dedicated subnet so that's an important point here so i'm going to have a particular subnet that i'm going to use let's clean up that arrow because it's going to get confusing it's a particular subnet for in this case my inbound endpoint now i can have multiple endpoints each one of them would require their own subnet this is dedicated per endpoint the minimum is a slash 28 the recommendation is to do a slash 24. it gives me that ability to scale in the future you can think about well how many queries per second am i going to need to handle so i may want to have that additional ability to grow and so what we're going to do here is we're going to add an impound endpoint so it's now basically creating and using an ip from this subnet that goes to this private resolver so this is adding the inbound endpoint well at this point there's now an ip address that exists in my virtual network it's a regular ip address that's routable just over regular ip connected networks will now route to this and what this is basically now doing is via this well it goes and resolves against azure dns so what can i do well instead of having to mess around with this old dns forwarder and doing manual stuff which i really don't want to do well i can kill off all of that and instead of forwarding to this my on-premises dns hey fantastic what i'm now going to do is forward over here now this could just be forwarding everything that it's not forward to for so hey i don't have an answer in my zones send it to here which will send it to the dns resolver which sends it to azure dns or this could be conditional forwarding you have a choice i.e hey only ford if it's x.net then forward it to the ip address that it's adding in that subnet so you can think about this is solving the idea of from dns servers that exist outside azure could be on premises could be in other clouds whatever that is as long as it has a ip path there's a connection to this v-net i can now forward from my custom dns servers to the ip address it's creating via that inbound endpoint to now resolve against azure dns and resolve records in those private dns custom ones private link whatever i need and again i could add additional endpoints if i wanted to maybe for scale purposes maybe i've got different business units are going to use this i want to build back so i'd create a different endpoint if i added a second inbound endpoint it has to be a different subnet it's one dedicated subnet per endpoint i can't share them so this is solving the idea of hey i want to resolve to azure dns from outside the virtual network without having to manually worry about dns forwarders deploying it's just doing that for me and i could absolutely stop there i can say that's all i needed hey that's the functionality i need from the azure dns private resolver but then there's a second part of functionality i may want and that's the idea that hey i'm using azure dns but i have some records some zones hosted on my own custom dns servers it could be in azure it could be on premises that have ip addresses so from azure dns i want to be able to forward to other dns servers that host those zones and today there's no way to do that well that's the next part of what we can configure in the portal so once we've added optionally remember i don't have to do this maybe i don't want the inbound functionality i have a choice if i want to enable this functionality or not but i'm going to say yes i want to add an inbound endpoint now i can optionally add outbound endpoints so once again um let's just do outbound i didn't use consistent naming notice the subnet i picked for my inbound is now grayed out can't use the same one i have to pick a different subnet and i'm using slash 24 so i've got future scale i'll save that so it now has an outbound endpoint now this point you might be wondering what earth do i need an outbound endpoint so let's think that through so azure dns is this azure service it's floating out there it goes and links to these private zones through resolution i'm now in a scenario i have my own dns server my own dns server has an ip address that i appear address might be on my virtual network it might be on a different network that's connected via my virtual network so i have to be able to talk to it well azure dns has no existence in this virtual network i might not have an inbound endpoint and it doesn't want to do dual duty anyway so it needs an ip address that it can use to communicate two things via ip so the way we do that is well okay we're now going to add so it needs its own subnet again a second dedicated subnet so this is going to be for my outbound and once again i can add multiple outbound end points if i wanted to and once again it could be a slash 28 the recommendation though is to use a slash 24. and once again it's going to create an ip address and this is now an outbound endpoint and this is the important part so think about when i'm going to go and now have some records to say hey i want to query another dns server if i'm a client and i'm querying azure dns this solution is not going to afford my client to say hey go and talk to this dns server no azure dns is going to go and talk to the dns server on my behalf and it's going to go and get the answer and give it straight to me so azure dns has to have a path to get to the dns server it's going to fall to so when i go and query azure dns for some record that's hosted on this dns server or this dns server what's going to happen is this private resolver using this ip address will now go and communicate to that dns server to get me the answer or communicate over the site to site vpn or express route and talk to this dns server to get the answer so it's using the outbound endpoint to get me ipconnectivity to the dns servers i'm actually conditionally forwarding to to query the record so it can answer that requesting client it's not pointing the client to a different dns server so the client needs the connectivity it doesn't azure dns needs the connectivity so it can go and have a path to query it so that's why it needs that outbound endpoint again i could add additional ones for scale again maybe multiple business units i want to be able to charge back in in certain scenarios so it has an outbound endpoint um but what am i conditionally forwarding so then the next part if we actually go and looked in the portal is once i've created that outbound endpoint i have to create a rule set now i could do this later on but this rule set is a separate resource again the portal is doing it all for me but it's a separate resource now notice i have to bind it to an end point because that rule set obviously hey i'm going to set a bunch of rules how does it talk to the servers as we know hey the way it talks to the servers is going to use the outbound endpoint so what i'm going to do now is i'm going to go ahead and create this idea of a dns forward rule set which is just going to be a bunch of rules you have that whole idea of okay well the zone you want to talk to and kind of the ip address and then it will kind of be the ip address so i have to create the dns rule set and i'm going to bind it to an outbound endpoint because that's how it's actually going to go and do the communication so it's a separate resource but it's going to get bound to an outbound endpoint of a particular private resolver so that when it has to do these forwarding rules it can go and use that ip to go and talk to the dns to get the answer to give to the requesting client so if we continue this through so okay so i've bound it to a certain endpoint and then well i add rules i can add multiple walls hey my rule name maybe it's savile techcom is hosted on my zone what is the domain the dns zone so it's saviletech.com and then you end with a dot i'm going to enable it i have to add the destination well this is hosted on 10.0.1.10 notice it's destination port 53 and maybe i've got multiple servers it can also go to 10.0.1.11 and i can add that and i can add multiple rules so i can go through and add the various rules and what's happening is this is by default just linking it to this particular virtual network so as i'm going through the portal what it's now going to do is yes i'm creating this dns folding rule set and it's also going to take this rule set with all the various rules that i'm adding to it and it's going to link it to the virtual network and that's really that kind of complete picture so now it's linked these forwarding rules to the virtual network in the same way i link private dns zones to a virtual network when anything in this virtual network now queries azure dns for something in one of these zones i've added as rules well as your dns now knows about it it will go to the private resolver which will use the outbound endpoint to go and query the dns server i've specified get the answer and then give it back to the client so that's the key idea of this now i may have a hubspoke pattern this might be my hub where i deploy the dns private resolver i may have other virtual networks well if i have kind of spoke virtual networks here i would link this to them as well so they have the same common sets of conditional forwarding now this they have to be the same region so i'm drawing this all in the same region these are regional resources commonly these are going to be peered that's normal and so i want them to have a common set of conditional forwardings have the same resolution so they're all going to have the same for every pier i'd probably link the same forwarding rule set to all of those spoke virtual networks they're all consistent but it actually doesn't have to be peered because remember what's the flow of communication let's say i linked this rule set to a virtual network that wasn't peered to this hub would it still work absolutely it would because what's the communication path i've linked the rule set a client in here talks to azure dns hey saviletech.com azure dns savvilletech.com because remember i've linked this rule set okay it knows it's handled by this outbound endpoint of this private resolver so azure dns cloud service has the rule that says okay for this zone talk to this outbound endpoint and use it so it will use the outbound endpoint to go and get the answer and then buy azure dns give it back to the client in this virtual network so this virtual network doesn't actually need ip connectivity to the dns servers that the conditioning forwarding rule applies because it's not the client that gets redirected azure dns is doing the lookup for me so typically yes they're going to be peered because i probably have a hubspoke model and so they've got that common but if it wasn't that scenario if this was just a v-net but it still did need resolution from those dns servers it doesn't have to have an ip path to those dns servers it's not required it's going to be the normal case but it doesn't need it because the dns path is not going from the client to the dns server the path is hey i'm talking to azure dns azure dns has the forwarding rule because it's linked to the virtual network the rule set is bound to this outbound endpoint at the private resolver and it talks via that and then azure dns gives me the answer so that's really kind of the key point of this and again i use as much or as little as as this as i want maybe i just need the inbound i have my own dns services that i want to be able to resolve records in private dns zones great i just deploy the inbound endpoint part maybe i only need hey from azure dns talking to my dns servers hey i don't deploy an inbound endpoint i only deploy the outbound endpoint and the ns forwarding rule sets i have to have the rule set outbound endpoint on its own is useless i have to have the outbound the rule set to actually tell it what to forward to i could just use the outbound and the rule set or hey i want both sets of that functionality i deploy as much or as little as that as i actually want um it does have to be the same region so if i had multiple regions today well i'm obviously i need a dns private resolver in avena in that region and today the forwarding wall say i'd have to create in the other regions as well don't know what's happening in the future but that's where it is today the scale i would expect to also come into play later on today is i think a fixed scale but i would imagine over time hey based on how many queries per second i'm doing there'll be some scale mechanism in play the documentation says hey it can be a 28 but 24 is recommended the only reason it would recommend a potential bigger one is because it intends to scale things inside those subnets so i think it's fairly plain to see at some point there probably be some scale functionality but that's it that's what the azure dns private resolver does it removes me having to hey if i want to from my dns servers outside of azure resolve private dns zones i don't have to manage some custom dns folder and now i can actually forward from azure dns to zones hosted on my dns servers be in azure or outside azure the v-net doesn't actually need a path the only path i need to the custom dns servers is the outbound point that is bound to the dns forwarding rule set so that's it i hope that kind of explained what this is why you'd use it and as always till next video take care you

Channel: John Savill's Technical Training

Views: 43,447

Keywords: azure, azure cloud, microsoft azure, microsoft, cloud, dns

Id: V8ChsYAyxTc

Length: 24min 49sec (1489 seconds)

Published: Thu May 19 2022