The Unknown Complexities of DNS Resolution

MG:
All right, interesting topic today. We're taking a different, a bit of a different tack. We're gonna do a bit more of a technical topic and specifically focus on an area that's really important as it relates to ASM asset discovery, and that's DNS and DNS resolution. There's a lot of unknown or unseen complexities that you don't really uncover until you're trying to do this at scale that have a lot of impact in terms of you know, how that impacts the performance and the output and the results of an ASM product. And so we're going to dive into some of those technical challenges, some of the implications for that, you know, and our experiences, you know, dealing with those challenges and solving them, you know, with our platform. So, I'll kick over to Shubbs. Do you want to give some background on this and maybe start diving into some topics around the complexities of DNS resolution?

Shubs: Yeah, yeah, sure. Actually, I think one of the most important parts with DNS resolution, well, the reason why it's so important is because any real flaw in DNS resolution or any misunderstanding of what assets resolve to can lead to huge negative consequences for any security scanning solution, any ASM provider. So that's why, first, that's why we've spent so much time. on it, I think, and why we've had to really perfect it over the years. And I do think that the problem of DNS resolution at the scales that we're talking about, which is hundreds of thousands of assets, millions of assets every hour, we start to run into some pretty interesting problems. And this isn't a foreign concept. I think a lot of people that have gone down this road have realized how brittle it is to actually resolve this number of assets or this number of subdomains in a reasonable amount of time. And we've had many, many approaches throughout the history of AssetNote. So there's a lot of learnings, I guess, with that, which we can go into. But I think the first thing that I'd like to probably kick off on, and it's probably something that you and I are painfully aware of, is this concept of DNS wildcards. It's something that none of our customers really expect to see a lot of assets where they aren't really assets that are pointing to any real applications. They're assets that were set up as a DNS wildcard and maybe for the audience that don't know what a DNS wildcard is, It's where you can set up a DNS record that says, you know, asterisk dot this subdomain or whatever it is, points to a specific IP. Now, that is a very basic form of a wildcard. There are some more complex wildcards out there, some that do round robin and different IP addresses and things like that. But in the general broad concept, it's where you basically say asterisk of a zone points to a specific set of IPs or a specific IP. Now, why this is not that useful from… It has a lot of obvious implications, right?

MG: Yes. From an asset discovery perspective, particularly if you're looking for subdomains. And what's really interesting to see is how many people just kind of ignore wildcards in a way from an asset discovery perspective, because, you know, to your point, right, they're essentially junk assets, right? They look real in the sense that they're resolving, but they're not necessarily, they don't necessarily have the substance that you would expect for an actual true asset, right? That it's, you know, there's something there with that asset. Because with the wildcard, you could type in just a random subdomain string and it would still resolve, right? And it's clearly nothing, right? But it looks real. And I know there's a lot of, a lot of tools out there that basically ignore this. And, you know, if you've got, you know, an attack surface, maybe you run a bounty program, there's people doing a lot of brute forcing and things like that, that'll flow through to, you know, say passive DNS, which is a common source for ASM tools for subdomain data. And, you know, it might show for a particular domain that you've got you know, sometimes millions of subdomains that aren't actually real subdomains or real assets in the context of having any substance there. So that's why it's really important to kind of, you know, if you are focused as we are on signal in your attack surface and then flowing through to everything else that you might do with those assets, whether it's security scanning or otherwise, if you're focused on that, this is a big thing to get right.

Shubs: Yeah, it definitely is. And there's a lot of complexity to it. I think that there are some really naive approaches dealing with DNS wildcards. And to be fair, that gets you maybe 60, 70% across the line. But what I guess what we found over the last six years is that this isn't foolproof. We'll often find that there's you know, DNS wildcards that are rotating through a large set of IP addresses. And in that case, we've had to really go back and fortify what we've built for DNS wildcard detection to be able to handle those cases. And this is one of the things where I think, especially in the open source community, I think that there's not as much, I guess, innovation or support for DNS wildcard filtering. I think that this is something that's kind of left as an exercise to the reader. And everyone has their own implementation of how to do this. And everyone, you know, initially probably starts off thinking that this is going to be enough to cover 99% of use cases. And then suddenly they realize, no, it actually really covers 60, 70%. So I guess, you know, one of the things I'm trying to get across there is that DNS wildcards aren't as simple as like a very basic benign check to see if there's a wildcard there and then just filtering it. There's many cases where you can either lose results which are valuable or you can just filter too heavily, to be honest.

MG: There's a balance that needs to be struck, right? You need to figure out an approach that gives you accuracy that doesn't allow too many wildcards in or any ideally. But then also doesn't exclude or filter out real assets there. And that's where the real challenge is of getting your own data.

Shubs: Yeah. And this is the other interesting part when we think about ASMs in general and what we've seen in the market, I guess. We either see it go in one or two directions, really. One, where they just include the wildcards as a part of their scope and as part of their assets. It's something that you and I have spoken about. And then a customer might see, oh, I've got 30,000 assets, but in reality they only have like 120. And then there's the other side where they just filter it out and they don't give the customer any option to really do anything about that. and they just got to trust that whatever algorithm they've got at the back end to filter out wildcards is a reliable way of doing it. So yeah, there's these two different approaches. I guess we kind of sit in the middle there. We filter out wildcards, we put them in a different section, we let customers verify them if they want to. And we have a few other processes that make sure that this is all good.

MG: Our approach is to broadly focus on having really robust wildcard detection, such that we do filter out a whole bunch of, you know, the majority, if not all of the wildcards by default, but also not necessarily just excluding them. We kind of treat them differently and then people can sort of, you know, judge the results for themselves. In terms of what we see though, almost none of our customers need to do that, right? you know, the wildcard assets that we filter out are genuine wildcards. And, you know, we find that's a better approach than necessarily taking one of these all-in extremes, where you just filter it out and then you might potentially miss some, even though we don't really have that problem. But the other extreme, I think, is more of the problem, and it's more prevalent in what we see, which is people just ignoring it and just putting everything in wholesale. And it comes again from this idea, maybe it comes from a couple of areas, but I think it comes from this idea that they're broadly afraid to miss stuff, right? And so, you're better off putting in false positives than sort of a false negative in a way. And I think for us, the approach that we take is just to work at the problem as deeply as we can to get that confidence that we need to be like, this is working and what we present are real assets. And maybe there's an element of what you were mentioning earlier, which is the sort of open source tooling in this space doesn't really do much as it relates to wildcard filtering or wildcard detection. And so, for better or for worse, a lot of a lot of products in this space, particularly recently, you know, I just built off the back of these open source tools in a really naive way, because they haven't necessarily had to build the whole system from scratch as we did, because, you know, we've been around well before these open source tools were released, right? And so, you know, we had to, you know, interrogate that problem more deeply, just as a matter of practicality in terms of building this. and as a requirement. So perhaps that's the root cause, but it does flow into a lot of issues down the road. You mentioned, you know, customers. I remember being on a demo not too long ago where a customer, you know, we're going through our regular flow and we're back and forth questions. And the customer asks us, hey, can you go to this specific domain and show me what subdomains you have? you know, went there and it was like, I don't know, it was like a couple of hundred subdomains. And initially I was thinking like, oh, well, you know, have we missed something here? Like what's going on, you know? And they're like, no, no, that's right. That's, you know, we have, we've looked at a bunch of other tools and they've shown us thousands of assets under this subdomain, which we know is not right. We know it's not real. And then I'm like, oh, okay, let me show you. And I went to a section, you know, where we have the wildcards filtered out. And lo and behold, it had like three, four thousand, you know, subdomains filtered out. And, you know, and then that's sort of why it matters, right? You know, these guys want to get a view of their attack surface. And they want to know what's really there because what you do with those assets is important. And so if you're going to do something with those assets, they have to be real and relevant. Otherwise, it's just a waste and it's just noise.

Shubs: Yeah, and if you're going to be doing anything practical with these assets, then you need to make sure that what you're doing is optimized for what you're trying to achieve. For example, if we're going to do security scanning, you don't want to do it on hundreds of thousands of fake assets, really. So yeah, that makes total sense. And it kind of goes into the second topic of, you know, why it's so valuable to, for one, for why is it even so valuable for us to invest so heavily in this DNS-centric approach for discovering and scanning assets? And this is something that, you know, we've got many people on the market that take a very IP-centric approach. This is something that you've spoken about, Michael, in the past where You've got a lot of players out there that scan the entire internet and then they catalog all the IP addresses. And then there's some level of, I guess, metadata extraction on all of these IP addresses to attribute them back to companies. Now, there's this thing where I think that a lot of people haven't really spoken about too much, but it's basically where all of these providers that are taking the IP-centric approach have a huge gap, like a blind spot, if you'd call it, in reconnaissance, in discovery, and in scanning. And the reason why I'll explain this to you, and maybe for the people listening to this will understand this if they've dealt with this data, There are a lot of providers out there today that do not work on an IP first basis. For example, you think about Cloudflare, you think about Akamai, you think about any WAF, you think about any like reverse proxy, they're not dealing on an IP first basis. You hit the IP address and Cloudflare is going to say, yeah, if you give me the correct, you know, SNI and the correct host header, I might route you to the right location. But when you visit my IP address just by itself, I'm just going to give you a generic cloudflare page and you're not going to know what is underlying, what is there, what's underlying asset, what the underlying asset is. Which is why I think, you know, a lot of these approaches are going to eventually become less and less valuable for scanning the entire internet on an IP-centric basis. I'm not saying that we shouldn't do that. We already do do that at AssetNote. We do that, but it shouldn't be your sole approach to discovery. It's just a part of it. Yeah, it's just a part of it. And this is the thing where I see this time after time, whenever you look at a complex attack surface, and especially the larger companies, they've got Akamai everywhere, or they've got some WAF everywhere. And you look at this attack surface from an IP-centric view, and you're actually seeing, I would say, I would guesstimate, like in most cases, like 40-50% of the actual attack surface, which is really poor, right? And you might see that there's, you know, however many IPs on the internet. And this data is still very valuable, because often it's origin IP addresses. It's actually IPs that probably shouldn't be not going through a WAF. But if you want to get actual coverage, you need to do this level of DNS resolution. You need to do something in enumeration. You need to be sending the correct host header. You need to be sending the correct SNI. So yeah, I don't know.

MG: What are your thoughts on that? I think these approaches are an extension of kind of a legacy approach. You know, if you think, you know, one of the things that we talk about all the time is that security doesn't exist in this vacuum, right? Security is, you know, gets influenced by and is sort of a function of the larger IT landscape in general, right? And so if you think historically when you know, everybody had a range and they had a data center with physical boxes, right? And every asset that you owned fit in that range, right? So having an IP-centric perspective, you know, makes sense. And then, you know, once we, you know, once sort of, you know, processing and things became a little easier, people were like, well, actually, I can just, rather than focusing on a small range, I can scan the entire IPv4 address space, you know, in a reasonable amount of time and that sort of, you know, where a lot of these sort of early tools sort of came from, right? And that's why they take a very IP-centric approach. And so, Megan, sorry. All right, we're gonna, let me, can I put myself on fucking do not disturb? Sorry, we're gonna have to re-record this bit. It's just ringing me out of the blue. Um, okay. Um, all right. Sorry. So, so maybe I'll take it from the top for the IP centric stuff, right? Yeah. Okay. So yeah, I mean, the IP centric view, I think was born out of, you know, born out of more of a legacy view of things, right? If you think, you know, back in the day, you know, and one of the things that we say a lot is that, you know, security and security tooling is a function of the broader IT landscape and how that's evolving. And if you think, you know, back in the day, right, you had a data center, you had an IP range and every asset that you owned, you know, sat in that range, right? And so, so having an IP centric view, you know, made sense back then, you know, going back, so to say, 20 years or so. But, you know, and then as, as, I guess, processing power and technology and whatever got better, you know, people then extended that out and were like, hey, we can scan the entire IPv4 address space in a reasonable amount of time, and that's where a lot of these tools were born. But, you know, when you sort of go further along the timeline, kind of like what you were alluding to and suggesting, is that You know, you've now got cloud providers, you've now got WAFs, and IPs don't hold the same significance that they used to hold, right? They're more ephemeral, they're more fleeting in nature, they're reused. You know, so there's an element where you can't necessarily tie single IP to an asset very cleanly on its own, right? Because, you know, these cloud providers, you know, have a shared IP space that then, you know, as you sort of spin things up and spin down, you know, that IP space gets shared across their customers and reallocated. to different customers of that cloud provider. So you can't necessarily say, you know, like you could when you had a range that was registered to a company, and you had all the IPs in that range, and you could say, yep, that's yours, right? You can't really do that anymore. So, you know, taking a purely IP centric approach, you know, has a lot of drawbacks when it comes to asset discovery and ASM, you know, for that reason. And so and then, I mean, if you if you go even further out and, you know, this is maybe a pipe dream that a lot of people have, but, you know, is whether IPv6 gets broad adoption, right? And if IPv6 gets broad adoption, then the ability to scan that entire address space is a lot more limited, at least from a reasonable timeframe perspective. And so DNS information, I think becomes very significantly important in this in terms of understanding attack surfaces and understanding what assets people have.

Shubs: Yeah, yeah, I fully agree with you. And there has been, there has been a lot of efforts, I guess, from these providers that try and do this internet wide scanning to even cover IPv6. Some of them are very, very questionable in nature. So they've come up with strategies that I think if the common layman knew about, Lehman knew about this, they would be like, wow, I don't really trust these guys as much anymore because they're doing dodgy things to figure out IPv6 as soon as they come on the internet. So there's definitely a bit of that going on as well. But yeah, I agree with you entirely. Scanning IPv6 ranges is not really a realistic way of looking at scanning the internet in the future. And yeah, it is probably a pipe dream, but who knows? The adoption is increasing every year and more and more things are getting ready for IPv6. But I think that discovery is not going to be the only problem with IPv6. I think there's going to be a lot more problems like attribution and realizing that, oh crap, all the rate limiting technologies we've built in the last 20 years aren't going to be that valuable at IPv6 level. But yeah, yeah, definitely. And I think with DNS records, there is something that's really interesting from a resolution perspective. And this is certainly something you can do if you just started resolving things in mass today. You might decide, okay, I'm going to pick like the four or five largest DNS resolvers on the internet, and I'm going to pipe all my traffic. through them and then you might think that's probably the easiest way to start off and look that can get you somewhere at a certain scale that can get you some places but what you'll find eventually is that a lot of these DNS resolvers do things like rate limit you or provide incorrect results or just not respond to you after a certain time of slamming them so that's not really an approach that you can take long term and it's not really something that I would recommend And you know, something that we ended up doing was we were like, oh, how hard can it be to manage our own DNS resolution farm or whatever? And we spun up a bunch of boxes to try and get unbound servers to do our DNS resolutions. And we found actually DNS resolution is a lot harder of a problem than we originally thought. Yeah, we can have a bunch of random resolvers there, but things like speed and reliability really come into play. And when we're looking at the speed and reliability of some of these large providers like Cloudflare or Google, they've invested a lot of time, a lot of effort, a lot of engineering to get to that level of scale and reliability. It's not something to be taken lightly. I often hear about, you know, some people being like, oh, I just set up a, you know, a DNS resolution farm, whatever, or a server, and that's good enough for me. And it's like, okay, it might be good enough for now, but the second you start scaling it out, you'll probably realize there's problems with the data. There's probably problems with how, like, reliable it is. There's problems with how fast you can go. And these things are not easy problems to solve. You know, I think that over the last six years, we've had to really, really get to a solution that can scale out to, you know, millions and millions and millions of resolutions within a very short period of time. And that's been a very interesting journey. And I think my I guess my only message to people that are going down this path is that DNS resolution at scale is not as straightforward or easy as it sounds. I think there's a lot of complexities there, especially when it comes to reliability, monitoring, making sure that everything is actually really fast as well as reliable is a tricky thing to do.

MG: Yeah, yeah. Yeah, and so just to give a sense as well of when we talk about scaling this out of, you know, what we've built and how we operate, we do everything on an hourly basis. So all of the processes in our platform run on an hourly basis, sometimes more, but, you know, as in more frequently, but generally speaking, it's an hourly basis. And so resolution, you know, we're doing across, you know, millions of assets on an hourly basis. So it is quite an interesting technical challenge and engineering challenge, not just thinking about, you know, the processes of that and thinking about the nuances of that as it relates to our product, you know, like wildcards like we discussed, but also just, you know, just from a pure, you know, infrastructure management kind of level as well of just keeping things up and working reliably when you're operating at that kind of scale. And you know, you make a good point, like if you're like say a bug bounty hunter wanting to do some sort of resolution, you know, at a much more reasonable scale and speed, maybe you're only focusing on a small target, or you don't care necessarily about being as fast as we are, then yeah, a lot of the stuff that we've discussed can get you a certain way. But once you get past a certain point, and you want to do this far and wide, but also reliably at speed, you do start to run into these problems. And to your point earlier, again, just to reinforce that, a lot of the open source tools are not going to consider this, right? So if you just think you're just gonna ramp up utilizing these tools, you're going to run into these problems. And if you don't have, like we do, like one of the things that we've invested heavily in you know, just across the board, but especially as it relates to our DNS infrastructure, is observability, right, of how that's running. And so, you know, if you don't do that, you may not necessarily pick up that you do have problems here. And then that will flow through ultimately, you know, to the results that you're getting at the end of the day.

Shubs: Yeah, for sure.

MG: What are some of the other challenges, you know, in terms of, you know, maybe talking about that, right? Because I know that we definitely have had some issues with, say, infrastructure providers as it relates to doing things at scale. You know, maybe you can talk a little bit about our experiences there.

Shubs: Yeah, I think primarily, if you're someone that's deciding to run your reconnaissance stack on a provider like AWS, there are some pretty hard limitations with what you're able to do. And look, there are some solutions that can get you a bit further, but I think you'll still end up hitting some limitations of basically what AWS's software-defined networking stack is. So whenever there's state involved, for example, there's a security group or there's some sort of networking state involved where there has to be state tracking throughout the network and you've got the software-defined network doing that as part of AWS's networking stack, you are going to see a lot of network issues, especially with things like scanning at scale, things like resolving at scale. So a lot of these issues I think can be resolved to some extent by making sure that there's no real state tracking happening. That includes removing all security groups and all that sort of stuff. But even then, I still think there are some pretty hard limitations with AWS unless you pay for some really expensive instances, which I guess there's limits to that. I don't know how much you want to pay for your reconnaissance stack at the end of the day, but I'm pretty sure that these instances aren't really worth that much to be paying just to be able to get a little bit of network reliability. So we've obviously gone through that whole journey ourselves. To be fair, we were extremely confused going through this journey because we had gone through all the different channels to realize at the end, wow, this is actually just a limitation of my instance. This is a limitation of if we wanted to really get to the speed and scale we're talking about, we're going to have to pay for some extremely expensive AWS instance. Whereas in reality, we could just go with any of the other cloud providers that don't do this. Well, some of the other cloud providers. that are a bit more traditional in nature and don't have this software-defined networking stack that AWS does. And look, I'm not saying that AWS's software-defined networking stack isn't a great feature. It allows for a lot of flexibility for a majority of use cases where you want to have security groups, you want to have certain rules and stuff that make sense. But for our use case, where we actually do need access to the networking stack in a way that's very efficient and reliable and can scale, we actually found that relying on AWS's networking stack unless paying for really large instances is not a viable strategy when it comes to doing this reconnaissance work. So we do utilize other cloud providers for this and we do have connections back in, but that's a bit of a lesson for us in the last six years that we've learned and we now know very well. So it's good knowledge.

MG: Yeah, I mean, it's important, as I said, you know, another reason why we focus very heavily on, you know, diving as deep as we've done. It is, to your point, a reasonably niche case if you think about AWS and these cloud providers, you know, as a whole, right? But, you know, for ASM, like, it is a really important use case. And it's important because of how this stuff flows through, right? And it flows through to things like scanning, right? So for example, if you're not detecting an asset is online or resolving because of problems in your stack, then that typically will mean that you don't scan it or you don't do any metadata collection or anything else on that asset. And you're saying that the asset is not internet accessible, right? is a pretty fundamental element of ESM. And so, you know, if you're not doing this accurately, you're missing out on results. And at the end of the day, your product is not as effective in giving visibility into the attack surface, and then by extension, you know, visibility into the exposure. And so, you know, you need to get these things right. And you know, maybe we can talk a little bit about, you know, how we then, you know, take some of this and apply this in some of the other areas of our platform. So I know, for example, you know, when we, not just in terms of whether we consider an asset online or internet accessible, but when we go through to do our security scanning, we factor in, you know, the various DNS records that are there as well. So, you know, can you maybe dive into that a little bit more and why we do that?

Shubs: Yeah, for sure. I mean, there's many cases nowadays where you have a subdomain that points to either a load balancer that has several DNS records, or you just have a load balancing methodology with a single subdomain pointing to X number of IP addresses that rotate over time. And this is an interesting thing for us to be aware of, because And I have seen this in my career in security testing and just in general where you will have a subdomain record that points to, let's say, a set of four IPs. Out of those four IPs, only one of them is vulnerable because only one of them has had, like it might be load balanced, right? So there might be different servers on the other end. but it's just DNS load balancing at the end of the day. And even though it's the same application, you might have one of those IP addresses that don't have the patches applied or they don't have the necessary changes to fix a certain vulnerability. And what that means is if you're just taking a very simplistic approach and you're just scanning the first record or just one record, then you have a chance of missing these issues from a security scanning perspective. So, yeah, one of the things we do is we actually round robin our security scanning throughout these IP addresses, and we make sure we get as much coverage as possible throughout our scan cycles. So this is definitely, you know, an important topic. and one where we're trying to optimize for security vulnerabilities that we discover. But obviously we're not talking about scanning every DNS record for every subdomain all the time. We're talking about evening it out and scanning as much as we can over time. So that's kind of the concept that we've taken and kind of the way we do it. It is a important thing to realize when thinking about security scanning and why security scanning through subdomain records is not as simple as just pointing it to the subdomain. We might have to specify which individual IP address it's resolving to that we want to actually scan. And that is quite important because if you just blindly trust the resolver, the resolver might pick any of those records, whatever comes first or whatever, and you don't actually have a real understanding of what you're scanning. really. So yeah.

MG: Yeah. Yeah. And you want to make sure that you're not missing things and you're getting that complete visibility, both on the discovery side, which we've spoken about, but also on the security scanning side. And you don't want you know, that sort of loan IP and, you know, just whichever method you're using for load balancing, right? You don't want that loan IP that's misconfigured to sort of be, you know, I guess missed or looked over because, you know, your scanner is not accounting for those sort of scenarios. We try to be as complete as we can be with this to make sure that we're not missing anything in the attack surface.

Shubs: Yeah. And, you know, sometimes when you do do this DNS resolution at scale, something you do realize is that there are a lot of quirks with how this works. And something that you and I came across a couple of years ago now is just DNS poisoning at scale. And, you know, Michael and I were giving a presentation in September at BSides Canberra about, you know, one, how we identified this DNS poisoning at scale, and two, how we practically exploited it. Given the fact that both Michael and I are from really offensive security backgrounds, we did work out a way not only to detect this DNS poisoning, but to meaningfully exploit it. And we'll obviously get into more details at this conference presentation, but Just something to note for the people that are interested in DNS resolutions is that when you are doing it at the speed and scale Sometimes you will come across some really weird stuff some stuff that we've seen where we're initially like Oh, let's filter these out and then we're like wait a second. There's a pattern here. Oh This pattern is a lot more than just this one customer. This pattern is wow. This may affect Tens of millions of domains gosh like that's a it's a big impact from something that started off as a simple investigation internally and turns into Probably one of the most large-scale DNS poisoning attacks. We've seen in the history of time So that's that's just you know, just just to put it lightly there. That's yeah.

MG: Yeah, and that's That particular one which will obviously dive into in the presentation. But yeah that that's kind of interesting again it came out of you know, building this and understanding what's going on here and understanding all the quirks. And this was just another one, another quirk that we're like, this is weird. And once you dive into it and you see those patterns, then you start to realize the bigger picture. But then it's, you know, the hacking brain kind of kicks in and it's like, oh, like, what if? And then you start trying those and you're like, wow, like these are this is successful and this is like mass scale. And so yeah, very interesting presentation. It's at B-Sides Canberra. So if folks are around, check it out. I'm sure it'll end up online at some point. We'll probably, you know, maybe we'll do another episode you know, after the presentation to talk about it. Or, you know, we'll probably maybe do a blog post as well. We'll see. But yeah, definitely, definitely very interesting. And again, it just came out of, you know, working on, working on, you know, managing the quirks of DNS across our very diverse customer base. Cool. I mean, are there any sort of other takeaways as it relates to, you know, DNS resolution, managing DNS, you know, in a tax service management context that you'd want to put out there?

Shubs: Yeah, I think the one last thing that I'll quickly just kind of talk about from a security perspective is I think there's a lot of people out there that don't really understand security context for DNS records. So for example, specifically when you've got certain status codes being returned by DNS servers, when you do a lookup, And I think this is something that we've definitely spent a lot of time on internally to build detections and to inform customers about where these risks are. But with DNS alone, it's quite straightforward to test whether or not there are there are really DNS misconfigurations on attack surfaces. And this is something that we focus on quite heavily as well, and something that we've spent a lot of time on. But I guess I just want to, I think the big thing I want to end this podcast on is just the importance of this data, the importance of DNS data, the importance of having this coverage over this attack surface from this perspective and this lens and why it's so important. And I think there's a lot of people out there that kind of rely on these IP-centric tools as a be-all and end-all of discovery and I just, the only real message I want to, I want to get across is that that is not a sufficient way to cover your attack surface in its entirety. And personally, as someone that's been spending so much time doing reconnaissance and discovery and, and building automation for it, I, I really can see the gap. Uh, when you look at these IP centric tools, you can see the clear gap in what they're missing from a discovery perspective. Now, as I said earlier, I'm not saying that these tools aren't great for what they're great at, but there is a gap, a meaningful gap when it comes to discovery. And I think subdomain data, DNS data, for reasons that you've even explained earlier today, like IPv6 and other things like that, it is going to continue being a first-class citizen in discovery and reconnaissance. And I think that people need to focus on it as a first class citizen. They need to stop focusing on IPs as a first class citizen, maybe second class, and then subdomain data as a first class.

MG: Yeah, 100%. And, you know, I think it's kind of interesting, you know, where our approach is sort of born from. And I think that sort of goes to the fundamental nature of why we do things the way that we do. is I think a lot of the IP-centric tools, you know, not just as we discussed earlier, you know, are coming from a legacy where that was much more effective. But, you know, just approach it in a different way. You know, it's, you know, those sort of tools are approaching it as a data gathering kind of exercise. And it's like, okay, well, you know, we've built this infrastructure to scan the entire internet, you know, how much can we gather and then we can search that and interrogate that, you know, and, and, you know, obviously, internet wide scanning, you know, an IP based scanning is an important part of being complete, right? And we do a bunch of it, we have a whole bunch of different, you know, internet wide, you know, scanning infrastructure as part of our discovery processes. But it's not all of it, right, as you pointed out. And DNS has a very important part to play. And I think where we're coming from is just that offensive mindset, that attacker's mindset. We're more focused on You know, when we have a target, you know, whether it's a customer, whether we're looking at a company for a bounty, whatever, however we might want to approach it or whatever context, it's like we're mapping out that particular company as complete as we possibly can. And it's kind of a different approach. When you think about it that way, it's less about this purely big data problem and more about, you know, what's the ultimate goal here? It's like, well, we're trying to map that out so they can see the full extent of it, but then, you know, do stuff with it, whether it's like more deeply understanding assets with enrichment or, you know, scan it for the kinds of, you know, high signal exposures that we look for. and that sort of exploitability based testing. And it's like, you really need to understand the bounds of that. And I think it may seem subtle, but the difference in the mindset and where we're coming from, I think it really changes the way that you approach the problem. And I think that's really where our perspective is, you know, at the end of the day. But yeah, I mean, this is a great topic. I know we could talk about DNS. I don't know if anybody would be interested in us talking about DNS for hours, but we probably could. But yeah, maybe we wrap it up there. There's definitely a lot of interesting follow-on discussion that we could have, but maybe we'll leave that for another episode. So I think this was good. I think we'll call it there. Thanks, Jobs.

Shubs: Sounds good. Thanks, guys.

‍