[00:00:00] Speaker A: We should be looking for opportunities to secure infrastructure wherever we have it in an efficient way. All these organizations out there, they already have DNS infrastructure. We're just saying do more with what you already have. Make your DNS infrastructure smarter than it is today. You already use DNS. DNS is already there mediating all of these transactions that occur over your network. You want to get better visibility into what's happening on the network. You want to be able to block some threats that obvious based on the destinations that are going to. We can do that.
[00:00:32] Speaker B: This is KBCAT as a primary target for ransomware campaigns, security and testing and.
[00:00:40] Speaker C: Performance risk and compliance.
[00:00:42] Speaker A: We can actually automate that, take that.
[00:00:43] Speaker C: Data and use it.
Joining me today is Cricket Lou, EVP, as well as chief DNS architect from Infoblox. And today we're discussing domain name system, also known as DNS, and the security concerns associated with the phone book of the Internet. So cricket, thanks for joining and welcome.
[00:01:03] Speaker A: Thank you very much. It's nice to be here.
[00:01:05] Speaker C: So let's start with you. I've read your bio, and one thing that's interesting about your bio was that you've been around since before we called it the Internet. So maybe briefly talk us through before the Internet or your journey. And then how have you seen the worlds of the Internet evolve over the years?
[00:01:25] Speaker A: Yeah, so I think my first experience with what became the Internet was when I was an undergraduate at the University of California at Berkeley. And back then, what I really liked about our connection to what was then the ARPANET was that it meant that email addresses became a lot simpler before that. I don't know if you know anything about the days of UUCP, the Unix to Unix copy protocol, but if you wanted to send somebody email, you kind of had to thread the email hop by hop through all of the servers that you wanted to have transmitted. It was a real.
So we had a connection to the ARPANET that was very exciting for those of us who were studying computer science at Berkeley. And from there I went to HP. I remember the department that I worked for, which was called corporate and network services when I joined, was responsible for what was then called the HP Internet. So obviously there was an Internet at that point. And initially, though, my responsibilities didn't have anything to do with DNS or Internet working. I worked for a little group that did office automation strategy. So we wrote memos that basically said you ought to use Microsoft Word and not me pro or word perfect. Not perhaps the most electrifying job to have. But I was working sort of right across the aisle from people who were working on the HP Internet. And that seemed really exciting, seemed like an engaging sort of, sort of endeavor. And fortunately, I managed to cross the aisle and start working on the HP Internet, which was then the world's largest private TCP IP network. And I got into DNS.
[00:03:04] Speaker C: Wow, that's a cool story. And what was coming up in my mind as you were speaking is because I had an interview earlier today, and you probably remember this quite vividly, around when the Internet sort of started out, if you want to call it that, people being worried about their jobs, what the Internet would do. And I sort of see the same type of fear or worry around AI, generative AI, and the same sort of concerns perhaps are emerging from this. Do you think? Maybe if you take a moment to listen to that question, do you think it's because people don't know what we don't know?
The rules aren't really written yet. When we look back retrospectively, we could probably say, oh, the Internet is a great thing. Obviously there are concerns and issues with it, but the Internet has still generated jobs and it's evolved us as a society. But I'm just sort of seeing the same fear come through, especially in the last twelve months or so since Chat GPT has emerged. So are you sort of seeing that as well, in terms of the correlation?
[00:04:02] Speaker A: Yeah, I don't know if the correlation is exactly the same. In the early days of the Internet, what I remember is thinking, wow, this is a really exciting time. My friends and I can play these network games. We can communicate with each other. It was difficult, I think, at that point, or at least I did not extrapolate from there to the world we have today, where we have tiny mobile devices that have Internet access, that unless we're off backpacking on vacation, we assume that we're going to have some sort of Internet access from our devices. Think with generative AI and similar technologies, I think people have, they can see what the capabilities of the technology are, right. You can ask Chad GPT to write something for you. Write an introductory email that invites people to the following event, blah, blah, blah. And it's very easy, I think, from that to extrapolate how those sort of capabilities could obsolete individuals. Right. If you're the kind of person who works in certain roles, if you work as an inside sales rep, if you work as perhaps a field marketing person, those sorts of things, then some part of your job is doing those sorts of things. On the other hand, those technologies can also make your job a lot easier, right? Because you don't have to sit there and struggle over how am I going to write this invitation? How am I going to do this or that? You can have something like Chat GPT help you with it. But I do feel like in the beginning of the Internet, that was really unknown. We didn't really know what would happen.
[00:05:38] Speaker C: So let's flick over now to your time with Pine DNS, or part of pioneering DNS. So walk us through the journey, because now, and I want to get into, obviously, the security concerns, but I think if you look at the generation coming out now and the new kids on the block, they probably don't even really think about DNS or how it works or anything of that capacity. So I'm really keen to understand.
[00:06:07] Speaker A: Well, I really kind of fell into DNS. I didn't know anything about it. Like I said, was working for the department at HP that was responsible for the HP Internet and as a consequence, responsible for DNS, at least at HP. But it wasn't my job, and I was very lucky. I just kind of fell into it. I was living in San Francisco at the time and commuting down to Palo Alto, which is where HP's corporate offices are, or were, actually, I think they've moved, carpooling with a bunch of friends. And one morning the manager of one of the friends I carpooled with called me. And you know, John's had a family emergency. He's not going to be coming in today, but he was registered for a class. It's too late for us to get our money back, but you can go in his place. And I said, sure, if it means I don't have to come into work today. That sounds great. Turned out the class was in San Francisco. And then kind of as an afterthought, I said, well, what's the class about? And he said, it's about DNS. I said, okay, I don't know anything about that, but it sounds interesting. And I went to this class. It was taught by Paul Malcopatris, who was actually the real father of DNS, the guy who invented the technology and a brilliant teacher, very funny, very easy to understand. And after two days of that, I was hooked. That was what I wanted to do back then, DNS was actually pretty similar to what it is today. It was less dynamic. I mean, one of the things back then was that in order to connect a computer to the Internet, you had to have some sort of static configuration. A computer's address didn't tend to change. And there, of course, weren't nearly the variety of devices connected to the Internet as there are today. So that's been certainly one very big change.
The DNS servers of the day were comparatively a lot less feature rich. They lacked a lot of security that they have today, but they are absolutely recognizable as DNS servers. Anybody who works with DNS today would probably be able to figure out how to configure one of those DNS servers. It's not like a kid today trying to figure out how to use a vcR.
[00:08:07] Speaker C: My gosh, I had to explain to a guy on my team what dial up Internet was. And I'm like, I'm not even that old. Like, I'm in my 30s, but this kid's in his 20s, early twenty s. And I was like, wow, I feel really old now. Again, going back to new kid on the block, that wouldn't even come into the equation.
[00:08:24] Speaker A: Yes, it's funny that we still retain the vestiges of those technologies too. My wife was saying the other day to somebody, forget what it was she was talking about. Maybe they had recommended a tv show to her or something, and she said, oh yeah, I'll have to tape that. And they went, tape?
[00:08:39] Speaker C: I know.
[00:08:40] Speaker A: She's like, yeah, I'm old, I'm old.
[00:08:43] Speaker C: So what made you hooked about DNS? You said that you went for this class and then you're hooked. What about it? Which was so, you know, the technology.
[00:08:51] Speaker A: Just made a whole lot of sense to me. And I think the way that Paul explained it was really clear. It was like, oh, of course you would design it that way. Things like the hierarchical namespace. Oh yeah, of course that makes sense that you would do that if you were going to subsequently do things like allow different organizations to manage different parts of that namespace. A hierarchical namespace makes sense the way the DNS servers communicated with each other, that a stub resolver that might be in some device, like a laptop, would query a recursive DNS server and the recursive DNS server would go out there, query some set of authoritative name servers to find an answer. It all just made sense to me. I think maybe one of the things that was particularly striking about DNS as a technology is that at the time, p had a big network that was based on a networking protocol called X 25. Have you heard of X 25?
[00:09:46] Speaker C: No, I haven't.
[00:09:48] Speaker A: Well, X 25 is an old technology, and it made no sense to me at all. I didn't understand why addresses were as long as they were in x 25, there were just all kinds of weird, arbitrary design decisions, at least to me at the time. They seemed weird and arbitrary. And by comparison, TCP, IP and DNS seemed to make so much sense, like they had been designed by people who had a clearer idea of what they wanted to do and were actually seeking to make things understandable.
[00:10:18] Speaker C: Wow. Yeah. I've never heard of X 25 before, but I think it's interesting to understand the journey around it then as well. So you mentioned before, DNS as it is today is somewhat the same as it was when it started out, if you want to call it that, or inception. What do you think has changed there? Is there anything specific that you'd like to sort of point out from the DNS front? Considering you've been doing this a while and in your role now, you've obviously seen the landscape change.
[00:10:47] Speaker A: Yeah, I mean, certainly one of the things that happened is that networks became much more dynamic. We moved from dial up, which made things somewhat dynamic, to wireless technologies, which we take for granted nowadays, cellular networks carrying data. All of that means that the addresses that people's devices have can change and they can change in many cases pretty rapidly. And DNS had to change in order to accommodate that. So that was one of the first big changes, was that DNS had to be extended in order to accommodate that. And it was extended with things that we call dynamic update and notify and incremental zone transfer. That's not particularly important that anybody remember what those are. But there was engineering work to do in order to make sure that DNS could keep pace at the same time at the very beginning, because DNS was designed for the ARP and it wasn't designed with a whole lot of security features. And so we did spend a lot of time also adding what probably seem in retrospect, like very basic security features to DNS into implementations of DNS servers like Bind IP, address based access control lists for queries and dynamic updates and zone transfers, which these days just seems rudimentary. Back then, hey, we didn't have them.
[00:12:06] Speaker C: So security is obviously an afterthought, as you've sort of just explained in it. And I guess it's changing if you want to look at today's world. Yes, that's changing, but they're starting to do devsecops or SeC DevOps, what do you want to call it, but also security by design, et cetera. So security is being embedded into things. But why do you even think, back then security was an afterthought? Because we can talk about, I mean, this obviously is cybersecurity podcast, so I'm probably not the right person to really give a view on this, because I care about it a lot. But I think that to some degree, nothing much has still changed in the sense that security is still an afterthought to certain amount of people or companies, because they don't really think about it that much. And yes, it's changing, but it's going to take a little bit of time. So I'm curious then to understand, from your perspective, why was it an afterthought back then?
[00:12:53] Speaker A: Yeah, well, I would suggest that in the very beginning of DNS, which was 1983, in fact, we're coming up on the 40th anniversary of DNS, or 40th birthday of DNS next month. It was an afterthought because access to the ARPANET was pretty tightly controlled. Not everybody had it. It was considered kind of a collegial network, if you will. We didn't worry too much about threats across the ARPANET. As the ARPANEt evolved into the Internet, it became clear that there were threats. But maybe we misjudged what those threats were. We focused on kind of bread and butter security mechanisms, like I said, IP address based access control lists. We spent a lot of energy on something called the DNS security extensions, which is used to combat cache poisoning attacks, basically attempts to inject into the caches of DNS servers on the Internet bogus data, data that might direct you to people who think they're going to their bank's website, to an imposter website, where they might enter sensitive information that could be used against them. It's only really been in the last maybe ten or 15 years that we've realized, oh gosh, the way that people are misusing DNS is in a way a lot more prosaic than that. I mean, catch poisoning attack, they're still kind of exotic. They do not happen all the time. They do sometimes happen. But the bad guys, the folks who write malware, for example, they use DNS in all kinds of ways, right? And for example, malware will typically rendezvous with command and control infrastructure out there on the Internet by looking up domain names and DNS. I mean, maybe it will synthesize those domain names using something called a domain generation algorithm, but it's still using DNS to find the IP addresses of command and control infrastructure. If it finds something interesting on a drive file system that it wants to move out to the Internet, it may well use DNS to tunnel that data to communicate that out to the outside world and to the bad guys. Because in the vast majority of cases, on the vast majority of networks, people aren't looking at DNS traffic carefully. And so they can embed that upstream data in DNS queries and no one will be the wiser. So like I said, it's only been in the last, since about 2010 that we realized, oh gosh, it's not just cache poisoning and basic things like that that we need to secure. We need to turn these DNS servers into security tools. We need to make them smarter about the queries that they process and the responses they return.
[00:15:24] Speaker C: So how did your thinking sort of evolve? So you go back to that 2010 example, how do you then transform that into a security mindset? Was there anything specific that stands out for you around? Oh, okay, well, now we need to look at how we're going about this and how this could be a problem down the line from a security point of view. What was the thinking behind that?
[00:15:48] Speaker A: Well, the reason that the 2010 is important is because that's when Paul Vixey and Vernon Shriver came up with a mechanism called response policy zones. RpZs, I guess rpzs down here for short. And response policy zones are just a way of configuring a name, a DNS server, so that it basically can ingest a reputational feed, a feed of domain names and IP addresses that we know are being used maliciously. And then you're telling the DNS server, look, if you get a query from one of these domain names that we know is being used in a phishing campaign or being used to identify command and control infrastructure, don't answer it. Answer it with an error, say that domain name doesn't exist, or hand back the IP address of some portal within the organization and tell people that they tried to go somewhere that they shouldn't have gone.
It seems maybe kind of obvious in retrospect, but it was in those days kind of revolutionary because it meant, oh wow, we can arm our DNS servers with the intelligence to not be complicit in these sorts of activities. And that was a really big deal. Now, adoption of the technology has not been as rapid as I would have liked. I would have hoped that folks would realize that, gosh, this is amazing stuff, right? Every nontrivial transaction that occurs over a TCP IP based network or over the Internet is mediated, is preceded by a DNS query, or maybe more than one. So this is incredibly important technology that can basically address large majority of the threats out there, but we still haven't seen the kind of adoption that I would have hoped for.
[00:17:31] Speaker C: What were you hoping for?
[00:17:32] Speaker A: Well, I would hope that adoption would be nearly universal and that basically every large organization running DNS infrastructure on their networks would have response policy zones or equivalent functionality active on their networks. But I think that the actual number is probably substantially less than 50% and maybe more like ten.
[00:17:54] Speaker C: So I want to go forward a question, and then I'm going to kind of come back to the security concerns. But just hearing you speak now, would you say DNS is pretty fundamental, as you've clearly articulated? Would you also say that it's something that's easily overlooked by security teams, by people? Again, the next generation Gen Z? Don't really think about how DNS works. How the mechanics. Oh, you just type in a URL, maybe the thinking and the mechanics of how it works isn't there. And there's something they always talk about in security is you need to understand how things work to be able to protect it. So I'm curious then to hear your thoughts.
[00:18:31] Speaker A: I think that's it's very true that DNS is not well understood in the security community, not by sort of the average security person. And part of that is that it's considered kind of arcane technology. Right. When DNS sort of arose, it sat in this weird position between networking and system administration, because, of course, if you were going to run a DNS server, you needed to have a Unix system to run it on. And so there weren't a lot of people who had both the networking background and the system administration background to manage DNS. And I don't know, ever since then, it's never sort of lost that reputation as this kind of weird, esoteric technology that nobody really understands. And certainly in the conversations that I have with security personnel at previous organizations, most of them aren't familiar with things like response policy zones. Most of them aren't familiar with the sorts of things that DNS infrastructure can do to help them, how it can help inform them of when they have infections on their networks, or when they have folks inadvertently or deliberately responding to phishing campaigns and trying to go places in the Internet that they shouldn't.
[00:19:46] Speaker C: Do you think as well that, and I can't speak on behalf of everyone, but a lot of security people nowadays are more like application focused rather than your old school networking layer, if you want to call it that.
[00:19:57] Speaker A: Yeah, I think that is true. I think, unfortunately, the old guard of the traditional, sort of white bearded Unix guru who knew the OS and he knew the network, he's kind of gone. Or at least I see fewer and fewer of them.
The security folks that I do see, I mean, they're very bright people and they have to keep pace with a really alarming rate of introduction of threats. But they don't always know a lot about networking technologies.
[00:20:30] Speaker C: Yeah, I've seen that as well. So would you say then, if people, generally speaking, understood more about maybe the networking, and on the networking front, but also how DNS works in terms of the mechanics, do you think we would have a lot less security problems? And I know that's a big question, but again, it's about how do we fill the gap between a standard network engineer to, I don't know, application security engineer, for example.
[00:20:56] Speaker A: Yeah.
I would say unequivocally that if we simply use what we now call sort of protective DNS as an umbrella term to include technologies like response policy zones, if we use those pervasively, yeah, we would find a much higher percentage of threats. We would identify them quicker, we block them quicker.
[00:21:16] Speaker C: So how do you think, from your point of view, with your background, how do you think we can start to close that gap? Because I'll tell you where my thinking is going. So a couple of weeks ago, I was in a meeting doing this company, and they even talking, even at the hardware layer. And I mean, look, this goes into another whole interview on its own, but it's like, let's securely build hardware from the ground up. They showed me the factory, how it all works, how it's built on a blockchain and it's all audited and all of these things that will be deployed for critical infrastructure as well as government and government agencies, for example, because they were sort of just saying even at that layer, which is something that I didn't really think of up until I went and met with these guys that were talking to me about it, saying, well, if there's a problem even at the hardware layer, forget the rest. Don't worry about applications and everything else. So I'm just saying curious, like, how do we start to close that gap? Because I think today, because everything that's happening, people are very, like I said, focus on the application layer, but then also forgetting fundamental stuff like basic networking, but DNS, but hardware, et cetera. And it's something that even rattled me because I never really thought about it up until I had that conversation. I just wasn't at the front of my mind.
[00:22:31] Speaker A: Yeah, that sounds pretty exotic. I mean, I don't worry about threats to the silicon, for example, somebody injecting something into the design for my processor, that's going to get me down the road. Yeah, but one of the things that we should be looking for are we should be looking for opportunities to secure infrastructure wherever we have it, in an efficient way. And that's one of the things that I like about protected DNS, is that all these organizations out there, they already have DNS infrastructure. Right. You have to, in order to have a TCP IP based network. We're just saying, do more with what you already have. Make your DNS infrastructure smarter than it is today. We're not saying, hey, you need to buy some WySi new device, and you need to put one of these on every single one of your subnets, and that'll solve all of your security problems. We're saying you already use DNS. DNS is already there, mediating all of these transactions that occur over your network. You want to get better visibility into what's happening on the network. You want to be able to block some threats that are obvious based on the destinations that are going to. Well, we can do that. And I do also, I want to make sure that I'm clear about this. This is not an info box technology. It's not really an Internet standard. It's something that Paul and Vernon came up with and published, but it's supported by basically every major open source recursive DNS server. Bind. There's a check server called not knot. There's unbound that comes from NLNEt, which is a dutch nonprofit. They all support this. We would love it, of course, if people did this with infoblocks gear. But even if they didn't, the world would be a better place if they use protective DNS.
[00:24:12] Speaker C: So let's maybe switch gears and let's go into the security concerns, because this is a cybersecurity podcast, and again, there are concerns with DNS, like ddos, et cetera. So talk to me more about this.
[00:24:25] Speaker A: Yeah, I mean, we still see lots of threats against DNS servers. DDoS is still a big one. All of the major DDoS mitigation organizations, companies publish like, quarterly reports on what they've observed on their DDoS mitigation services. And I think what I've seen is that typically one out of ten, maybe one out of six, involve DNS in some way. And in a lot of cases, what's happening is that the bad guys are using DNS servers on the Internet as amplifiers and as reflectors in these DDoS attacks. So a well connected DNS server. If you send a relatively small query, you can still get it to send back a large response. And if you spoof the source IP address, which of course is fairly easy because this is UDP traffic, then you can get 40 to one, sometimes even larger amplification factors. Let the DNS servers do your dirty work and ddos your enemies. So that's still a big problem. And of course DNS servers are also the targets of DDoS attacks. They are essential infrastructure if you're going to have a presence on the Internet, if you're going to receive email, if you're going to have web servers or other Internet applications available out there, you also have to have DNS servers and they're an obvious target for the bad guys. If the bad guys manage to successfully DDos your Internet facing authoritative DNS servers, you're effectively knocked off the Internet. So we're still working on that too. We have lots of mechanisms for dealing with some of those issues. It's still an ongoing problem.
[00:25:59] Speaker C: What are some of the mechanisms that you're working on at the moment?
[00:26:01] Speaker A: Well, one of the mechanisms, and I'm not responsible for this one, this one was actually developed again by Paul and some other people, is called response rate limiting. And response rate limiting effectively makes it more difficult for someone to use a DNS server as an amplifier and as a reflector. It says, look, I'm only going to accept so many of the same query from the same, say 24 network for I-P-V four. I think it's 56 or 64 for I-P-V six. And after that I'm going to limit the rate at which I respond to that query from that network. So that's a good thing. I mean, if we saw that more widely deployed, it would certainly make it more difficult for the bad guys to use DNS servers as amplifiers and as reflectors.
[00:26:46] Speaker C: So would you envision that this will be more widely deployed moving forward or how do you see this unfolding?
[00:26:52] Speaker A: Well, really I think what probably needs to happen is the vendors who ship the software for authoritative DNS servers need to turn this on default because don't believe that it is right now. And that's somewhat problematic. There are relatively few people, relatively small percentage of people who maintain DNS infrastructure who also understand it well enough to know, oh yeah, I should probably turn on response rate limiting given where I'm setting up this authoritative DNS server.
[00:27:21] Speaker C: Yeah. So again, going back to my question before in the wild, there's 220 interviews out there. Those 220 I can't really remember anyone focusing on their concerns around DNS. So again, would you assume that it's something that's just overlooked, that people are not thinking about? Because there's all these other things that are out there, that ransomware, and now we're worried about data breaches and the OAIC coming after you and penalties and fines and media retention. So does this just get lost in the bucket of things? Because, again, it's just not something that's raised very often.
[00:28:01] Speaker A: Yeah. I mean, I do sometimes feel like sort of a voice crying out in the wilderness, but it is important. I mean, DNS really is critical technology, and it has the potential to be so helpful in combating all kinds of malicious activity on networks and also giving you visibility into what's happening on your network. I think all of that is so well worth evangelizing. Right. Which is why I'm here, why I'm talking about this for the next several weeks down here in New Zealand and Australia, and why I talk about it pretty much every week.
[00:28:36] Speaker C: That's a lie. It's every day for you, isn't it?
[00:28:38] Speaker A: Well, there are weekends. My wife doesn't put up with it if I talk about it too much on the weekend.
[00:28:43] Speaker C: So for people listening that maybe they have overlooked this, what are some of the things that people can start paying attention to from a security point of view? Is there anything that you'd like to sort of let people know about that perhaps from the work that you conduct that it's an obvious one for people to overlook?
[00:29:00] Speaker A: Yeah, I mean, one of the things that I think that folks ought to look into is, first of all, they may need to sort of reach across the aisle. I hope that metaphor exists down here too, but I'm sure it does. The networking folks are the ones who typically would manage DNS, and they may need to go to the security folk, their counterparts in security, and say, look, there are these mechanisms. I have heard that this might be useful. Or conversely, the security folks, maybe, who are listening to the podcast may have to reach across the aisle to the networking folks and say, hey, I've heard about this. Do you think we can do this with our DNS infrastructure? I think this could be important. And then you begin to look into what your current DNS infrastructure can support. Does it already have support for things like response policy zones? If not, could it be upgraded to, and then take a look out there at the landscape of response policy zones and other threat feeds that are available. Get those plumbed into your DNS infrastructure. Things will be much better for you.
[00:29:55] Speaker C: So would you say that there's not enough cross pollination? So the networking team going across to the security team, for example, and I mean, historically, security just used to be a team isolated on their own as an independent silo. And that's where a lot of the issues that we're facing today that we're trying to fit retrospectively now with the intel we've got around talking to other people in the team, or to your point, around leading across the aisle, do you think by doing that, which sounds so basic, but I don't know if enough people are doing that at all, because a lot of these teams are very separate and independent from one another?
[00:30:30] Speaker A: Yeah, I mean, we really view that as a big challenge, that in a lot of organizations, the networking folks and the security folks don't even meet up until those organizations don't meet until you hit maybe the CEO in some cases. Right. The security people go up through the CISO, the networking folks go up through the CIO. Those guys are both direct reports of the CEO. Then you probably don't have organizations that work all that well together. And that's really a shame, almost a crime, because there's so much that they could do together. There's so much that they could do if they were cooperating.
[00:31:07] Speaker C: So from a security perspective, what concerns you the most when you think about, you know, you've been in this space for so long, what does concern you the most at the moment?
[00:31:18] Speaker A: Well, there are some things that are, I think, threats to DNS that are sort of out of our hands, that are really more at the nation state level. China, for example, has had kind of their own Internet and their own part of the domain name system for some time. There are other countries that are threatening to at least cleave off some part of the Internet and some part of the namespace. I think that would be really sad, because one of the great things about the Internet, one of the great things about DNS is that it's universal, it's global, and that you can sit here, know Wellington, New Zealand, and you can look up stuff that's in Ulan Ba tour, Mongolia. I think that's amazing. And it would be a shame if we were to balkanize it. It would be a shame if we were to give up on that dream of the universality of the Internet.
[00:32:07] Speaker C: So your concerns more for geopolitical tensions, would you say, in order to amplify whether it's a DDoS attack, for example, is that sort of what your concerns are then?
[00:32:18] Speaker A: Yeah, I guess the reason that I'd be concerned about that is because I don't feel like most of us have any control over that. The individual threats like, hey, new species of malware or whatever, I feel like we can address those. We can take those on as they crop up. But the big geopolitical stuff, maybe there's nothing we can do about some of that.
[00:32:37] Speaker C: Yeah, probably not. I think recent events would probably indicate that. So then where does that leave us? Because if there's certain things that we have no control over, but they're still powerful, that can be weaponized against us, what does that mean moving forward?
[00:32:51] Speaker A: Well, I think that we keep fighting the good fight. We make sure that we preserve those things about the Internet that are important to us, that are good. If some players decide to pick up their portion of the Internet, go home with it, we may not be able to affect that. But on the other hand, we can keep the rest of the Internet a free and open place.
[00:33:12] Speaker C: Do you still think the Internet is a bit of a wild west, though? Because when I start thinking about it, I'm like, it's still, like, not the way people envision it. Sometimes it feels like it's stuck together with duct tape and sticky tape at times.
[00:33:25] Speaker A: Yeah, I mean, that it's a wild west. There are so many different parts of the Internet. I think the Internet is so large now that it's difficult to say anything in general about it.
In the United States, there's gigantic parts of the Internet that are hosted by Azure and AWS, and there are huge ISP networks that are, some of them quite well run and some of them not so well run. So it varies a ton. And there are some places of some parts of the Internet that are really cesspool. Some organizations that harbor a lot of malicious activity, which is too bad. But again, it's so large that I don't think it's fair to say anything general about it. Like it's held together with bubblegum and debiling wire.
[00:34:16] Speaker C: So what about moving forward now? Is there anything that you'd like to leave our audience with today from. Yes, the DNS point of view, but also wrapping that around from a security perspective, you did touch on before that there's some developments being made. Is there anything specific you'd like to leave our audience with today? Cricket?
[00:34:31] Speaker A: Well, I mean, the main thing is basically what we've been talking about over the last 15 or 20 minutes, which is, hey, DNS can be a fantastic security tool. Please take a look at that. This is a security podcast there are a lot of very bright security professionals listening to it, and I would love it if even a handful of them decided, hey, maybe ought to look into this. Maybe ought to check out these response policy zones or this idea of protective DNS and see if this is something that I can take advantage of myself.
[00:35:03] Speaker B: This is KVCast, the voice of cyber.
[00:35:07] Speaker C: Thanks for tuning in. For more industry leading news and thought provoking articles, visit KBI Media to get access today.
[00:35:15] Speaker B: This episode is brought to you by Mercsec, your smarter route to security talent. Mercsec's executive search has helped enterprise organization find the right people from around the world since 2012. Their ondemand talent acquisition team helps startups and midsize businesses scale faster and more efficiently. Find out
[email protected]. Today.
