Mastering Network Services in Hybrid and Multi-Cloud with Infoblox Universal DDI Management

Hello everyone. Glen 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 SaaS, 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, SSH to touched on some of the multi-cloud issues that our customers see.

Uh, so we're, we're really focused on solving these challenges from a multi-cloud perspective, right? And you might be thinking like, oh, well, I'm not multi-cloud, right? Maybe I'm a hybrid, right?

OnPrem and some cloud, 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 cer, that certainly looks a multi-cloud, 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, uh, 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, and Azure engineers on them.

You might have separate teams that 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 Infoblox to manage DNS, but maybe they're not used to logging in and managing Route 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 OnPrem? What am I doing for DNS inside of a NWS environment? They're almost never the same, and you could make them the same and backhaul 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 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 Porn Network 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 NI os, 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?

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 Akamai, they might be doing it with ra. 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 4, 5, 6, 7 different environments to manage those records. C 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, uh, 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, uh, uh, I, I love this example.

I was on with a customer and, uh, I had an A-W-S-D-N-S engineer on the phone, and I had an Azure, uh, DNS engineer on the phone, like hyper-specific. 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 is like, oh, I know what private resolvers are. That's a Azure speak, right?

The, the language of DNS between AWS and Azure is so different that the two individuals that work at the same company couldn't have a conversation about DNS and Azure versus AWS. And I had to help bridge the gap between them to explain to them, no, no, these features are exactly the same. I have a decoder ring that I, 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 KS 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.

It 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 D-N-S-D-H-P-I-P-M infrastructure across the board, right? DHP 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 ops team, 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 wanna 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 Azure or GCPI now can see those same DNS records, that same IAM that I would've seen in the native portal, uh, in our portal, right? Keeping a nice, uh, view that is specific to what that network, uh, admin cares about seeing. Uh, the other thing you're gonna 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 IPM 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 NI os X physical and virtual servers. Uh, you'll notice the NI OS 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 SSH was talking earlier about, you know, Hey, we 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 NI os, if there's some feature or setting that you wanna set that's kind of a, we call those hidden nerd knobs. Uh, in a, 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 via a nice view of the ui, which adds a, a wrapper to, to entering into that portal. First, I just wanna say thank you for spelling. It's on-premises as the fellow that owns, it's on-premises dot com.

I, I can probably say you nailed that, right? com, which forwards to, its on-premises dot com to remind you. Uh, but what do we do for like L four to L seven application load balancers?

'cause modern apps have different ways in which they allocate DNS. It's not L layer three anymore. So what do you have around mm-hmm.

Dealing with stuff where you get like a cilium on top of Kubernetes where it's very, it could be very dynamic. Yeah. And like, 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 mm-hmm.

Than we used do 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 robin 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 roadmap 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 the second question. Yeah. Specific specifically with stuff like Cilium or Istio.

'cause first of all, if you can find way to successfully running Istio at scale, I wanna meet them and, you know, kiss them on the ear because it's, no one's done it, but cilium where they have all their network policies that are also security policies, right? So it's kind of a, a dual purpose there, but then If they write the record to Route 53, we'll pick it up. Right?

Okay. 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 REF 53 or something else, even if it's a synthetic record, right? If you write it to REF 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 think. So in Kubernetes environments, a lot of customers are using core 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 roadmap. Once we do that, then we would be able to, uh, serve DNS within the Kubernetes cluster using core DNS, but we will manage it, uh, 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, TO meshes 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?

Yeah. And the reality is mostly five minutes is plenty fine, but we we're nerds and we love nanoseconds and microseconds. Mm-hmm.

As they always say, if you're writing JavaScript apps and you're worried about microseconds, stop writing JavaScript apps. Like it's right to play bad. And in, in Kubernetes, uh, there are two types of pods.

These server types pods, they don't go away and they come up, you know, register themselves to, uh, STO or whatever service mesh, and then they're there, they're serving applications. So those are not the ones that go in seconds. It's the jobs, the task types, but nobody needs to connect to them.

They're connecting out to something else. Like they do some calculation, download some data, post some results. So nobody's really connecting inbound to those, so they can go away and, and there's no problem with them.

And of course, you mentioned Cord S specifically, what about console? Uh, if you're gonna pick another one, Hey, to our friend over here, if you want a great course on console go to. Fair enough.

Yeah. Accord accordion s is actually in a part of our threat events product line. So we, we actually use accordion s as the DNS sporting 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 NS, um, doesn't mean we won't look at others, but we have a long history with Cord DS. Um, you'll also notice there's two other things on here I want to touch on before we move on, uh, on-prem, Missy, 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 to date 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 third party cloud DNS is also, uh, in the, in the, in the works right now for CloudFlare Akamai.

Um, but I'm not, you know, pedantic about any particular one. I wanna support any one that our customers are using. So whatever the DNS, uh, you know, external, you know, service of choices 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 pane 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.

And if I may, Okay. Yeah. I'm glad you asked that.

'cause it's actually a, 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 as Azure GCP, and then that's a single unified API for you to learn. Yes.

Yeah. Interesting. So is there like a, I don't want to go too far, but is there like a, uh, like a flag or a, or a parameter that you pass that says, create this there?

Like, for example, in Azure? Or do I not care? I'm curious then.

Yeah, so we have a concept, uh, it's borrowed from buying called views. And these zones live in a view, and that view is dictated by provider. That's right.

I'm looking at how to do, uh, what we call view list zones, 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 Okay. Where the zone lives.

So the APIs, API key would be per view mm-hmm. That I'm going. Okay.

Yeah, that makes sense. Yep. So 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 URI.

Okay. Okay. So it's part of the payload that you're Seeing because, okay, gotcha.

One of the values we are providing to customers is they don't have to maintain four different API keys and API credentials. Uh, yeah. They can just maintain one, uh, with Infoblox and one API one API credentials, one key, one terra, one provider, and we translate everything, you know, behind the scenes for them.

Yeah, That's, that's, that makes a lot of sense. That, 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 SaaS 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 CrowdStrike, uh, outages with having, you know, all of their DNS and DHP running onto domain controllers, right? So, and you'd say, well, they're a large SaaS, 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 DHCP off of that and, uh, have us run that on prem for them. Uh, but be SaaS manage and SaaS control, because clearly they're a SaaS provider.

They speak SaaS, therefore they didn't want to just run another appliance that needed to be logged in individually. Another one is a healthcare 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 phone home for weeks. They can still serve DNS and T. 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 IPM 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, 'cause we're authoritative for IPM.

So they're feeding, you know, metadata that says, you know, I need a slash 24 in A-W-S-U-S 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 'em that next available subnet, and they use Terraform as a way of interfacing with the VPC create in AWS and 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 in 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 multi-master and then when they reconnect, they reconcile?

Or do you only go to readonly mode? Like It's only read only mode? 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 is, 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 'cause people don't want to change everything. 'cause that would be kind of a reconciliation nightmare.

But most people say, Hey, I've got this 2030 C names that need to get updated in a DR situation. So that's what we're looking to Provide. Yeah, that's the primary case I used to have was like, literally you would take one active directory domain controller and we'd slice it off for an active disaster recovery exercise.

We treat it now with the master, but then when we're done, we shoot it in the temple and then we Bring, yeah, that's, that's the use cases that we're the MO we're building around the most. Mm-hmm. 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 cloud ops 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 NI os point of view with the number of customers we have that are doing D-N-S-D-H-B 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 we're 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 IPM issues that, um, the, some of the, some of the folks on the network teams solved years ago, right? The more cloud ops teams I talked to, they're, 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 is it each place does, has their own sort of tweak on how they have their Yeah, so we do find that some 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.

'cause 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. I wanna, uh, Jason, a Manager with our technical marketing team. Uh, so I'm gonna show you a couple quick demos right now on Universal DDI.

So we'll start, um, Glen was talking about the, the DNS management piece. And so that's what I wanna start with is kind of that most basic Yeah. Can I pause?

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. It's, that is Okay. Alright, good.

So, um, so I'm here on our, uh, our, our DNS zones page. Uh, like Glen 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 wanna serve them for clients or, or endpoints, et cetera. 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 gonna see, I have, I have the same, the same zones.

com zone, back in the Infoblox portal. Um, we could see that we're also syncing all of the records in as well, right? Uh, but we're not just syncing it.

It's not just that one way we're, we're offering that ability to manage it out of, uh, our Infoblox portal and UDDI. Uh, There we go. I'm just gonna 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 site over there.

Let's just get to route 53 real quick. Take a look at our, our zones in AWS And again, here's the, here's the zone we're gonna look at. Um, we can see records on the AWS side, uh, as well as on the info block side.

And, and we're not just limited to, um, to, to working with those existing records, right? I can create, I can 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 gonna set a PTL and we'll save and close and push this new record to AWS Alright, so jumping over to the AWS portal, uh, real Quick, is it doing a validation for 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 gonna be kind of our, our next topic after this, uh, I am gonna 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, but then there is validate. Sure, yes, yes. But, but I'm gonna help, I'm gonna 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 that 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, uh, 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 we're, right now we're just working with, um, the basic record types, you know, so, so a records 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, uh, AWS routing records and all the different types of stuff you can do there.

So definitely, you know, looking to, to integrate that more in the future. Mm-hmm. Uh, for now, you can kind of see it's, it's mostly ba pretty basic record types.

Yeah. But if I Create it On the AWS side, will I be able to see it? Um, you're gonna, you're gonna see it, but you're not gonna 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. Mm-hmm. And how do you work with like the alias c names inside AWS where they're presenting their dynamic backend ab 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 TXC 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 manage, is that one of the records that you do manage or For, for text records?

Yeah, yeah, yeah. 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.

Oh boy. Different. Um, 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 in the system smart enough to know I'm pushing this record to Azure.

I need to quote it this way. I'm pushing to a WSI quote it this way, Uh, audit trail nut, not cloud trail, but like, do you, what do you do for auditing actions and Sure. Absolutely.

Yeah. We, um, and I won't, I won't go down there now 'cause, 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 push and I could see them attributed to my username, uh, that I pushed these records to A WSI pushed 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 and AWS and info? So if you're making that change in AWS, we're not at this point in ingesting, uh, those, those like cloud trail logs. Mm-hmm.

Um, so you would have to, you would have to track that, that audit, you know, change in AWS itself. Would you have an audit record showing that it had been updated at least, um, updated in AWS and you sync in that change? Is your audit log gonna say this record's been updated?

You it's gonna 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 At That Point.

But it is gonna be in there and Did if they're pulling in that change. Yeah. What do you us, do you have like granular RAC that goes above and beyond what we have and so you could give somebody, hey, you can access this zone and you can access these records in that zone.

Yes. 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, or a user and I assign 'em 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.

com zone, which is a part of that access view one. 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 can do that across, uh, not just the DNS, but the IPAM side as well. And a random, uh, thing that just, let's just say hi, 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. W do you have things like to watch for, like lifecycle of DNS records and when renewals are coming and stuff like that?

Not, I, we we're not doing anything right now, now at registrar level Only down at the ag. Okay. Yeah.

So we're, you know, we're gonna see the host, like say you're registered through AWS and you've got your hosted zone there in AWS, we're gonna 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 oddity in that your re when you register an AWS, it picks the five NS servers that it attaches to the record at that time. But they can change and Route 53 does not change. Mm-hmm.

Do you, can you do things like spot the mismatch where the SOAs don't match what's in the active managed 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 gonna 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. Yep. Alright.

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. Now, I'm, I'm skipping the DHCP 'cause it, it's kind of boring for a demo.

Um, but we'll go, we'll go right into ipam and I'm gonna use kind of a use case that Glen 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, or, you know, for dev for, for, uh, all our staging on other things like that.

Um, and then we could have box set out, you know, tags for the different clouds and whatnot. So I'm doing a, a very simple, simple, like, 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's doing, um, I'm going to, I'm gonna, 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 Azure 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 vnet, I need some subnets to it. I probably need a lot of other stuff to it, but I'm just gonna 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 gonna, we're gonna look for that tag of cloud, and if it says AWS, we're gonna look at the AWS block, Azure, we're gonna look at the Azure block, et cetera.

And then what we're gonna 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 gonna tell it the size of, uh, space to create.

And then I'm gonna 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 gonna do the same thing with creating some subnets underneath it. I'm gonna 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 IT 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, I'm gonna go ahead and run first, uh, my Azure one.

So in my, my Azure example here, I'm calling my, um, my module. I'm telling it 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 backend.

So a size large is gonna gimme, uh, like a slash 24 V vp, uh, vnet. Um, and then I'm gonna create some subnets on it. So then, then what I'm gonna do is pass basically the information return to that, right?

Like the CERs for my vnet, the CERs for my subnets, uh, and I'm gonna feed 'em directly into Azure's, uh, vnet module, right? Which is just available in 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 lemme 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 gonna do the same thing in AWS 'cause 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 gonna point it and use that A-W-S-V-P-C module again, right there out in the Terraform Registry. No code. I had to write myself for that.

So I'm gonna kick off that one as well. And let's go back and take a look where we Have like a Terraform runner that you are 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 ci cd 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 vnet chosen.

It's given an IP space, and then it's selected basically four subnets underneath it, right? Um, so really quick, I'm gonna go over here to, uh, Azure. Uh, this is my new resource group I've created inside of that, I've created that, that Vnet, uh, 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 Infoblox. And let's zoom back out and take a quick look at our four subnets, again, using those cider blocks that we assigned by Infoblox. So there's kind of just a, a simple demonstration of that, you know, that use case that, uh, Glen was talking about.