From Phonebooks to Phalanx: Cricket Liu on the Future of DNS
In this episode of The Defender’s Log, host David Redekop sat down with the “Godfather of DNS,” Cricket Liu, to discuss how the internet’s phonebook became its most vital defensive layer.
The Evolution of Protective DNS
Liu admits that in the early days, DNS was built on implicit trust. That changed in 2010 with the introduction of Response Policy Zones (RPZ). Liu helped pioneer the integration of threat feeds into DNS infrastructure, moving beyond “clumsy” manual blocklists to real-time protection.
Visibility vs. Privacy
The shift toward encrypted protocols like DoT (DNS over TLS) and DoH (DNS over HTTPS) creates a challenge for defenders:
- The Win: Massive privacy gains for roaming users and sensitive data.
- The Risk: A loss of visibility for traditional network monitoring.
- The Solution: Liu emphasizes that visibility remains at the recursive resolver. By collecting passive DNS telemetry, organizations can still perform forensics and detect lateral movement without compromising encryption.
The Path to Zero Trust
Liu highlights Zero Trust DNS (ZTDNS) as the next frontier. Imagine a device that refuses to connect to any IP address unless it has been validated by a trusted, encrypted protective resolver. This “portable perimeter” ensures security travels with the employee, regardless of their network.
A Legacy of Curiosity
Reflecting on 40 years of DNS, Liu credits its longevity to its elegant, extensible design. His advice for the next generation? Stay curious. The blueprints for the internet are free and public; the only barrier to entry is the hunger to learn.
Full episode of The Defender’s Log here:
TL;DR
- DNS as a Security Shield: DNS has evolved from a simple “phonebook” into Protective DNS, a critical first line of defense that blocks malicious domains before a connection is even established.
- Balancing Privacy and Visibility: While encryption (DoT/DoH) hides traffic from “middleman” snooping, defenders can still maintain visibility by analyzing passive DNS telemetry at the resolver level.
- The Rise of Zero Trust DNS: The future lies in Zero Trust DNS, where devices only connect to IP addresses validated by a trusted resolver, creating a “portable perimeter” that follows the user everywhere.
- Human Curiosity vs. AI: While attackers use AI to mask malware, the best defense remains human curiosity and using AI tools to find patterns in DNS data that “autopilot” systems miss.
Links
View it on YouTube: https://www.youtube.com/watch?v=PYZ-ngJsX8w
Listen to the episode on your favourite podcast platform:
Apple
https://podcasts.apple.com/us/podcast/protective-dns-and-the-future-of/id1829031081?i=1000766797085
Spotify
https://open.spotify.com/episode/6pDhWYmEPvn3mlhBhwVyhi
ADAMnetworks
https://adamnet.works
Full Transcript: The Defender’s Log - Episode 021
Narrator: Deep in the digital shadows where threats hide behind any random byte, a fearless crew of cybersecurity warriors guards the line between chaos and order—their epic battles rarely spoken of until today. Welcome to The Defender’s Log, where we crack open the secrets of top security chiefs, CISOs, and architects who faced the abyss and won. Here’s your host, David Redekop.
David Redekop: Welcome back to another episode of The Defender’s Log. And I have a very special guest with me today that really doesn’t need any introduction, but I will anyway, because Cricket Liu is really the “godfather of DNS” as a lot of people like to refer to him, but he is very approachable. And, I have yet to spend time with you in person, but I’ve known of you and about you for a very long time. Welcome, Cricket.
Cricket Liu: Yeah, thank you very much, David. It’s nice to be here.
David Redekop: Yeah. Well, you know, you’ve been in the DNS world for longer than the web has been a household name. Having been the author of DNS and BIND, did you ever imagine that the phonebook of the internet would eventually become one of the most critical security elements?
Cricket Liu: I don’t think I did, certainly for the first, I don’t know, 20 odd years of DNS’s history. I didn’t foresee that. It took smarter people like Paul Vixie and David Ulevitch to figure that out.
David Redekop: Wow. I have not heard that name, David Ulevitch, for some time. But yes, I know that David and Paul were very early on. And before it was called Protective DNS when Response Policy Zones were first conceived of and you were right in it, right at the beginning.
Cricket Liu: Yeah. We had, I was at Infoblox—Infoblox, I mean, from 2003 on. So, in 2010 when Paul and Vernon introduced the idea of Response Policy Zones, we had a kind of a block list functionality in our products at Infoblox. And, in order to populate the block list you needed to basically upload like a CSV or something to the Infoblox grid, which was a pretty clumsy way of handling things. And so when I read about Response Policy Zones, I thought, “Wow, this is so much better than what we’re doing currently.” And, I happened to be, on an interim basis, managing the product organization at Infoblox at that time. So, I dispatched one of my product managers, Pierre Ehsani, to write a project requirements definition for including support for RPZs in the product, and I think we were the first DDI vendor to actually have support for them.
David Redekop: That is really cool. And looking back, I can’t imagine us being without that as a security layer. We often say that Protective DNS now needs to be the first and last defense layer with other stuff in between in many cases. But, you know, and that brings me to a point of honest networking. In the early days, DNS was implicitly trusted, right? Like you were just expecting that there was no abuse, there was just, “Hey, this is my question, this is the answer that I got.” It was implicitly trusted, but that rapidly changed. How do you now, looking back, how do you now see that progression happening? Did it happen as fast as it should have?
Cricket Liu: I would say it’s probably not even complete. I’ve spent a lot of time out there sort of preaching the gospel of Protective DNS, and I would say that there are a lot of organizations that run DNS infrastructure and simply run it, we’d say, wide open, right? Without any particular care for whether or not a domain being looked up is malicious, or might be suspicious or what have you. So, I think the job’s not done yet.
David Redekop: Right. Yeah. One of the things that I learned from you guys and from a variety of Protective DNS proponents—again, long before it was called Protective DNS—was this idea of the first signal. And, was that something that was always obvious to you? Like, how did you get started where this area of DNS became a topic of interest for you?
Cricket Liu: Well, I think, it was probably not long after we started to add RPZ functionality to Infoblox’s products. And shortly after that, we realized, “Gosh, you know, we’re going to have some sort of a feed to provide customers who use this functionality.” It’s not that useful in and of itself. I mean, it is kind of handy as kind of a DNS administrator Swiss Army knife, if you will, for patching over things like somebody messes up a named IP address mapping on the internet. You can kind of spackle around it using RPZ. But, we saw the need for a threat feed to be able to provide that to customers using RPZs. And we went looking for partners and that, I think, led me to a company called Internet Identity. And, a friend of mine, Rod Rasmussen, who was the Chief Technology Officer of Internet Identity, which Infoblox later purchased—and that for me was, kind of, a turning point to understand the work that they were doing to populate these enormous databases, if you will, of malicious and suspicious domain names.
David Redekop: Right. That’s still a fascinating area of research for me because of the decentralization of the internet. It means that anybody can do anything. Good guys can do what they do and bad guys can do what they wanna do. And we’re left with being the defenders to basically determine which is for good intent and which is for bad intent. And that bad or malintent is a constant topic of judgment and of disambiguation. And I’m wondering if you could take us down that journey because you’ve been in it from the point of view of buying a feed, using someone else’s feed to adding stuff of your own, to doing malware research and then eventually getting into preemptive defense—that journey is of interest. Talk to us about that.
Cricket Liu: Yeah, so early on I think that IID was mainly—a lot of the threat intel they provided was as a reseller. They were maybe a broker, if you will. So they were able to aggregate DNS-based intelligence from a lot of different sources, and then provide that to folks. So you could sort of pick and choose what you wanted. Oh, some of the SURBL feed and some of the Spamhaus feed and some of this and some of that. Over time that changed. And today, the part of Infoblox that is the old Internet Identity, our Infoblox Threat Intelligence Unit, actually does most of their own research. And their research is really based on running analytics on passive DNS data. And now what we do is really produce threat intelligence that’s based almost entirely on running analytical algorithms over passive DNS data. And for folks who aren’t maybe familiar with that term passive DNS, that’s basically DNS telemetry. It’s just a record kept by DNS servers of all the responses that they get from other DNS servers. So whether those are referrals or answers or errors or whatever. Basically you aggregate all of that and you kind of boil it down a little bit so that it’s a little bit more compact, and then you can replicate it somewhere for later analysis. And that’s basically what we use. Along with say registration data, like who’s registered a particular domain name and when—that sort of thing. And, I think, that’s somewhat unique. If you compare that to, for example, like a Spamhaus or SURBL or an organization like that—those guys do great work. But what they’re doing is monitoring big phishing campaigns, collecting spam and spam traps. Doing analytics based on that stuff, which is tremendously valuable, but it doesn’t really start with the DNS data as far as I know.
David Redekop: Mm-hmm. Right. I find it super fascinating how this space has evolved over the last while and seeing the research that you guys produce on your blog. It really is impressive. And when you have the large aggregate amount of passive DNS data, you can do that kind of research. So, coming from a background in doing research and risk assessment, I find what you guys are doing quite admirable. And so thank you for making the internet a better place.
Cricket Liu: And I should give much credit to Renee Burton, who runs our threat intelligence unit. She’s wonderful. I know you’ve communicated with her. She’s super, super down to earth, very, very bright.
David Redekop: Yeah. No, that is very clear that she has that thinking style—that you need to always look for the pattern that isn’t necessarily obvious. We were just doing a study on walking backwards of all things, this afternoon before our call, because what I wanted to do was retrain my brain in areas where neurons have not been used for a while, and it turned out a very effective way to do that is just to do something that you don’t normally do, which is walking backwards. All of your habit patterns immediately become ingrained into going in autopilot. And when you’re in autopilot mode, you’re actually no longer developing. And the same thing applies, I think, to threat intelligence research—is to think about things differently because the attackers definitely have that skillset. Because every single time they take a certain direction for an attack that worked last time, they know they’re gonna have to tweak it a little bit for it to remain effective. Right? Which makes me wonder what’s coming after ClickFix?
Cricket Liu: That’s an area where AI is having a real effect on the bad guys because they get to use AI as a tool to, for example, customize malware for individual targets. I mean, not just organizations, but sometimes individuals, and to change the signature of a particular piece of malware so that it won’t trip any alarms on signature-based detection. So we’ve gotta have better mechanisms than that, and we have to use some of those same AI facilities on our own side.
David Redekop: Overall, we also are seeing a major shift towards DNS Security, and I don’t want to conflate it with DNSSEC because there’s tons of topics and discussions out there on the importance of DNSSEC, but I’m talking about encrypting the transit. So we have DNS over TLS, DNS over HTTPS—DoT and DoH as they’re often called—and DoQ now. From a purist’s perspective, this is a massive privacy win. But from a defender’s perspective, we’re losing visibility. Okay? Not your company or ours, but a lot of defenders are losing visibility. Give people some hope in that. How they can still value the privacy win and still maintain the visibility?
Cricket Liu: Yeah. Well, as an employee of a vendor that produces DNS servers or that sells DNS servers, one of the things I’d say is, yeah, I mean, if you’re implementing DoT and DoH across your organization, you probably will have a more difficult time monitoring the channels in between the DNS stub resolver and the recursive DNS servers, but the DNS servers still have access to all that information. So it’s a great time to make sure that you’re collecting passive DNS data from all of your DNS infrastructure and filtering it as necessary, but then saving it somewhere so that you can do later analysis forensics. You can follow up on successful breaches and find out, for example, if the bad guys, once they compromised a given server, tried to move laterally within the organization, and if so, how successful they were. All of that stuff is still possible as long as you have access to that passive DNS data, and that should come for free. Should be something that you can simply pull off of your Infoblox infrastructure or your open source BIND or Unbound infrastructure, almost anything that you might run out there. I’m not so sure about the Windows DNS server, but almost everything else would support collecting passive DNS.
David Redekop: Yeah, exactly. That information is still available. Just maybe not necessarily in the same format as before. What I like to remind folks of is that DNS is not meant to be like our Signal messages that are end-to-end encrypted. DNS is encrypted, even when done well, is encrypted from the endpoint to your internal resolver where you do have that visibility—from there potentially to another protective resolver and so forth—so that you end up with encrypted channels along the way. But because it’s so efficient, it really doesn’t matter if there’s one or two stops along the way, because that is how you’re going to get the right combination of a performance win as well as a security win. Does that jive with you?
Cricket Liu: Yeah, I think so. There were two other things that I thought might be worth mentioning about encrypted DNS and one of them is that if you have a lot of faith in the security of your underlying network, then you may not need, for example, DoT or DoH between your stub resolvers internally and your internal recursive DNS servers. So that’s one area where you may just say, “Hey, you know, we’re not gonna implement it there because I’m not concerned about the integrity of the underlying network.” On the other hand, if you are concerned about, for example, roaming employees, employees working from home, those sorts of things—then those are perfect places to put in DoT or DoH or DoQ. I still don’t know whether they pronounce DoQ as like “doc” or anything like that.
David Redekop: I have heard it both ways, but something tells me that like most English, it is by consensus. And IETF kind of runs on a consensus. So if enough of us say “doc”, then I guess eventually it’ll be “doc”, not to be confused with a Google Doc or…
Cricket Liu: The other thing about encrypted DNS is that at least as of right now, almost all communication above, say, your forwarder—so the communication between say your forwarder and the authoritative DNS servers on the internet that it communicates with—that’s unencrypted. That’s until we implement ADoT, which is Authoritative DNS over TLS—that’s unencrypted. And so there still is a lot of value in monitoring that traffic too. And your, any systems that you have that rely on sniffing that traffic to detect untoward activity can, would still work.
David Redekop: Cricket, I believe you and Ross Gibson and one other contributor were part of the authorship of the latest NIST DNS Security Guidance. And, I noticed in there—this is not a criticism—but I noticed that the DNR and DDR RFCs were not included. And now that makes sense because you’re talking about, maybe the industry isn’t quite ready yet to have the stub resolver to the internal caching or recursive resolver secured because 99% of endpoints out there—IoT, OT—wouldn’t even know what to do with it anyway. Is that what the reasoning was?
Cricket Liu: Yeah. You know, I don’t know that we really thought that much about it. It may simply have been an oversight and some future version of NIST Special Publication 800-81 may have to include that. But I do think at this point we’re probably not in a position to say, “Hey, look, all internal communication between stub resolvers and recursive DNS servers has to be encrypted.” I think we’ll probably get there at some point. We’ll probably—it’ll be a little bit like the evolution of the web, for example, where, I mean, basically all traffic is run over TLS nowadays. And it’s an exception if you see a connection from your web browser to something that is not encrypted. But, for right now, I mean, one of the things that you pointed out, for example, was like IoT devices. Well, they have stub resolvers, and those do not support DoT or DoH. And probably for the foreseeable future won’t. So we’re gonna have a fair amount of unencrypted DNS running over our internal networks for a while.
David Redekop: Right. I’m equally surprised at how little support there is, as I am surprised on the stuff that insists on it. You know, like, Android insists on DoT right away, Home Assistant, you know, of all things insists on DoT right away. So there are like outliers out there where somebody clearly felt that this was important. But no, the reason I mentioned that is because the old days—olden days—we were protecting the castle with the moat; in a Zero Trust world the moat is kind of dissolving away. And so that’s where DNS can act as that portable perimeter. You know, for a remote workforce, like you were talking about people that work from home—is that still the path that we’re on?
Cricket Liu: Oh, I hope so. I mean, I’m still out there sort of beating the drum trying to get folks to implement Protective DNS whenever possible. And I mean, Protective DNS is fantastic because it does provide really that very—the moat, if you will, right? That very first layer of security. So you don’t have to worry, for example, about someone clicking on the link in the phishing email because the link’s not gonna work if the phishing site is in your threat feeds. Likewise, if the device becomes infected and calls out to some command and control infrastructure on the internet—that communication isn’t gonna succeed if we know the domain name of the command and control server and we already have it in the threat feed. All of that I think is so important. It’s gotten to the point now where—I don’t say this because I don’t wanna be rude—but, when I meet with customers and they say, “Yeah, we don’t have any Protective DNS infrastructure.” I describe it to them and they say, “Yeah, I’m not sure.” I think to myself, “Why wouldn’t you do that? Like, why on earth would you not deploy Protective DNS?” You never want to be in a position where there’s some successful breach or some huge ransomware attack or whatever, and you find out after the fact that the command and control server for that particular piece of ransomware was well-known and was in the DNS threat feeds, and you could have prevented the whole thing from happening just by having, for example, Response Policy Zones plumbed into your infrastructure.
David Redekop: I think for those of us that have been in this space for a while, the power of Protective DNS is so obvious to us, but because it’s not a default—I mean, let’s face it, the default of any CPE device, whether it’s a small business or an enterprise—the ISP equipment, by default, will have indiscriminate access and there’ll be zero filtering, and they’ll probably default to quad-eight because that just works and it’s always up, and it’s Anycast and all of those things. Because the business of the ISP is to provide connectivity, the business of an IT provider is to provide availability, and security is only down the line of priority. So, unfortunately, very often it goes too far down the list of priorities. When I take a look at the threat reports that you guys issue on a regular basis, I’m always wondering what kind of enterprise client even was exposed to that risk to begin with because Protective DNS had multiple opportunities to stop that threat along the way.
Cricket Liu: Yeah. And sometimes, we’ll go back after the fact—working with a customer of ours who might have been affected by something, you know, some breach—and find out, for example, that they had Protective DNS in place, but they just had it set to log and not block, for example. Which is kind of sad. It’s tragic—that they had the opportunity to block it, but they didn’t.
David Redekop: Right. And I understand why you might do that for a very short period of time in order to adopt some kind of learning mode to analyze what are some really important domain names, because that’s how you find out what all the private namespaces that are being used. What we often find during deployment, when we ask, “Okay, during learning mode, what are all these domains?” They’re like, “That’s on our network,” and a lot of people are shocked what happens during logging-only mode. But that, I guess, what ends up happening is priorities get shifted in an organization—you never have enough resources for the right protective or budgeting for the right amount of protective efforts—that the project that got started kind of got stalled.
Cricket Liu: Yeah, I mean, there are certainly any number of reasons that you might initially want to have something running in logging-only mode. You want to make sure that it’s not gonna block anything that you don’t want it to block. Maybe there’s some stuff that you find in there that you wanna whitelist before you turn on blocking and so on. But the goal over time is to actually block stuff.
David Redekop: No, absolutely. Cricket, we often talk about segmentation and even micro-segmentation. Talk to us about how that applies to the world of DNS risk profiles. How they aren’t the same for a user device as they are for, say, a server VLAN?
Cricket Liu: Yeah, I think that’s super clever. Basically, what Microsoft did was to sort of put together encrypted DNS and Protective DNS, and they made some fairly minor modest modifications to the TCP/IP stack in their operating system. So basically what happens is that if you have a Microsoft Windows client in one of these Zero Trust DNS environments, the TCP/IP stack is configured to say, “I will not connect to any IP address that has not been resolved by a DNS server—a Protective DNS server that I use.” And “I know this is the Protective DNS server that I want to use because I’m using encrypted DNS to communicate with it. I’m doing some sort of server authentication because it’s TLS.” And if the Protective DNS server says, “Hey, I’m returning you this IP address, therefore it’s safe—it’s passed all of the checks that I’m doing,” then you can connect there. But, unless there are pre-configured exceptions, you couldn’t, for example, just connect to a bare IP address literal; you’re not allowed to do that anymore. So that’s a pretty interesting notion, right? You couldn’t, for example, just install some piece of software that used a different DNS server—that’s not allowed. You have to use one of the Protective DNS servers and can’t reach out to these IP address literals. The idea, as I understand it from talking to the former product manager for ZTDNS at Microsoft, the idea is that in a Zero Trust environment, what will happen is not that the Protective DNS server will filter out bad destinations, it’s the opposite—it will only let you go to known-good destinations. So that, I think, is sort of maybe your server example, right? I mean, a server you could possibly enumerate the sorts of places that it actually would need to go. Probably less likely you could do that with somebody’s desktop machine or laptop or whatever, because who knows, you know, what they see on a billboard or what QR code they scan or who knows what else. But it’s a very interesting idea. I think that we could effectively gate or wall off the environment that a particular device could go to through the use of something like Zero Trust DNS. And what’s really cool about the Zero Trust DNS approach of Microsoft is that it travels with a device—unlike if you are relying strictly on the perimeter controls and then when the device leaves that perimeter, it leaves unprotected—the Zero Trust DNS travels with it.
David Redekop: Yeah, that’s pretty cool. And, we have a series of podcasts that we’ve recorded with Microsoft on this topic. So, I’ll be very excited to share that with you when they get released. But I think it’s moving the needle in the right direction where you’re moving the protection closest to the endpoint possible, and making sure that you look at the egress side of it by allow-listing for a short period of time those trusted-resolved IP addresses. When you take a look at the threat landscape today, a lot of the threats that you guys publish, you can see exactly where in the attack chain this approach would actually disrupt it entirely. And so if most of modern day’s threat actors attack chain cannot execute, they’re gonna have to move to another victim. Or, you know, ideally, get off of the malware business altogether.
Cricket Liu: Move to the good side.
David Redekop: Yes. Wouldn’t that be nice?
Cricket Liu: Wouldn’t that be, yeah.
David Redekop: So let’s talk about DNSSEC, just very briefly though, because you have been a very good proponent and an advocate for it for a very long time. But when I checked this week, we only have still less than 7% of active internet zones signed.
Cricket Liu: Yeah, well, it really sort of depends. It’s interesting like if you’re looking to see which zones are signed, it’s very localized by TLD. So for example, if you look at the percentage of subdomains of .com that are signed, it’s a vanishingly small percentage. It’s a tiny fraction of 1%. If, on the other hand, you were to look at .se, which is Sweden’s top-level domain, or .bg, which is Bulgaria’s—there’s a solid double-digit percentage of sub-zones that are signed because they’ve had active campaigns to make sure that folks sign their sub-zones and in some cases they probably have some sort of regulations that may require it for companies in certain businesses or what have you. So the adoption is super uneven. It really just depends on where it is in the world you look and a lot of European governments have done a much better job of deploying DNSSEC than the rest of the world.
David Redekop: That makes sense. I hadn’t really thought about the segmentation of TLDs and the concentration of it and I suppose with .com being the early TLD, so many of the early registrations were simply about protecting someone’s wordmark or someone’s trademark with no intent of actually doing anything with it in most cases. And eventually fall off and there’s a broker that picks up the ones that are expiring and then they’re up for auction. It makes sense that none of those would have any motivations to have them signed. That makes sense.
Cricket Liu: But there’s also the other half of it—is to look at the big recursive DNS servers out on the internet or the big recursive DNS services like Google Public DNS and Cloudflare is 1.1.1.1 and 1.0.0.1. And to see what percentage of zones they validate. Basically what percentage are signed and validate correctly. And if I remember correctly, the percentage is relatively high because of course, if you’re just looking at .com—you consider .com as just a flat, I don’t know how many delegations it has—a hundred million, 300 million delegation namespace? Out of those, it’s a tiny fraction of 1% that are actually signed. But on the other hand, if you’re taking the point of view of the recursive DNS server, you’re looking at what gets looked up most frequently. So the very popular, very important parts of .com—google.com, facebook.com, those sorts of things, Infoblox.com—all of those things we hope are signed because they’re really important and we really wanna make sure that we get to the right destination. So, if I remember correctly—and I haven’t looked at the statistics in a while—but the percentage of queries that result in validation to say Google Public DNS or Cloudflare is still pretty high. It’s still double digits, I think.
David Redekop: Okay. That actually is really helpful for context for everybody that is wondering about why the adoption is so slow. And, a lot of the times I find myself needing to remind myself that DNSSEC really does have a very separate and distinct purpose of providing authenticity and validation that the data is truly from the source. It can be verified, but it also does not have any encryption. And so really in the end, we’re gonna end up with DNSSEC signed and encryption as two separate pieces to continue to secure the protocol.
Cricket Liu: That’s right. They’re really orthogonal to each other.
David Redekop: Yeah. Yes, that’s right. That’s a good word. So looking back at the evolution of the DNS protocol as a whole, is there one foundational thing about DNS that you wish you could go back and change to make it inherently more secure for the Zero Trust era that we’re moving towards?
Cricket Liu: I lived through the many different generations of DNSSEC, and I do recall the first version of DNSSEC, if you will, was pretty difficult. And the first implementations of it were—oh my gosh—a tremendous headache to try to administer. I think it was the fourth edition of DNS and BIND where I first had a chapter on DNSSEC. And I think that the process for signing a zone for the first time was a 12-step process that covered 25 pages of text or something like that. And I thought after writing it, “I’ve wasted my time because no one in their right mind is actually gonna do this.” But we’ve come so far. At this point, BIND, for example, has very good automation of signing and resigning. I’m sure there’s lots of other open-source software that does—we invested in this at Infoblox early on to try to make it as automated as possible. Like: select the zone you want to sign, click “sign zone”, click “yes” (because it has to be some sort of a confirmation), and then it just does it. But, if I were redoing things, yeah, I might have started with something like DNSSEC capabilities built into DNS from the very, very beginning. That certainly would’ve helped. And there are other things about sort of extensibility. I mean, we’re—I think we’re constantly running out of bits in the header. And, of course, there are limitations like the original use of ASCII for labels. And, I think, we never particularly thought that 256-character limit on a domain name was gonna be a big deal. But hey, you know, that’s probably someday gonna be a big deal too.
David Redekop: Yeah, you make me smile when you talk about all of these limitations, but when I reflect upon what it took just to have the TCP/IP stack design in principle—to have the DNS namespace design in principle to be this flexible—I am still in awe, Cricket, that this all still works. That we find a way to keep on adapting and make it work, you know? And, so, the way people use TXT records in a super creative way for all kinds of things—it’s gotten so crazy that it’s now become a danger to allow TXT records to be resolved in networks that you wanna protect. But by the same token, there are some really good legitimate use cases like the way we automate ACME and Let’s Encrypt certificates and all of these things connect to one another—it’s become a really complicated web that we’ve created for ourselves.
Cricket Liu: Yeah, yeah. It’s really a tremendous testament to the design that Paul Mockapetris came up with DNS in the early days that it still is—I mean, obviously we’ve—there have been improvements around the edges. There’s DNSSEC, there is encrypted DNS, there are lots of resource record types, there’s EDNS, stuff like that. But it is recognizable. It is absolutely recognizable today, 40 years later. It is recognizably what Paul came up with. So that’s tremendous. He should—I think he has been—he has gotten his share of accolades. I don’t wanna take anything away from him, but we should recognize the amazing design work that he and others did early on.
David Redekop: Absolutely. I had him on a previous episode, where I specifically had questions for him about—I wanted to know how he had prepared his mind for that kind of thinking and what some of the things that he was told to do differently that he resisted. And it really is a fascinating episode to go back on. Anybody interested in that earlier version or in earlier episode of that, where he describes that. So yes, I agree. Hats off to him for sure.
Cricket Liu: I’ll give it a listen.
David Redekop: Yeah, no, for sure. I think you’ll enjoy that. But, Cricket, you and I are both dads and earlier off-camera we were talking about our children in the next generation. And how we can encourage them to pick up the baton in this space because we’re not gonna be around forever. Okay. Alright. You expect longevity? That’s good…
Cricket Liu: No, I don’t know. I don’t know about that. On the other hand, maybe that’s a good reason for you and I to never retire.
David Redekop: Yeah, your wife might like that. You know, some spouses like the idea of their husbands never retiring.
Cricket Liu: Yeah. I think mine is encouraging me to retire.
David Redekop: Okay. Well, that’s a good sign. That means that the spark is alive and all is well. That’s fantastic. But, seriously, from a legacy point of view, what—is there one piece of advice that you would have for the next generation that might be interested in this space? Like what are some inspirational words? Think of yourself speaking to our sons. My wife and I have five of them—about how this is an exciting space that’s going to keep them cognitively challenged for the rest of their lives?
Cricket Liu: One of the things that I find so remarkable about this is that almost everything that I’ve learned about DNS, about the internet, is freely available out there on the internet. There’s no sort of secret sauce. You don’t have to go to med school or law school in order to learn about it. It’s all there. It’s available to you in RFCs. Nowadays, of course, there’s tons of video content—some of it like this—that you can use to learn about it. And the reason that I got into this in the first place was because I had started working at HP back in the late 1980s and had a job working for a department of wonderful people whose job I just did not—I had no interest in. They were writing a strategy basically for the organization on it—like, which word processor should we use and which spreadsheet should we use, and things like that. And here I was able to pivot from that just by learning stuff on the internet. And I should say, notably, taking a class directly from Paul Mockapetris back in the day. And other folks could do this too. It’s just a matter of having the interest because all of the resources are out there. There’s so much to learn and if you want to sort of help build a better internet and fight the good fight against the bad guys out there, there’s just a tremendous amount you can learn just by using your computer, using your web browser.
David Redekop: Yeah, no, I agree with that. It’s an interesting time, where there literally is no obstacle between where you are today—knowledge and capability-wise—to where you want to be. Okay. So, let me challenge you on just a little bit though, and say: in what way does the human make a difference in the world where AI already has all of that capability?
Cricket Liu: Well, I mean, I think when we’re talking about AI, we’re probably mostly talking about generative AI, right? And GenAI is mining the internet for the most part, right? It’s generating stuff based on the assembled knowledge of the internet. It has more trouble coming up with brand new stuff. And, I think, clever folks will always have a place coming up with new advances, new protocols, new applications of existing protocols and existing technologies. Some of that now may be guided by generative AI, but that’s fantastic. That’s just another tool to have in your tool chest.
David Redekop: Right. So having the curiosity and the hunger for newer, better ways—there’s still going to remain the element of scarcity in the world of abundant AI.
Cricket Liu: Yeah. That rings true for me. I think so. You know, AI isn’t going to spontaneously go out there and come up with the next great business idea and execute it. It’s not going to come up with the next great mechanism for dealing with the sorts of attacks that we see day in and day out. But a person who’s using AI as a tool could certainly do that.
David Redekop: Cricket, will I see you at a future conference soon? IETF, DNS-OARC or any of those?
Cricket Liu: Yeah, I mean certainly, one or the other. A lot of enthusiastic Infoblox folks have been attending DNS-OARC in particular, lately. I know you’ve met some of them—my colleague Ross Gibson, you probably met Josh Kuo as well. Really, really good guys. I don’t know if you’ve met Jim Mosley. So, one of these days, I’ll get back into the swing of things and go to another DNS-OARC meeting and maybe even IETF. Who knows? It’s just that so often the dates for OARC or the fact that they tend to be in kind of far-flung locations don’t jive well with my calendar of corporate responsibilities.
David Redekop: Yeah. The next one’s in Edinburgh and that’s a time zone adjustment that’s gonna cause some jet lag. And, at my age, it’s not quite as easy as it used to be to do a six-eight-nine hour adjustment, so I need to give myself a few extra days. But, the next IETF is in Vancouver, so that’ll be easy for you…
Cricket Liu: Right. So maybe I’ll see you at that one.
David Redekop: Yeah. Beautiful city.
Cricket Liu: Yeah.
David Redekop: Alright, well, it’s been a real fun session for me to have you here and I do look forward to meeting you in person real soon. And until then, take care.
Cricket Liu: Yeah, likewise David. Thanks for having me on. Bye for now.
Narrator: The Defender’s Log requires more than a conversation. It takes action, research, and collective wisdom. If today’s episode resonated with you, we’d love to hear your insights—join the conversation and help us shape the future together. We’ll be back with more stories, strategies, and real-world solutions that are making a difference for everyone. In the meantime, be sure to subscribe, rate, write a review, and share it with someone you think would benefit from it too. Thanks for listening, and we’ll see you on the next episode.