hello everyone Glenn Sullivan senior director of products here at infobox I manage the strategy and roadmap for Universal DDI asset insights and our as a service offering so basically if it's SAS and it's DDI it's on my uh product management team I'm here today to talk to you about Universal DDI which is smack dab in the middle of this uh product Suite here you can see they're highlighting Universal DNS management Universal dhb management and Universal IP address management or otherwise Universal ipam uh as we like to shorten it because everything we do is an acronym inside of an acronym right so we're solving customer challenges right and and if you were attending the earlier session or if you were watching the the previous stream here uh mesh T touched on some of the multicloud issues that our customers see uh so we're we're really focused on solving these challenges from a multicloud perspective right and you might be thinking like oh well I'm not multicloud right maybe I'm a hybrid right on Prem and some or maybe I have a lot of accounts in any one Cloud right we look at it all as a similar set of challenges right if I have you know deployments in AWS and I've got deployments in Azure and I've got deployments in gcp or maybe I've got 300 accounts in AWS that Ser that certainly looks a multicloud even if it's only technically in one Cloud um the things that we see from a customer challenge perspective is we see that workflows uh don't apply across the board right on-prem workflows don't apply to cloud cloud workflows between the clouds don't apply as well um we also see that there's different tools and vendors uh that are used in each one there's a different API to to maintain right uh one of the things that we like to touch on is human error causing you know causing trouble right human error is the number one cause of outages right when I'm trying to keep things consistent so of course you move to Automation and automation means that you get rid of all human error except when we talk to our customers we find out there's usually only you know one or two people maybe three if you're super lucky that understand the 50 60 lines of python that really do pull uh you know the next available IPS out of you know the different environments or set up the DNS records in uh Google Cloud DNS right there's really uh a lot of complexity hidden under the covers in any of these API implementations also there's just a lot of complexity to managing different environments right it's different teams uh you may have a cloud team that has AWS engineers and an assurance Engineers on them you might have separate teams they might be completely siloed either on purpose or organically right uh you may have different tools that you're using right the network team is very used to logging into infol blocks to manage DNS but maybe they're not used to logging in and managing rout 53 uh so there's different different tools that they have to manage as well also every single different environment usually has a different service deployment model right uh what am I you know what am I doing for for DNS inside of a you know a gcp environment what am I doing for DNS on Prem what am I doing for DNS inside of a native environment they're almost never the same and you could make them the same and back haul everything but then of course you've got you know latency introduced and other other problems that are caused by that as well right so deployments are varying across the board so what happens right with these issues right uh errors happen from manual configurations Services outages and delays right we've see this all the time right we we hear it every time we talk to a customer they're like oh yes there was a conflicting IP that was given out and it took out a major part of my environment or uh there was delay in deployment because there was a lot of back and forth about who owns a particular you know part of the DNS solution right um also in decommissioning we see a lot of issues too right like uh someone will do a deployment and they'll say oh we need to decommission that part of it and they'll say okay well who created that record and there's no record of who created the record so then everyone's afraid to delete it so there's a lot of you know uh complexity that gets introduced in the system as things go on and on um and of course this introduces operational cost right it slows down your deployment the more people that you need to manage your environments uh the the longer it takes for you to do anything the more operational cost you have so Universal DDI is the answer to these right so this is a this is a before and after kind of slide right this is a current and and you know after and then you see like uh in the current I've got two silos there right I've got the network team on the left and the cloud team on the right and that red arrow between them is represents kind of manual Communications right emails phone calls teams slack uh whatever your your your poison is for transferring knowledge between you know individuals who are trying to do an operational task that's what is represented with that red arrow right and uh if you see the pornet admin on the left here you know they have to manage you know our portal which you know isn't hard to manage but it's a tool they have to to manage also if they're using our on-prem Tool uh nios right our our our appliance-based deployments they have to log in and manage that maybe they're managing our Microsoft uh environment from that as well right so they're managing a Microsoft environment proxying it through nios so that that's another environment that they have to manage maybe they have direct access to those Microsoft servers maybe they're going through a server team to manage those and then if they're doing external DNS right for they're authoritative and other words they're hosting their you know whatever whatever.com uh externally they're probably doing that through some combination of external Services right they might be doing it with cloudflare they might be doing it with aami they might be doing it with varara there's so many right that they could be using right uh so this is another place whenever they need to make a change so let's just think on DNS right we won't even make this complicated and talk about dhb and ipam if I have to synchronize a Zone a DNS zone between all of these environments I need to log in to four five six seven different environments to manage those records cre creates a lot of you know places where Eric can happen the other thing uh is then we have the cloud team on the right and we have this represented as a single Circle right with a per with a with a picture inside of it as a single individual but this could be anything this could be a cloud Center of Excellence this could be a team with AWS and Azure Engineers on it this could be individual teams that don't even talk to each other and they all have different languages right so I I love this example I was on with a customer and uh I had an AWS DNS engineer on the phone and I had an Azure uh DNS engineer on the phone like hyp specific their job was DNS in Azure and DNS in in AWS and I said hey you know we can manage the cloud forwarders you know we can do conditional forwarding you know star whatever.com we can say forward that to this resolver you know kind of a a nerdy DNS thing and the Azure person said oh well you're talking about inbound and outbound endpoints so I don't have that in Azure so I guess you can't help me and I had I had to say hey time out it's okay we handle private resolvers and he's like oh I know what private resolvers are that's Azure speak right right the the language of DNS between AWS and Azure is so different that the two individuals that worked at the same company couldn't have a conversation about DNS in Azure versus AWS and I had to help bridge the gap between them to explain to them no no no these features are exactly the same I have a decoda ring that that I have hung up in my uh Cube area excuse me that tells me what each of these different clouds offer from each of their individuals and we all know this right this isn't a DNS thing it's a k s and EK like every single cloud service has their different names for everything so on the right is uh a different view of the world where our portal is the center uh the universal portal here uh where you log in and it doesn't matter if you're a network engineer or a cloud Ops engineer doesn't matter if you're managing you know one cloud or multiples multiple accounts multiple entra ID tenants right uh in Azure you log into our portal and you can see the DNS dhtp IPM infrastructure across the board right dhtp more of an on-prem thing right than a cloud thing um but you will see that infrastructure across the board and it's really important you can see we made it very very small and hard to see but it's very very dotted line there it's a gray dotted line around the cloud op Steam and it points an arrow to the public Cloud the important part is that swim Lane of the cloud team managing using the native tools doesn't go away right so if I want if I'm a azure engineer and I'm very used to the way that Azure manages DNS and I want to log in and manage DNS that way that that swim Lane is not removed that still exists if I uh want to you know log in as a network engineer into our portal as opposed to logging into AWS asure gcp I now can see those same DNS records that same ipem that I would have seen in the native portal uh in our portal right keeping a nice uh view that is specific to what that Network admin cares about seeing uh the other thing you're going to notice is that green line between our portal and the clouds that is cloud to Cloud apis there are other uh implementations out there that have you know gone down the path of managing DNS or managing ipam in you know some of the some of the major clouds but usually they revolve needing some kind of server deployment deploy an appliance uh deploy something in the environment interface with that and then synchronize the data back to our portal uh We've eliminated all Need for deploying a server uh we do Cloud to Cloud apis for pulling all the information both two-way sync between our portal and the three major clouds uh the other thing you'll notice is on the is on the bottom left there is our nios X physical and virtual servers uh you'll notice the nios servers the nios uh grid is now controllable from our portal this was a door that was closed you know previously a few years ago uh when mesh was talking earlier about you know hey we're having two interfaces we've eliminated that for 80 plus percent of use cases and in and we actually have a way of going into the into the exact UI of noos if there's some feature or setting that you want to set that's kind of a we call those hidden nerd knobs uh in in a product that's been around a long time we've added a lot of nerd knobs over the years those are all accessible by a nice view of the UI which adds a a wrapper to to entering into that portal first just want to say thank you for spelling it's on premises as the fellow that owns it's on premises. I can proudly say you nailed that right I even own it's on premise. which forwards to it's on premises. to remind you uh but what do we do for like L4 to L7 application load balancers because modern apps have different ways in which they allocate DNS it's not L layer 3 anymore so what do you have around dealing with stuff where you get like ayum on top of kubernetes where it's very could be very Dynamic and what are the polling rates at which you you know push and pull to keep that stuff up to date where we have you know apps that can come up and go away a lot faster than they used to In traditional DNS great question so we have a thing called DNS traffic control DTC it is our Global server load balancing it's based on DNS so we have that for both nios on Prem or you know appliance-based and we also have it for nios X what it basically is is it's is it you know sets up DNS records with health checks and rules and you know Round Rob and other other kind of load balancing type methods to say oh for this particular record hit this server in these conditions essentially um it it is something that is offered now uh we are looking at how do we handle the more complex routing Solutions so I have some road map on that from like Route 53 so if you look at the three clouds Azure and gcp have reasonably okay routing you know from a DNS perspective AWS has a lot of routing from a DNS perspective so that's what I'm my my gold standard is integrate with that and that's something that we're doing quarter over quarter we're adding more different routing policies that we support um you asked a question you asked a second question yeah specifically stuff like celum or ISO because first of all if you can find anybody that's successfully running is at scale I want to meet them and you know kiss them on the ear because no one's done it but silm where they have all their Network policies that are also security policies right so it's kind of a a dual Pur there but then if they write the record to Ral 53 we'll pick it up right um there are some scenarios we found where things are like uh AWS has a has some of their own features that manipulate DNS without necessarily interfacing with Route 53 so what we do as a vendor who cares a lot about DNS is we urge those who are doing what I'll call fancy things with DNS to write them as a standard to one of the platforms uh whether it's R 53 or something else even if it's a synthetic record right if you write it to rout 53 we can ingest it and we can we can interface with it oh the other question you asked was about pulling intervals um we have a default of five minutes um but you can still do Zone transfer for anything that supports Zone transfer and that's obviously instantaneous because it's the DNS you know core protocol thing uh unfortunately a lot of the cloud vendors don't support Zone transfer but that's what we're for so so when people get into a situation where they're like um I want to do a Zone transfer between these two these two you know vendors that can't do it that's when we come in because we speak Zone transfer and we speak API we do that translation between the two I wanted to add thing so in kubernetes environment a lot of customers using 4 DNS yes as the DNS which provides fast DNS uh and they're asking us if we could manage core DNS from our Universal DNS so that is something that is on the road map once we do that then we would be able to uh serve TNS Within the kubernetes cluster using Cod DNS but we'll manage it just like we'll manage Microsoft uh the other thing you brought up um I've talked to customers that uh have used the apis so as these you know steo mashes come up uh they would call our apis and register the DNS records uh and yes they can happen you know uh fast but you know they're bombarding our apis and saying it's not scaling and we need to make it faster so that's that's what they're doing right now yeah the reality is most mostly 5 minutes is plenty fine but we we're nerds and we love nanc microsc as they always say if you're writing JavaScript apps and you're worried about micros seconds stop writing JavaScript apps like it's too bloody bad and in in kubernetes uh there are two types of SPS the server type spots they don't go away and they come up you register themselves to uh stto or whatever service smashh and then they're there they're serving applications so those are not the ones that go in seconds it's the jobs the tasks types but nobody needs to connect to them they're connecting out to something else like do some calculation download some data post some results so nobody is really connecting inbound to those so they can go away and and there's no problem with them and of course you mentioned CS specifically what about console like if you're GNA pick another one hey friend over here if you want a great course on Console go yeah cordus is actually in a part of our threat defense product line so we we actually use cor DNS as the DNS boarding proxy uh for proxying DNS traffic on Prem and sending it to our Cloud for cloud resolution so we've got a long history with cord DNS um doesn't mean we won't look at others but we have a long history with C DNS um you'll also notice there's two other things on here I want to touch on before we move on uh on premesis as uh you know we said earlier uh for Microsoft is something that is uh in development now we're actually going the agent approach um the agent would run on a uh Windows device that's not necessarily the domain controller um because it's the fastest way to get the the data that we want to be up toate and current with the DNS changes and and everything that's in there um the other thing that we're we've learned is that you know Microsoft admins are very used to working with agents they're not so used to working with an appliance that sits somewhere in their Network and does a bunch of you know API calls into into their active directory domain so that's something that we're uh actively working on and then thirdparty Cloud DNS is also uh in the in the in the works right now for cloud FL aami um but I'm not you know pedantic about any particular one I want to support any one that our customers are using so whatever the DNS uh you know external you know service of choic is that's what we're aiming to to support because we recognize that obviously with Cloud scale applications um you know these these you know these companies have made a lot of uh investment into having external DNS that's available as as a CDN level so you know they're the the goal is to support whatever they're uh whatever they're doing as opposed to saying oh the external DNS query has to come through us that's not that's not in the spirit of universal DNS I've got a quick question sure um what I'm seeing here is like that traditional single paint of glass like management plane for like you're describing all the API calls going to all these different systems is it safe to assume that your inbound API for the portal abstracts that layer of complexity as well yes if I okay yeah I'm glad you asked that because it's actually a major point of um of pride is because we recognize that there's a lot of um there's a lot of you know differences between the apis that are you know for even creating a single record between the three clouds right so we abstract that away and say okay create it the Zone that's managed by us that's synchronized with aws's you're and gcp and then that's a single ified API for you to learn yes interesting so is there like a I don't want to go too far but is there like a like a flag or or a parameter that you passed that says create this there like for example Azure or do I not care yeah so we have a concept it's borrowed from bind called views and these zones live in a view and that view is dictated by provider um I am looking at how to do uh what we call viewless Zone uh that would synchronize with multiple zones simultaneously uh it's something that's uh that's in the works but right now you know where you're writing it to because the view dictates where the where the Zone lives so the API is API key would be perview that I'm going okay makes sense yep now the the API key to the portal is the same and the calls you'll be making to the portal would be the same it's just a field that says this Zone goes into this view it's a URI yeah it's part of the U okay okay so it's part of the payload that because okay got one of the values we are providing to customers is they don't have to maintain four different API keys and API credentials uh they can just maintain one uh with INF four blocks and one API one API credentials one key one terraform provider and we translate everything you know behind the scenes for them yeah that's that's that makes a lot of sense which is why I'm asking that question like I see the complexity removed in one area but potentially complexity added somewhere else and it sounds like you've solved that but we'll see correct okay just wanted to touch on a couple of use cases before we hand it over to Jason to run the demo to show you guys how all this works um I wanted to talk about a couple of uh use cases that are specific that we've seen uh our early customers use and through our Early Access program one is a large SAS provider uh Global everybody would know the name if I said it but I can't say it um they had uh some impacts from crowd strike uh outages with having you know all of their DNS and dhtp running on domain controllers right so and you'd say Well they're a large SAS they shouldn't you know they shouldn't be doing that well everybody has very large networks and those large networks are segmented and they're all different run by different teams right the cloud the the cloud uh application team doesn't necessarily manage the corporate Network that you know users log into when they walk into a building right so uh they were moving off of Microsoft and they recognized that they needed to get uh DNS and DHC off of that and uh have us run that on Prem for them uh but be SAS managed and SAS controlled because clearly there a SAS provider they speak SAS therefore they didn't want to just run another appliance that needed to be logged in individually another one is a Health Care System where local survivability was key uh local survivability is a is the concept of obviously being able to serve DNS and dhb protocol whether or not I can get to the internet whether or not I can phone home whether or not I can phone home to my uh data centers so everything that we do from a from an nios X point of view is for local survivability so that you know it gets its configuration it gets its updates from the cloud but any kind of interruption it keeps serving DNS and dhp protocol right and this health system had a tornado that took out a hospital they had no Wan they had no you know internet for you know weeks on end so those are the use cases that we designed for we have cruise ships that literally go out to sea they can't Throne home for weeks they can still serve DNS andt uh the last one I I just want to touch on is a uh e-commerce uh luxury e-commerce brand um that uses us for ipam for public Cloud right so they've got a lot of AWS implementation um they're pulling you know new allocations constantly for vpcs that they're standing up and tearing down they're using terraform as a way of getting the data out of out of our system for because we're authoritative for ipam so they're feeding you know metadata that says you know I need a sl24 in aw us us East one in the PCI you know environment that matches you know staging or Dev or whatever they give us those parameters they say they ask for the next available subnet we give them that next available subnet they use terraform as a way of interfacing with the VPC create in AWS in the way to write to us authoritatively um do they have to do that no there are other ways they can do that but they've standardized on terraform so any kind of automation that someone's bringing to the table we're looking to integrate with as opposed to dictating that we have to be the automation platform when you do something for the local survivability does it become like a independent multimaster and then when they reconnect they reconcile or do you only go to readon mode like it's only readon mode it it it and uh yeah it's meant for being kind of a satellite until it's reconnected so there's no reconciliation that needs to happen because there's no config changes that are made is there any opportunity to actually still inject new records in an off like in an there there is a request to do that and we are working out the right way to do that my my point of view on it is there would be certain record types that would be synthetic that would be injected during a Dr situation so we're looking at how to do that right now but that's because people don't want to change everything because that would be kind of a Reconciliation nightmare but most people say hey I've got this 2030 cames that need to get updated in a Dr situation so that's what we're looking to provide yeah that's the primary I used to have was like literally you would take one actor directory domain controller and we'd slice it off for an active Disaster Recovery exercise we treat it now as the master but then when we're done we shoot it in the temple and then we never bring that's that's the use cases that we're the mo we're building around the most so as product management how much of your time is spent so because obviously internal structures are different for each Place uh the way they they have Cloud teams they have devops teams they have CIS admins so how much are you spending your time on tailoring it to each one of these and then having to navigate within it to sell to these people um and to what extent if you do do you change the product so I don't know if you know for example for these use cases how each one their it groups are uh set up does that make sense so I spend a lot of my time talking to both network operations teams and cloudops teams and the best calls I have is when they're on the same call but sometimes that that doesn't happen um we do tailor features just for cloud Ops um the the nice thing about coming from the noos point of view with the number of customers we have that are doing DNS dhb and ipam uh primarily on Prem is we have that user base nailed we know everything about all of their problems because we've been building products for them for years the cloud Ops teams were coming at more from a hey what are the interactions you're having from the netops teams what challenges are you trying to solve when you get an allocation from them how do you use it you know giving the network team the visibility and how those allocations are used these are the types of conversations that we have with Cloud Ops teams um and they have a whole host of ipim issues that um the some of the some of the folks on the network team solved years ago the more Cloud Ops teams I talk to there they're solving these problems with spreadsheets um which is exactly the same problem that network teams had 15 years ago 20 years ago you know doing IAM uh on Prem so would you find that pretty consistently you have Cloud Ops net Ops you don't have um integrated product teams or each Place does has their own sort of tweak on how they their yeah so we do find that some C customers have like a center of excellence but it's it's definitely not as common as having a separate team the one place where things get interesting is DNS because if there's one place where the network team manages something that's in the cloud for the cloud Ops teams and the cloud Ops teams really aren't you know keyed in on how on how it's working under the covers it's DNS that's the number one place where I see a network team having like a cloud person who knows how to speak cloud and knows how to speak Network and that's for managing DNS in the public Cloud thanks okay hi everyone I'm Jason R manager with our technical marketing team uh so I'm going to show you a couple quick demos right now on universal DDI so we'll start um Glenn was talking about the the DNS management piece and so that's what I want to start with is kind of that most basic yeah can you zoom that in just a little bit um some of us have old eyes thank you for saying that and saving me this question I'll follow my sword that is great okay all right good so um so I'm here on our our our DNS zones page uh like Glenn said we work with this concept of DNS views right out of bind where we can uh separate different providers or we could you know separate DNS zones based on where we want to serve them for clients or or endpoints Etc um but what I've done is I've connected up our public clouds with uh with uddi in my system um so for example I've connected it into Google Cloud right um and we can see here I've synced all these zones across from Google Cloud if I if I go over to my uh Google Cloud console here I'm going to see I have I have the same the same zones um and I can dig into any of these zones and look like for example here's my uh my records in this uh gcp Dommy corp.com Zone back in the infol blocks portal um we can see that we're also syncing all of the records in as well right uh but we're not just thinking it it's not just that one way we're we're offering that ability to manage it out of uh our infol blocks portal and uddi uh there we go I'm just going to make a a quick change to that DNS record updating our uh IP address uh if I go back over to to the Google Cloud we'll see almost almost instantaneously right we've pushed that change now being able to do that for one Cloud right it's okay but it but it's but it's a fairly simple thing the value is in bringing all of those different systems under that same management uh so for example I want to do the same thing in AWS um I can go to my my AWS view here and once this loads uh we'll get all my zones from AWS on the uh the console s over there let's just get to Route 53 real quick go look at our our zones in AWS and again here's the here's the Zone we're going to look at um we can see records on the AWS side uh as well as on the infolock side and and we're not just limited to um to to working with those existing records right I can create I could create a say a new a record here uh and push it out to this um to this zone so we'll just give it a simple uh IP and whatnot here I'm going to set a ETL and we'll save and close and push this new record to AWS right so jumping over to the AWS portal real quick is it doing a validation before like you can actually submit it so it's is it looking at that you have an existing IP address or anything right there or you just blindly being uh so so I I have the freedom to to shoot myself in the foot basically right I can enter in any IP address I want there however when we get into the um the asset Insight side which is going to be kind of our our next topic after this I am going to show you how our system will recognize when maybe I have some records with invalid addresses and things like that and we are doing some detection around that you're introducing you can introduce human error right now at this point then there is validation sure yes but but I'm going to help I'm going to help us catch it right with with another part of of that same system um but but it's not always an error right there there may be cases where using outside address that's not in my system yet I I do need it maybe I'm creating a a record that's pointing to a you know something in a partner's organization or something like that or something that's outside of my basic control so there are use cases where I want that freedom to enter in any and every address that I might need to be able to use for DNS you're creating an a record here um what other record types are supported from Portal is does it have full support for all the different weird AWS things no so so right now we're just working with um the basic record types you know so so a record C names MX all all your basic record record types and then as Glenn said um we are looking at you know expanding that integration to say some of the the funky AWS routing records and all the different type of stuff you can do there so definitely you know looking to to integrate that more in the future uh for now you can kind of see it's it's mostly B pretty basic record types yeah but if I create it on the AWS side will I be able to see it um you're G to you're going to see it but you're not going to see see it in the same form right so for example if I create um some routing records on the AWS side I might see multiple a records on my side here since we're not we're not fully working with those routed records yet and how do you work with like the Alias C names inside AWS where they're presenting their Dynamic back in absolutely and that's and that's a great thing to be able to do yeah where you're using say the Alias records and it's pointing directly to a service so because we know that IP or whatnot could be dynamic we can sync that and work with that just fine and for txe records just because when you get singles they don't have quotes when you get multiples you have to make sure that you're not trouncing the previous record which I do all the time how do you man is that one of the records that you do manage or for for text records yeah yeah yes so we so we are able to do those um and I know it's it's actually a little like if you look at the apis for the different clouds like how they manage with the quotes is slightly different so so we do have we we do have that built in and you're you're able to you know create create text records just just by simply going in and entering it here and the system smart enough to know I'm pushing this record to Azure I need to quote it this way I'm pushing to AWS I quote it this way uh audit Trail not not cloud trail but like do what do you do for auditing actions and absolutely yeah we um and I won't I won't go down there now because um but we do have like um a full full audit logs and you know system logs in the system so I could go in there um look at audit logs and I could see those changes that I just pushed and I could see them attributed to my user us name uh that I push these records to AWS I push these records to gcp and I did it at at this time on both sides of it though when you're in AWS what if I make a change in AWS are you seeing the logs of the DNS entries in AWS and info so if you're making that change in AWS we're not at this point ingesting uh those those like cloud trail logs um so you would have to you would have to track that that audit you know change in AWS itself but would you have an audit record showing that it had been updated at least um updated an ads and you sync in that change is your audit log going to say this record has been updated yeah it's going to be in a log I'm I apologize I think I think it's actually in the um in in the um like the system log and not the audit log because it's a part of a discovery process versus a human interaction that point if they're pulling in that change yeah what do you do you have like granular rback that goes above and beyond what we have in so you could give somebody hey you can access this Zone and you can access these records in that zone yep absolutely so we have this we have this concept of access views right so I can um I can take an an administrator or or user and I assign them to an access View and then I assign that access view to various objects right like I could assign it to uh this DNS view or I could assign it to just the DNS Zone um and then within and then using a policy I could attach different administrators to that access view and say okay um you know this group of users are DNS administrators for Access view one uh meaning that they can only see and interact with say this awsmm corp.com Zone which is a part of that access view1 and they're only allowed to do certain things to DNS right I could actually limit them down to that so you have very very granular levels of control and we could do that across not just the DNS but the ipam site as well and a random uh thing that just let's just say hypothetically I ran into this the other day where say you forget that your one year from your last time you re-registered the domain and say you forgot to Auto renew would do you have things like to watch for like life cycle of DNS records and when renewals are coming stuff like that not I we we're not doing anything right now only down at the Y so we're you know we're going to see the host like say you're registered through AWS and you've got your hosted Zone there in AB we're going to see The Zone um but the Zone doesn't necessarily reflect anything as to when that um when your your uh your actual registration expires right and so we're not we're not interacting with that piece of AWS yet and there's one AWS audity in that you're when you register in AWS it picks the five NS servers that it attaches to the record of that time but they can change and Route 53 does not change you can you do things like spot the mismatch where the S soas don't match what's in the active manage Zone uh yeah so we so we would see that here and and as changes you know changes like the knowing that these these NS records are Dynamic so we're going to update those as well when we you know when we do those period um periodic syncs right so um while we're able to push directly from here we're still also doing a periodic sync on the back end to rectify okay did did AWS make any changes to something like those NS records that we don't necessarily control nice y all right so the next thing I wanted to uh to show so we talked um DNS management right so the next thing I wanted to look at is the the ipam management side I'm skipping the DHCP because it's kind of boring for a demo um but we'll go we'll go right into ipam and I'm going to use kind of a use case that Glenn talked about right where where we have um a customer and they're managing uh those different Cloud environments and they're doing so using like tag data right so we could have for for example that um those those tags on environments for prod um for you know for Dev for for all staging and other things like that um and then we could have blocks set out you know tags for the different clouds and whatnot so I'm doing a a very simple simple like uh in implementation of that here I've I've just created these three IP address blocks and I've assigned them to the various clouds right um and as a part of each of these I've just given it one one simple each of them one simple tag with a a tag that says Cloud uh with the value of the cloud that I want it to be used for uh and just like the customer doing um I'm gonna I'm going going to I'm going to actually make that implementation and tie those together using terraform right so we can see right now my uh my Azure space here I don't have anything in um but I've got a new aure account and I need to stand up a uh I need to stand up a a landing space in there right I need a I need a v-net I need some subnets to it I probably need a lot of other stuff to it but I'm just going to do the basic pieces for this demo so what I've done is just built a a simple um a simple terraform module right and all my all my terraform module does here is it looks up that IP address block um by whoops by that tag of uh by that tag of cloud right so we're going to we're going to look for that tag of cloud and if it says AWS we're going to look at the AWS block Azure we're going to look at the Azure block Etc and then what we're going to do is we're going to take that block and we're going to create a basically a new block nested in it that's going to become the the the IP space or the container for our VPC or vnet um so all I'm doing is giving it that overarching block I'm going to tell it the size of uh space to create and then I'm going to let our our API do the rest of the work of figuring out you know what IP addresses to actually use once that's created I'm going to do the same thing with creating some subnets underneath it I'm going to use that let our API do all the work of figuring that out uh so so one of the nice things I like to point out here is that there's not a single IP address in my code right and so I don't have to know any any IP addresses I don't have to mess with any of that to do this I can do this All based on tags and and attributes that are more human usable and make more sense to us right so I'm going to go ahead and run for first U my Azure one so in my my Azure example here I'm calling my um my module I'm telling that the cloud is azure uh I'm telling it that IP space I'm giving it a size which I've just uh translated on the back end so a size large is going to give me like a slasher 24 VP uh vnet um and then I'm going to create some subnets on it so then then what I'm going to do is pass basically the information return to that right like the cers for my v-net the cers for my subnets uh and I'm going to feed them directly into azure's uh v-net module right which is just available on the terraform registry it's out there for any and all of us to use for free I didn't have to write any code for it myself so let me go ahead and uh kick this job off all right I'm just gonna start this Auto approve um at the same time I'll show you I'm going to do the same thing in AWS because like I said what's cool about this is we do it for all clouds we're we're we're kind of agnostic to where we're doing it right so AWS using my same module uh and then I'm going to point it and use that AWS VPC module again right there out in the terraform registry no code I had to write myself for that I'm going to kick off that one as well and let's go back and take a look where have like a terraform Runner that you're running in your environment this is us like either doing a direct terraform or a terraform Cloud pointing at and we and we absolutely could do that I'm just doing it you know simply on uh on on my laptop for for demo purposes but but yeah absolutely you could you could run this out of terraform Cloud you could you could kick off um terraform runs I've seen it done out of say Jenkins or something like that as part of a cicd pipeline right where you have this integrated into that yep so uh let's see looking back at Azure here there we go so we can see we've we've got a um we've got our v-net chosen uh it's given an IP space and then it's selected basically four subnets underneath it right um so really quick I'm going to go over here to uh azure this my new Resource Group I've created inside of that I've created that that v-net I know that's super small there um but we can see our our range is the same one that we've you know that we've assigned from our source of Truth and infol blocks and let's Zoom back out and take a quick look at our four subnets again using those cider blocks that we assigned by info blocks so this kind of just a a simple demonstration of that you know that use case that uh Glenn was talking about