84. DNS Must Be Secured Presented by Infoblox – Tech Field Day Podcast Spotlight

You may not think about DNS until it breaks, but I know who's thinking about DNS, the people that want to steal your data, because attacks on DNS or utilizing DNS are becoming much more prevalent. If only there was a way to secure DNS. Wait.

There is, in this episode of the Tech Field Day podcast, brought to you by Infoblox. We're gonna talk about DNS security and how DNS must be secured. Welcome to the Tech Field Day podcast, where we bring together a group of IT technical experts to discuss single idea about key concepts in the IT industry.

This podcast features a variety of perspectives from members of the Tech Field Day delegate community, and is often associated with one of our tech field day events. Tech Field Day is a part of the Futurum Group, and this podcast is also published on our sister company Site Techstrong tv. In this security Field Day episode, which is brought to you by Infoblox, we're gonna be discussing DNS security.

But before we get to that, I'd like to take a moment for our panelists to introduce themselves so you know who's talking, starting with Jack. Hi, I'm Jack Pauler, principal analyst with Paradigm Technica. We focus on security and, uh, ai.

My name's Cricket Lou, and I am Infoblox's Chief evangelist. And, uh, one of the longest tenured employees. I think I'm going on 23 years there.

Outstanding. And I, of course, am Tom Hollingsworth event lead at Tech Field Day, which is a part of the future improve. Let's jump into the premise for today's episode.

DNS is one of the things that most people don't think about until it goes down. However, there's something else that you really need to be considering, and that's the fact that DNS, by and large, over its history has operated more or less in clear text, and that has given rise to a lot of opportunities for hackers and Du Wells to do things that well aren't really above board. And there has been a push in the industry to help secure DNS.

I think that we finally reached the point, though, where DNS needs to be secured. Now, cricket, you have spent a significant amount of time in your career talking about DNS and DNS security as of late. I, maybe you could give us a little bit of background.

What is it about DNS that has been so inherently insecure for so long? Well, almost all communications in DNS, whether that's between, uh, AUB Resolver, which is a DNS client, the code that's on your, uh, laptop or your smartphone, or any other device that speaks DNS and the recursive DNS server that it communicates with. All of that's in the clear.

Likewise, the communication between the recursive DNS server and the authoritative DNS servers that it queries, that's also it in the clear. Um, and that means that that communication is subject to snooping and spoofing. Both, um, anybody who happens to be on the path between you and your recursive DNS server can see all of the queries that you send.

Um, and in some places on the internet, for example, between, behind the Great Firewall of China spoofing is, is a regular occurrence. So the way that the Chinese government keeps you away from western social media sites is to spoof responses to DNS queries for those sites, domain names. So, uh, this has been kind of a last mile problem in the world of DNS for literally decades, and it's really only been about in the last 10 years or so that the internet engineering task force and the DNS community as a whole have taken it on and have said, look, we really have to do something about this.

Yeah, I know for a fact that this is something that has come up in, in the last few years, not from a, from a threat actor perspective, but from maybe a less than savory aspect of, uh, there are parties that can snoop on your DNS requests to say, your ISPs, uh, DNS servers, and maybe they could buy that information to sell targeted ads because they kind of know some of the places that you're going. And of course, you know, from a technical perspective, I kind of understand how that works. But then when I get phone calls from my friends going, Hey, is my provider snooping on my DNS because this ad on TikTok says that I need to install this program to stop that, you know, first I'm like, well, there's a little bit of truth to that, but there's also a little bit of grift to that trying to get you to, to use this program that may or may not actually fix the problem.

Yeah, that's right. Um, I, I mean, if you're, for example, using your service providers recursive DNS server, then regardless of whether you use some encrypted DNS solution, they're still gonna be able to, to mine your data because they are the other end point, right? They're on the other side of that encrypted, uh, connection, and they can, they can decrypt it.

I think a lot of the, a lot of the, the raison detra of these encrypted DNS protocols is, um, the, the concern that, you know, if you decide you're going to use, say, Google Public DNS, uh, if you're going to use, um, uh, quad Nine or CloudFlare or Infoblox or whatever, then uh, you probably don't want your ISP or the government, uh, under whose watch you, uh, you live to be able to, to decrypt your, your information. Jack, as someone who has kind of implemented some of these solutions over the years and, and really been heavily involved in, in security, uh, in general, has DNS been something that's popped up on your radar? Or is it just kind of considered like a utility function that well, you know, forget about it.

We're we, we got more important things to worry about? It's popped up on the radar, but not, um, from the security context, I think, you know, I think we're all familiar with the meme of when there's a network problem. It's always DNS and that's really rooted in the truth.

And I think now, you know, part of the issue is the malicious actor who can come in and in an unencrypted channel can, uh, basically change the DNS information you're receiving without you being able to validate it and verify it. And that really leads to, uh, proliferation of, uh, man in the middle attacks really, where somebody can come in and you want to go to PayPal, so to go pay somebody and they intercept it and redirect you to a site that looks exactly like PayPal, but it's not PayPal's servers, it's not their IP address. You're being fed, you're being fed another server that's acting as man in the middle.

And that's where it gets really scary because it is very invisible and very hard to detect without DNS security that you're getting corrupted information. Yeah, I would absolutely agree. And, and that's one of the things that we teach people, right, is if you are getting some kind of a spam scam, phishing type thing, look at what URL that that button's trying to send you to.

In fact, I, I saw that today. I got a spam message that said, oh, you have a new voicemail, but when you hover over the links, they are garbage links. So if, if someone was able to do something like inject a, uh, a malformed link into a legitimate DNS request for something, then, you know, that could be a huge issue.

Uh, CR what is d what, how does DNS SEC prevent that from happening? Is it just encrypting the DNS request, or is there more to it? Well, first we have to be clear about what we're, what we're talking about, right?

So there's encrypted DNS, which encrypts the channel, right? That's, that's basically using something like TLS, which should be familiar to, to most of your listeners, I'm sure. TLS is the, the encryption protocol that underlies h TT P and HTPS, right?

So, uh, one way to secure the communication between your stub resolvers and your recursive DNS servers is to use TLS. Just running DNS over TCP over TLS pretty simple. And that basically guards against somebody, uh, sniffing that communication spoofing responses, which is what Jack was talking about.

Um, separately from that, there's DNS sec, DNS SEC is the DNS security extensions, and these are cryptographic extensions to DNS that basically allow, uh, people who administer zones in DNS zones are just administrative containers, but it allows those people to digitally sign those zones and then validating recursive DNS servers, uh, can basically validate the authenticity of that data so they can prove importantly two things about data, um, that's been signed using DNS sec. Um, one of them is that it's, uh, actually, actually comes from the right source. com zone, and also proving that it hasn't been modified since it was signed.

So, um, that's super, super important, right? com or what have you, right? com can validate that data, but you still have that last mile.

You still have, um, the communication between the stub resolver and the recursive DNS server. And if that's not secured, if it's not, uh, secured using encrypted DNS, then somebody potentially on that, on that link, somebody who can intercept that traffic and, uh, spoof traffic on that link can just send back bogus data, recursive, uh, uh, DNSX validation or not. And I know that this is a problem that we faced in networking from some other things like BGP, where, uh, a malformed, uh, actor can, uh, inject BGP route information into the global table and hijack information for, uh, a period of time.

And I, I know that, you know, DNS and BGP are not too dissimilar from that perspective where, oh, well, if I just assume that I'm announcing this, the only thing that's saving me right now is the time to live on that. Uh, you know, the DNS, um, packet, basically, if, if you're forcing those things to expire too quickly, then it would just be a matter of me jumping in the middle and saying, no, no, no, no, I really, I'm, I'm the only one you need to go to here and pay no attention to the fact that those IP addresses are completely different. Now, um, is this something that is gonna require the, uh, cooperation of a large portion of the internet?

Because the first thing that I think of when this starts happening is, oh, uh, we have to create a standard for this. Huh? I wonder who's gonna want to be the one who dictates that standard to everybody, because then they get to control who is allowed to use it and how much is gonna be paid for it, and those kinds of things.

Yeah, I mean, it definitely does require some, some earth moving. So, uh, for example, DN sac, which we've been working on since the 1990s, um, DN SAC is a very mature standard, um, but it hasn't been really widely adopted. The, uh, the number of zones that are signed, the proportion of zones that are signed varies quite a bit depending on what top level domain that you're talking about.

And under calm, which of course is familiar to most of us. The, the percentage that's signed is, is unfortunately very, very small. Um, and that's, it's not changing particularly rapidly at this point, given that the protocol is, uh, more than 20 years old.

Um, the encrypted DNS protocols are gonna require, uh, in many cases that folks upgrade their DNS infrastructure, their DNS servers, and in particular recursive DNS servers to support these new protocols. Um, if you've been keeping up, if you run, for example, bind, which is probably still the most popular open source DNS server implementation, then if you're keeping up and, and updating it, then it's just a matter of configuring it because it already supports DOT and dough, which are DNS over TLS and DNS over HT dps. Um, on the client side though, you also have to be upgrading operating systems and devices to support these, these protocols too.

The latest versions of Windows support, um, dough, the latest versions of, uh, MAC os, iOS support dough and DOT two, I believe, and then various browsers too. So Firefox, Chrome, any chromium based browser, they'll all support DI think, uh, one of the motivations that'll really sort of flip the switch is when the browser do the same thing they did with HH TT PS, where they made HTPS the default and mandatory, and basically said, you know, if you go to an a, a non-encrypted site, throw up the big red box, the carry letters and saying, don't go here. And if the browsers start the browsers, really, if they start doing that for, uh, DN sec, then we'll see a much wider scale adoption, much more rapid adoption.

Yeah, I mean, certainly if the browsers were to give you some sort of a vi a visual indication, uh, that you had used, um, dot or, or some encrypted DNS protocol in order to resolve something, um, or a policy switch that allowed you to say, I only want to use encrypted DNS protocols. I don't want to use plain old, uh, DNS over UDP or TCP port 53. So I guess the next question though, because I remember when, uh, HT DPS, uh, default came online, uh, I was still doing my day job of, of sorting that mess out, and there was some pushback from people who were like, but, but this is gonna break a lot of our monitoring infrastructure.

Uh, I specifically remember, uh, web proxy filtering was a huge problem that I ended up having to do some DNS trickery to get around. Are, are there people in the industry who are pushing back against secure and or encrypted DNS because it kind of invalidates some of their product lines or possibly, um, something else, like you mentioned earlier, you know, rewriting DNS queries to lock, uh, people out from, uh, going to specific websites as a matter of national policy. Yeah, I mean, certainly there are products that rely on being able to sniff DNS traffic, right?

There are probably, uh, any number of products that, that, um, try to keep you from going somewhere there, intrusion detection and intrusion prevention systems that, that rely on that. And if you move wholesale to encrypted DNS protocols, then you're not gonna be able to run those anymore. It's just the DNS client and the DNS server who have access to that stream of data.

So I would imagine if, if you were working for one of those companies, you'd be log lobbying pretty hard against, um, the, the widespread adoption of, of encrypted DNS protocols. 3 and throws a warning when that happens. And suddenly, a whole lot of people were very angry that you found out that they were doing DNS and, and HTT BS rewrites.

And it's like, wait a minute, you've been inspecting my traffic this whole time. So I think that that can be one of those hidden benefits maybe, is that you suddenly realize there's a lot more going on under the hood than you really thought about. So I guess the next part of this question is kind of around the standards aspect of it, because we kind of alluded to the fact that, you know, uh, the easiest way to create a new standard is to try to get everybody to agree on the old one, and then we end up with a new standard, which is, you know, usually everybody agreeing except for one company.

But I know for a fact that there is, there has been a movement to have DNS SEC and, and some of these things, uh, codified with everybody's favorite government organization, the National Institute of Standards and Technology, or nist uh, cricket. Maybe you could tell us a little bit about how this is being set up and NIST for us to be able to kind of have a reference architecture to look at. Yeah, yeah.

That's, that's something that's, that's going on right now. Basically as we speak. Um, NIST has a document that's called Special publication 800 dash 81, and the first version of 800 dash 81 came, came out back in I think, 2006.

It is a, a venerable document, much appreciated by DNS administrators, and basically it's recommendations on how to secure DNS infrastructure, how to, how to run, uh, secure data, how to, how to secure your DNS servers, this sort of thing. Um, but one of the things that, that, um, my friend Ross Gibson and I recognized, uh, about a year ago, I guess it was, was that it hadn't been updated since 2013. And as such, it didn't really contain any recommendations about protective DNS or about encrypted DNS because both of those sort of emerged since that last version of 800 dash 81 had been published.

So, um, I contacted Scott Rose, who was one of the original authors of the document, um, he's aist and I said, Hey, Scott, are you, you interested in an update to this? It seems like these are are important subjects to cover in a document that is, uh, at least nominally a secure DNS configuration guide. And he said, absolutely.

Um, but he was working on other things. And so Ross and I put our hands up and said, we'd be happy to contribute some material about protective DNS and encrypted DNS if you're interested. And he said, I would be.

And, uh, so we, we wrote a lot of material, and Scott jumped in and wrote material as well, and we came out with what is now called 800 dash 81 R three. So it was published in draft form in May, I think towards the end of May of this year. It was in a comment period for about, uh, a little over a month, I think maybe, maybe close to two months.

Um, now unfortunately, with the US Federal government kind of shut down, it's stalled, but it's our belief anyway, that the final document will be published, uh, imminently, uh, after everybody goes back to work. So the nice thing is that this version of the document says, look, protective, DNS is super, super important. Everybody out there, US federal government, commercial organizations, nonprofits, whatever, you should be looking at this as a way to protect your network, right?

You shouldn't just allow folks to resolve any old domain name, even domain names that we might know or malicious know are being used by various species of malware to rendezvous with command and control infrastructure. And likewise, encrypted DNS is important because if you don't implicitly trust the network over which you're running, if you're worried about spoofing, if you're worried about, um, sniffing, then encrypted DNS protocols are your friend and can, can help you avoid those types of attacks. Jack, I was wondering if maybe you could kind of give us the practitioner perspective.

How important are these NIST standards when you are trying to, uh, convince a company to deploy a, uh, architecture like DNS SEC or encrypted DNS can, is being able to point to NIST's framework and say, you really should be using this a whole lot easier than going, well, I guess it's something you should consider. It absolutely is. I think it's very important, uh, both just because it's a standard, but also because the federal government tends to take those standards as commandments.

And a lot of security organizations really do sort of let the federal government take the lead and say, if they're doing it and they're doing it on a schedule, that probably means we should do it and do it on the same or schedule or very close, right? That this is not a 10 year transition, right. This is a, you know, a very short, and maybe cricket can talk a little bit more about transition times, but I think, uh, you know, in the enterprises, uh, you know, a lot of enterprises play follow the leader and typically the, the military and the federal government is really the leader here.

And, you know, it's, it becomes an impetus to put it on your list of things to do rather than I'll get to it at some point. Yeah. I, I know for a fact that when something comes up and I need to figure out if it needs to be deployed, the first thing I do is go look at nist.

Like, we, we've seen this recently with post quantum encryption. Um, do we need to switch out our cryptography? Well, for the longest time we didn't have an option because there was no real standard.

And thankfully, uh, NIST put everything through the ringer several times. In fact, uh, you know, uh, before they were called, uh, di lithium and, and some other cool stuff, of course, now they're government, so they have, uh, a boring name. But, um, one of the candidate keys actually fell out because, uh, thanks to the efforts of NIST putting its through its paces, it, they found that there was actually a shortcut in there with the lattice, uh, framework that it was using.

And it's like, well, uh, if we didn't have the, uh, the rigorousness of, of the testing process, perhaps, uh, we could have done something that would've, we would've ended up regretting. So I, I love the fact that NIST is willing to do this, and, and like cricket said, you know, if the draft is there and it's been commented on, and everybody seems to be happy with it, it's just a matter of flicking the switch whenever it goes live, whenever that happens to be. Yeah, it was going through some, uh, an internal review at nist, which I, I gathered was mostly editorial, um, when the shutdown happens.

So my hope is that, uh, that things reopen and, and, uh, they finish up that internal review and get it published. Yeah, I think when, when, when it comes out, and this is one of those things where it will make a splash within a very specific community, of course, not the broad audience, but that's the community, the community that cares about it. We'll absolutely look at this and say, okay, now it's, you know, as, as, as Cricket said, you know, DNS SEC has been around for, um, you know, what, since the mid 1990s, right?

So it's, you know, and, and I know personally on my systems, I haven't gone to DNS SEC because it's not easy to configure in the current environment, and it's not required. And, you know, I'm a small shop and, you know, what's the benefit to me really, but a larger organization that has the resources and now the impetus to do it, I think will start moving fairly rapidly towards DNS SEC for all of their environments. Yeah, it might be worth, uh, saying that even though 800 dash 81 is really a set of recommendations and not regulations, there are other regulations that point to nist.

So for example, the European NIST two, I know it sounds similar, but NIS two, um, uh, regulations, they point directly at nist, and in fact they point it at 800 dash 81, I believe, cricket. One of the things that came up during Security Field day, uh, where Infoblox was a presenter, was the fact that things like secure DNS and encrypted DNS can be used as a way to kind of, uh, harden your infrastructure against threat actors. And I know that at Infoblox has had a long history of working on DNS and and, and things like that.

What, what are some of the takeaways for you of being able to deploy, uh, encrypted and secure DNS, uh, as a way to kind of combat some of the threats that you've seen popping up in the industry? Because one of the things that I know is that when the attackers, when you shut down one avenue, they're gonna get really creative to sneak in another one, because that's kind of their livelihood now. Yeah, yeah.

Well, we've, we've talked in, in this podcast mostly really about encrypted dns, but protective dns, I would argue is, is perhaps even more important. And protective DNS is, is a pretty simple idea. It's just, um, outfitting your DNS infrastructure with the intelligence to tell the difference between queries for domain names that are innocuous and those that are suspicious, and those that are downright malicious and that to do something different when, when they respond to, uh, those queries for malicious and suspicious domain names to, um, answer with a lie, a little white lie that says that domain name does not exist, or, and, and of course to log the fact that a particular client looked up a known malicious domain name, so that after the fact you can say, oh, look, this client looked up the domain name that I happen to know is the command and control infrastructure for the species of malware pretty likely that that client is then infected with that malware and somebody needs to go clean it up.

So I, I think that that is, is hugely important. And, um, infobox has, has invested a lot of time and energy in that. We have, uh, infobox threat intelligence, a whole team of researchers who, um, scour this, uh, gigantic corpus, this gigantic body of what we call passive DNS data to find patterns that indicate malicious use of, of, uh, domain names, to put those into threat feeds and make those available to our customers so that they have an up to the second list of all of, for example, the domain names that are currently being used in, uh, malware, um, that are, are being used in a phishing attacks or what have you.

So I think that's a, a fantastically, um, useful mechanism. I think, Tom, this is one of those sort of hidden, uh, sort of silver bullets in security that we don't really think about when we think about network security. We very often think about inbound protecting ourselves from inbound attacks and firewalls, or I intrusion detection, as you mentioned earlier.

And this is a way to look at outbound traffic and discover something that's potentially bad, or that in that presage is a bad thing happening, right? So if you can see a, an infected device reach out to command and control server, and you can prevent it from ever reaching that command and control server because it can't do the DNS lookup, then you are preventing a whole host of other problems, lateral movements and, and exfiltration of data, and you can stop it very, very early in the attack chain. But we don't normally think about DNS as being part of that network security sort of stack of stuff that we do in network security.

So I think, you know, this is really cool when, when Infoblox was telling us about that at Tech Field Day, I thought that was great. I I would say that we've always heard, you know, they don't build them like they used to, but I would argue that especially with internet protocols, we shouldn't build them like we used to because we've learned over the years that there are ways to exploit things and take advantage of stuff that we didn't really think about in the eighties and the nineties. And thanks to the efforts of people at Cricket and Infoblox and all the other people who have put in all this work on the standards and these recommendations, um, hopefully we can eventually transition to a place that's a little bit more safe.

I know for a fact that when I teach people about browsing the web, we no longer really have to focus on, well, you gotta check to make sure you have to pla the padlock or that the URL bar is green, because that's just assumed to happen now. And it's gotten to the point where if something pops up as a non-secured site, our browsers are like, wait a minute, something doesn't feel right here. Who knows?

Maybe in the future we'll get to the point where DNS is secured and encrypted by default, and some of these attack vectors will just go away. Uh, before we close out here, uh, because this episode has been brought to you by Infoblox as part of their security field day presentation Cricket, I was wondering if you could let the people out there know if there's anything that they would like to learn about how Infoblox is helping to implement these standards. Where can they go to learn that?

Well, I'd suggest they go to our website. We do have a whole series of blogs. Some of them, uh, I've written some of them, uh, my colleague Krupa and other colleagues have written that are about, uh, encrypted DNS protective DNS, and specifically about NIST SP 800 dash 81.

And then of course, I'd, I'd also suggest that folks take a look at the new version of 800 dash 81, which despite the federal government shutdown is available out there for anybody to download, just, uh, Google NIST SP 800 dash 81 R three, and you'll find it, and hopefully that'll be useful for folks. Thank you all very much for listening to this episode of the Tech Field Day podcast. If you enjoyed this discussion, please make sure that you're subscribed on YouTube or your favorite podcast application.

We don't want you to miss any of the episodes. Another thing we'd love to ask is if you could give us a rating and a review, because that really helps people find who we are and what we're all about here. This podcast was brought to you by Infoblox and Tech Field Day, which is the home for IT experts from across the enterprise, a part of the group.

For more great episode and upcoming events, head Over Tech podcast us out on tech. Thank very much for listening, and we'll see you next week.