TDL 015 | Inside the DNS Battlefield: Malware, Tunnels & the Future of Network Defense

The ADAM Blog
, , ,
1

From LAN Parties to Network Defense: The Hidden World of DNS Security

In this episode of The Defender’s Log, host David Redekop talks with Johannes Weber. Weber’s career began with a spark of play at the age of 13, fixing connections at LAN parties for Age of Empires II. Today, that passion for networking has evolved into defending against one of the most persistent threats in the “cyber kill chain”: DNS-based attacks.

The Creative Attacker: Flying Under the Radar

Studies show that 90% of malware uses DNS at some point, often for Command & Control (C2) or data theft. Attackers favor DNS because it is rarely blocked by traditional firewalls.

In DNS Exfiltration, an attacker cuts a file into small, encoded chunks and queries them as subdomains (e.g., part1-data.attack.biz). The internal resolver, acting as an unwitting accomplice, forwards these queries to the attacker’s server. DNS Tunneling takes this further, establishing a full two-way communication channel—like an IPsec tunnel—disguised as standard DNS traffic.

Hardening the Perimeter

Defending this “niche” but vital market requires a multi-layered approach:

  • Recursive Resolvers: These are the best place to spot threats because they see the original client IP.
  • DNSSEC: This provides authentication and integrity, preventing “cache poisoning” and man-in-the-middle spoofing.
  • DoH (DNS over HTTPS): While it protects privacy in public Wi-Fi, enterprises must manage it carefully to ensure security tools aren’t bypassed.

Whether you are a “road warrior” or managing an air-gapped network, the goal remains the same: ensuring the network’s phonebook doesn’t become a map for the enemy.

Full episode of The Defender’s Log here:

TL;DR

The “Why” Behind DNS Security

  • Malware Link: ~90% of malware uses DNS for its “kill chain” (C2 commands or downloads).

  • The “5/95” Rule: Achieving 95% security is easy; the final 5%—plugging niche leaks like DNS—is the hardest.

  • Career Path: You don’t need to be a coder. Deep networking knowledge (like fixing LAN parties) is just as valuable.

    Top 3 DNS Threats

  1. Exfiltration: Breaking stolen data into chunks and “hiding” it in subdomain queries to an attacker’s site.

  2. Tunneling: Creating a full, two-way data “pipe” through DNS to bypass firewalls.

  3. DGA (Domain Generation): Malware auto-generating thousands of random domains to stay ahead of blocklists.

    Actionable Tools

  • Pi-hole: Free “nerd-approved” DNS sinkhole for home networks.
  • DNSviz: Visualizes DNS security chains to find broken links.
  • Ultimate Pcap: A free download from Johannes’s blog to practice Wireshark skills.

Links

Links discussed in podcast

Links to The Defender’s Log podcast

View it on YouTube: https://www.youtube.com/watch?v=-u0Od3DIpjs

Listen to the episode on your favourite podcast platform:

Apple
https://podcasts.apple.com/us/podcast/inside-the-dns-battlefield-malware-tunnels-the/id1829031081?i=1000748516444

Spotify
https://open.spotify.com/episode/4B5t1abwlBBo3Tz5M7tGk7

Amazon Music
https://music.amazon.ca/podcasts/d7aa9a19-d092-42a6-9fe9-9e8d81f68d30/episodes/63eee895-55ad-4b5e-90a4-99e67bc6321d/the-defender’s-log-podcast-inside-the-dns-battlefield-malware-tunnels-the-future-of-network-defense

ADAMnetworks
https://adamnet.works

The Defender’s Log Full Transcript -Episode 015

Tell us about malware and DNS. When it comes to malware and DNS, there are some studies out there that say that 90% of all malware uses DNS somewhere in the cyber kill chain. The two main protocols that represent an opportunity for UDP amplification attacks are of course NTP and DNS. So with DoH (DNS over HTTPS), you will have an encrypted channel between the client and the resolver. Doing it that way, an attacker can neither DNS spoof the packets nor can he eavesdrop. He will only see random data because it’s basically encrypted. Let’s talk a little bit about some usage of DNS that is applied on the creative side by the attacker still.

Yes, there are some ways. The well-known stuff is like DNS exfiltration or DNS tunneling.

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 Defenders 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.

Main Conversation

David Redekop: Well, welcome to another episode of the Defenders Log, and I have with me today, Johannes Weber. I hope I pronounced it with the proper German accent. Did I?

Johannes Weber: Yes, it was quite good because I think in America it’s pronounced like Weber with double B, but in Germany it’s like Va. So it was quite good. I know you’re speaking some German, don’t you?

David Redekop: Yeah, but that would not be so fun because the subtitling might get a little confusing, but you know, my dad’s name was Johan. And when we moved to Canada, he changed it to John because who’s going to say Johan? But eventually he went back to his actual birth certificate name of Johan. So then ever since then it’s been okay if someone calls him Johan you know he’s of a German background and if he’s Johan then he’s not. And so you know all of us have multiple identities when we deal with multiple cultures. And then I when we first came to Canada we moved to Kitchener Ontario which used to be called Berlin back in the day. And because of its high density of German immigrants um is my understanding is how it got that name to begin with. And we also had a street named VBA. Now what’s interesting in the rest of Canada it’s called Weber but in Kitchener is called Weber because again of the German heritage. So there’s a lot of Johan Johannes Va in in my background. So it’s for me it’s very cool to connect with someone with those two very German names. So anyway, welcome to the Defenders Log. Good to have you.

Johannes Weber: Yeah, thanks for having me talking about some network security related stuff which I really love.

David Redekop: Yeah, that’s very clear. And I first connected with you many years ago on your blog about NTP hijacking because of the two main protocols that represent an opportunity for UDP amplification attacks are of course NTP and DNS. And anyway that was the first time I interacted with you and then since then online and then now in video. So um I’m glad to have you. But what I did not ever gather from you um was the origin story. How did you ever get into this space that’s kind of niche even though we you and I live in this and so you you interact with people in you know the network security space but as far as a globe is concerned it’s really not a mass market right so it’s kind of a niche market. So how did you ever get started in something this niche?

Johannes Weber: Yeah. So I am always was interested in the network parts. So back then when I was at the age of 13 or so, we had something called LAN parties, local area network parties. And I was always the guy who was able to fix the network and we played some games like Age of Empires 2 for example where we had these SPX protocol and the TCP protocol and I was the one working with the network. So this is why I studied something related to network and something related to IT in general. And then it turned out that there was a study in German which was for IT security about networks. And this was quite a fun for me because it was the network and the security and this is what I love to do to yeah well to to architect like big networks and to understand big networks and also related to security because I’m working nowadays I’m working as a consultant for a German business-to-business system integrator called SVA Team Fat Alexander Gamea and I’m in a department working solely on network security consultant projects. So I’m mostly working with Palo Alto network firewalls but also with Infoblox for example when it comes to DNS. So this is what I love and the fun story about this is when I was during my study years I was not able to code. I’m not a programmer. I’m not a developer at all. And I always was afraid of getting a job because I cannot code at all. And I’m quite happy though that I found a job being a consultant for this network security stuff um in which I don’t have to code at all. So this is this is the good part of the story.

David Redekop: I love it. I absolutely love it. We have so many parallels and it’s interesting how many people get into this space that starts off with some kind of fun and engaging trigger right for you it was the LAN parties where you understood your natural skill set came in so handy and for me it was when I found out that the game of Monopoly on the Commodore 64 I read a short story in a magazine about how the developer of that game literally feels like the first five hours he built 95% of the game and the last 95 hours he built the last 5% of the game right which is so common when you write a proof of concept and then you’re going to mature something it takes a long long time but it’s like that with network security you can get 95% of the way there with 5% of the effort but it’s the last tweaking of everything else to get rid of the paracity problem that takes so much effort. So now this is really cool. You’ve done a number of presentations. You were at Sharkfest last year and I went through your presentation. I thought it was very well done and I thought maybe we could touch on some of those topics today and maybe we can start with the malware and DNS altogether because that is an area that you have a lot of experience in. Tell us about malware and DNS.

Malware and DNS Fundamentals

Johannes Weber: Yeah, let’s just one step before let’s just talk about the DNS in general and let’s just have the naming clear. So when we talk about the DNS server, it’s not only about the DNS server, but it’s about the recursive resolver and about the authoritative name server. So I just want to be sure that we are aligned with this naming because a recursive resolver is the DNS server part that’s within your company where your resolution takes place and the authoritative name server is the part where the zone file resides. So where the admin who is able to write is www.something.com and he is able to give this host name and IP address. So just for the naming to be sure that we’re talking about the same story. Yeah. Well, when it comes to malware and DNS, there are some studies out there that say that 90% of all malware uses DNS somewhere in the cyber kill chain. Because for example, if you’re clicking on a fishing link and you have some malware on your computer, it’s trying to reach some HTTPS servers to download executables or it uses the C2 traffic, command and control traffic at first or it has something called a kill switch. So at first every malware or 90% of malwares will use DNS in order to get the job done. So, this is interesting because it’s not a security issue within the DNS protocol, but it’s just like that malware uses DNS in the way it’s supposed to be, meaning resolving addresses to names.

Johannes Weber: The second story about this malware is like lookalike domains. So, this is not exactly malware, but it’s if you get a fishing mail and you have a link that reads, for example, PayPal, um there’s if you play a little bit with the font, for example, and you have a domain called PayPal, but instead of the lowercase L, you’re writing an uppercase I. It’s like https://www.google.com/url?sa=E\&source=gmail\&q=paypie.com. So you can as an attacker you can own this domain and you can recreate the site from PayPal for example. So this is something called lookalike domain and both problems share in common that you can solve them. You can secure them but at the first glance they are simply using the DNS protocol as it’s meant to be.

David Redekop: Right. Right. I noticed that when I do a search stream like real-time stream of certificates being minted that the amount of times that you see a PayPal lookalike to this day is actually kind of alarming where it’s somewhere in the FQDN. And so you’re using that example today and some people say, “Oh, that doesn’t happen anymore because by now PayPal has protected and owned all of the lookalike domains.” No, they don’t because someone can always use another domain and then put https://www.google.com/url?sa=E\&source=gmail\&q=paypal.com dot their owndomain.com but an untrained eye might just see that oh that’s https://www.google.com/url?sa=E\&source=gmail\&q=paypal.com is the beginning part of it and so yeah know what you’re what you’re describing is absolutely still a problem and the bad guys are still capitalizing on it that’s for sure.

Advanced DNS Threats and Defenses

Johannes Weber: Yes and there are situations where there’s even a third iteration of this kind of attack it’s called domain generation algorithms (DGA). So the malware has an algorithm to generate new domains and the attacker on the authoritative name server side has this algorithm as well. So let’s say in 30 days if the malware comes alive for the very first time it will run through an algorithm. It will know to which domain name to connect. And if this random-looking domain name was registered by the attacker just one day before, it won’t be in any of those known malicious malware feed lists, but the attacker is still able to use it. Let’s talk about the defense side. So when you want to defense such kind of attacks, it’s basically some kind of known malicious feeds or DNS block lists or so on. So that is you have a security provider you will download or you will maybe live through the cloud you will update your feeds where you have known malicious domain names and these lists will have all hopefully all of the malware C2 control servers those lists will have the lookalike domains in it but it’s a little bit complicated for this domain generation algorithm there we have another concept called newly registered or newly observed domains feed. So there the concept is a little bit different because we assume that all new domains are malicious until we verify they are not. However, in the end, you are as an enterprise, you are able to secure this type of DNS attacks or this misusage of DNS because we have basically security feeds that provide you with known malicious or newly observed domains.

David Redekop: Right. And I would add to that, Johannes, that when you refer to newly observed domains that the advanced attackers are now strategically aging domains so that the ones that they are going to use maliciously are no longer newly observed. But where they have difficulty in still overcoming our newest defense is to say if there’s no presence of a good reputation, right, where it hasn’t been legitimately used, that’s a much bigger hurdle. So what we’ve just done as the industry, and I’m sure you’ve seen this too, is that if we put that hurdle in front of them, then that makes it that much harder for the attacker. And at the end of the day, you know, we’re all in the defensive game. So, that’s sort of an advanced area of defense against that. Um, do you have any experience in looking at recent attacks that use strategically aged domains or ones that maybe fell off of a registration renewal and then were captured so that to the registrar reputation system they looked like they still existed. Um I don’t know if you’ve seen anybody I saw a recent example like that on an Infoblox report where a domain was strategically aged. So those are pretty advanced topics.

Johannes Weber: Yes. But fortunately we have counter measures. We have some defense techniques for this as well.

David Redekop: Right. Very good. I know that malware and inside of domain names you mentioned earlier about it being on that applies on the recursive side and that is mostly what we do with our audience is working from the side perspective of the user or the networks that we protect. So it’s almost always our security conversations are around how do we defend the person? how do we defend our devices on the authoritative side? That’s a completely different area of expertise. So yeah, we’re in the same space.

Johannes Weber: Yeah, that’s my perspective as well.

DNS Exfiltration and Tunneling

David Redekop: Exactly. Let’s talk a little bit about some usage of DNS that is applied on the creative side by the attacker still.

Johannes Weber: Yes, there are some ways. The well-known stuff is like DNS exfiltration or DNS tunneling. So doing it that way for a DNS exfiltration being the attacker for a moment, I want to get out some documents on an enterprise network for example, but I’m not able to upload it on OneDrive or so. So I want to get a document out of the network, but I want to fly under the radar at all. One way is to use DNS exfiltration in the following way. You are having the file that you want to exfiltrate. You’re cutting it into small chunks. Maybe you can encrypt it before. You can have something like a Base64 encoding or so and then you have a first step. The second step being the attacker you have a domain on the internet for example attack.biz. And now the malicious malware that resides on the internal network is querying the first slice of the document dot attack.biz. So it’s for example it’s like file01 and then let’s say the first 10 characters dot attack.biz asking for the A record. In fact this is a DNS query and this DNS query will reach the recursive resolver within the enterprise and it will be forwarded or it will be an iterative query to the authoritative DNS server. So the attacker does not run a normal authoritative DNS server because the server will reply with an NX domain but a tool on the server which captures all those DNS queries. And what’s interesting at this creative part is that an outgoing connection from the client where the malware resides to some unknown server is blocked but the query of a DNS is not blocked because he’s reaching the resolver and the resolver has an any-any to the internet allow rule for TCP/UDP port 53 because this is what DNS is using.

Johannes Weber: And in a DNS tunneling, it’s a little bit more advanced because now you can really tunnel traffic through DNS. So again, the attacker has some kind of an authoritative DNS server, which is basically some kind of a script and it’s the server part of this DNS tunneling. The client on the internal network has the client part of this DNS tunneling. And now you can establish a real tunnel. Consider an IPsec tunnel or a GRE tunnel. So you’re encapsulating a packet. You’re encoding it somehow and you’re asking something.attack.biz. This will go through the resolver until the script on the authoritative name server. And the authoritative name server will decapsulate the packet, decode it, encapsulate its answer in a packet and will reply for example as the TXT record of this just queried host name and the way will go back until the client. So again a direct connection from this client to the unknown server won’t be possible but through the usage of DNS and through the usage of this recursive resolver which has a low rule to the internet you’re able to do a real DNS tunneling and there are various tools out there for example DNST or iodine or DNS cat 2. They will easily be blocked by next generation firewalls because of their structure. However, I’ve just had a small conversation with the digital forensic incident response team at our company and he said, “Yeah, well, it’s quite common for malware to use DNS for exfiltration and DNS tunneling. They are not using the well-known tools because they will be recognized quite fast, but DNS tunneling is really a thing.”

Defending Against Tunneling

David Redekop: It is. And I will point the show notes to your recent article where you actually did screenshots of exactly how you did the iodine setup for DNS tunneling and we’ll reference that because the defense against that is very important for you and I. So how do you defend against this idea of tunneling where the endpoint can’t reach a VPN server that’s out on the internet but somehow use the flexibility of DNS resource record types in order to build that tunnel. How do you defend against that?

Johannes Weber: Yeah, this one is a little bit more complicated because until now we have defended through feeds or block lists. Here we can’t do it. We must use a more profound technique which is something like deep query inspection. It’s like a deep packet inspection for the DNS query. There’s no well-known name but in the end what you’re doing you have to analyze the DNS queries and you have to analyze for example the length of the labels or the entropy of the labels. Is it just something like www or server dot or host dot or is it like a random looking string where you have a higher entropy? You have to analyze the frequency or the total number of queries. So this is something that cannot be done easily on an intermediate router or firewall because you have to keep track of all those queries over quite some long period. However, keep in mind that this is probably way easier to analyze on the recursive resolver because he has the memory and the CPU rather than on an intermediate firewall without cloud. So the firewalls are still doing it but with a cloud connection because on the cloud it’s way easier for those companies to analyze huge data. That’s what the cloud is meant for.

David Redekop: Yeah, it’s we’ve come full circle, right? When we used to shift everything to the cloud and now we’re saying no, let’s do everything on premise that should be on premise and let’s use the cloud for what the cloud should be used for. So, as far as the defense is concerned, because these are special record types, um, the approach of blocking record types altogether, if I can jump in real quick with our experience, which is probably shorter than yours, but I’d like to just reflect on it a little bit. When we first saw that two key record types that get abused in this way, one is the TXT and the other one is the NULL record, and to a lesser degree the ones that are labeled private. But let’s just focus on the two big ones, TXT and NULL. We notice that those two record types um are easily able to be blocked completely for the typical end-user device. We’re talking like my computer, your computer, our smartphones and so forth. Whereas the TXT record cannot be blocked when you’re protecting backend infrastructure because of course it’s very actively used for you know acme or any kind of domain validation process right it’s very powerfully used in that way also we use TXT records for other uses like looking up MX records or SPF records that you know could have their own SPF type but could also be a TXT record or some kind of domain validation which is done through the TXT records in the parent zone.

Johannes Weber: Yeah, exactly.

Strategic Placement of DNS Security

David Redekop: So um what is your approach when you say you’re combining the firewall with cloud-centric analytic capability? Talk to us about that for a moment.

Johannes Weber: I think it heavily depends because let’s talk about where to place the DNS security part because if you have a recursive resolver for example and you have a rooted network and you only have a perimeter firewall then for example the DNS security should be placed on this recursive resolver. Why? Because this recursive resolver sees every single query directly from the client. He knows which client ask what. He knows which client he has given the following name because in the firewall will only see the recursive resolver as a source IP address for example. However, if you have not only a parameter firewall but a segmentation firewall and you have your micro-segmentation in place, the firewall will see every single DNS query as well. So you can easily leverage this DNS security part on this segmentation firewall. But it also depends on other topics. For example, do you have a license for that? Because the big firewall vendors, they charge you for the DNS security and it’s not getting cheap if you have a big firewall at your segmentation layer. Or the question at least in Germany we always have the question: do you want to use the cloud or not? If you want to analyze deep query inspection on premises, you have to do it on the recursive resolver because the firewall is not capable of it. If you’re fine with the cloud, the firewall vendors are doing a quite a good job in blocking DNS tunneling events because they can easily analyze tens of thousand DNS queries or let’s say just 10 DNS queries within milliseconds if they are using the cloud. So it depends where to use what and it depends on the customer—is it an air-gapped network or not? I’ve seen every different concept at the customer’s side.

Johannes Weber: And talking about the TXT records and all the other records, in theory for an attacker, it’s also possible to do a DNS exfiltration or DNS tunneling with just A records. It will be way longer. But if you know these numbers, how long an attack is present on your network, even though they are getting shorter, way much shorter. However, if he wants to fly under the radar, he can also do it with just A records. And you won’t block A records or quad A records for IPv6 because if you block them, you’re blocking the internet, don’t you? So, from an attacker perspective, it will just take way longer, but still flying under the radar.

David Redekop: Right? You know, I think you also know Andreas, right? He actually showed me how an NS record serial number can be used to do an A lookup and that in that case it’s even more creative. I’m not sure how often that gets used or abused because you’d have to have a very specific serial number on a domain that you have authoritative control from an attacker’s point of view. But I guess an attacker always does have that anyway. So it makes sense.

DNS Spoofing and DNSSEC

David Redekop: Let’s switch a little bit to another topic that used to be a worse problem but I would argue is less of a problem today in the area of DNS spoofing.

Johannes Weber: Oh yeah. So with DNS spoofing I think there are at least two different kinds of DNS spoofing. The first one is DNS cache poisoning. This is an interesting trick where an attacker tries to fool the recursive resolver to store falsified resource record in its cache. I’m probably not going into detail—you can look it up. Long story short, there is this possibility that an attacker on the internet is able to spoof wrong DNS resource records in a recursive resolver. The second part is classical DNS spoofing, kind of a man-in-the-middle attack. So that is you know that DNS basically is UDP port 53 or TCP port 53 but it’s not encrypted, it’s not authenticated, it’s not secured at all—it’s basically a stateless UDP connection. So a DNS attacker that is in the middle of your routing path—either because of a layer three man-in-the-middle attack like an ARP spoof or neighbor discovery spoof in a local LAN, or for example if he’s doing a BGP spoof or BGP redirect—he’s capable of doing a DNS spoofing attack. And what he’s basically doing if you ask for www.mybank.com and I’m the attacker in the middle I can see your DNS query and I simply can answer you this query but with an wrong IP address that points to my server where I have created the site of https://www.google.com/url?sa=E\&source=gmail\&q=mybank.com.

Johannes Weber: Luckily we have a counter measure for this as well and this is DNSSEC. And now here’s the crucial point of being precise. DNSSEC is not for confidentiality. It’s not about encrypting DNS. It’s still plain text but it’s for authentication and integrity. DNSSEC takes place between the authoritative name server and the recursive resolver in the following way: if you’re an admin and you are orchestrating the DNS zone file on this authoritative DNS server, you are enabling DNSSEC signing. That is you have a public-private key pair. You’re signing your zone with the private key. The public key is sent to the parent zone and the parent zone signs your public key. Job done. And now on the recursive resolver, you have to enable DNSSEC verifying. So if the recursive resolver now goes through the internet and is trying to get the name from the authoritative name server, it does not only store it in its cache but it also checks whether or not it has received the correct answer by using this public key, getting a checksum and validating the RRSIG (resource record signature). By doing this the resolver knows now that it has the correct entry and it has it from the authenticated authoritative DNS server. Well technically he can still spoof DNS but now it’s recognized on the resolver. However, keep in mind that DNSSEC is in most cases not on the client side. So the client still asks the resolver while unauthenticated DNS by now. Um but at least from the recursive resolver point of view the domain names are now signed and verified.

David Redekop: Right and this has been a 20-year journey. So DNSSEC at this point is no longer even a teenager and it’s amazing how many iterations it has gone through but it actually works right it does take some upfront heavy lifting the one time and after that you eliminate that risk so it’s still the chicken or egg problem. So because it only makes sense if there are way more websites or zone files in the whole internet that are signed. So as of now I think it’s not that much. However from the IT security perspective it’s really quite easy to activate DNSSEC validation on your recursive resolver. So if you’re doing some kind of bind server or if you have an Infoblox appliance for example, it’s just a check mark and checking that the right public key of the root zone is there and you’re done. So this is quite easy. So please enable DNSSEC validation. Test it of course in your lab but then activate it on your production environments because it’s quite easy and at least you will get rid of DNS attacks for signed zones.

David Redekop: Yes, exactly. And on that adoption curve, the last time I saw an adoption curve, it kind of looked like it was flatlining at under 20% of domain names that are active that are actually DNSSEC signed. But obviously it makes sense that if your domain or an organization’s domain is ever at risk for having a cache poisoning or a man-in-the-middle attack, then that’s the first mitigation is to apply that. That’s for sure.

DNS Privacy: DoT and DoH

David Redekop: Now what’s interesting is in another topic of how we’ve advanced DNS recently is in the area of privacy and privacy is not the same as authentication and integrity but it actually is beneficial. Talk to us about that.

Johannes Weber: Yeah. So this is still the missing part which is solved by DoT or DoH. Let’s start with DoT for a sec. DoT is DNS over TLS. So basically it uses another port, a well-known port which is 853. So if you have a resolver that listens on this port, you can talk from the client side via DoT. In fact, this can easily be blocked by a firewall. So it turned out that it actually is blocked in the internet at least at situations where you are fearing that your DNS traffic is of interest for some other third parties. If they can easily block it, it’s not usable. So in the meantime DoH is used—DNS over HTTPS. It uses the well-known port for HTTPS which is port 443 either on TCP or on UDP if you’re using QUIC or HTTP/3. In fact it’s just another component on a web server and the advantage of doing that is that this web server has its port 443 opened already for delivering web content but now it is also capable of answering DNS queries. Doing it that way on a firewall that basically allows TCP 443 because otherwise you would not allow the internet, it cannot distinguish between a DNS over HTTPS query or just web traffic. Of course it’s meant to encrypt the data. So with DoH you will have an encrypted channel between the client and the resolver. Doing it that way, an attacker can neither DNS spoof the packets nor can he eavesdrop because if he’s capturing on the link, he will only see random data because it’s basically encrypted.

Johannes Weber: So, this is a good thing, but not for every situation. So if you’re a private person and if you’re in a public Wi-Fi, you probably want to use DoH because you don’t want that all the other Wi-Fi clients are capable of eavesdropping or capturing what you are doing on your computer. However, if you are within an enterprise environment, it’s a little different because as we have heard so far, we are using some DNS security on the firewall or on the recursive resolver. But if now the client or some applications like browsers are using their own DoH resolver, this DNS traffic will circumvent the DNS security that we are running within our infrastructure. So this is not a good point. So if you’re an enterprise, you either have to deploy DoH on your site—so please deploy DoH on your recursive resolvers—then your clients can use DoH but still using your recursive resolver where your DNS security takes place—or you have to decrypt it classical TLS interception in the middle on the firewall. Basically this is just again this question—we are losing some kind of privacy within an enterprise environment but we are getting more secure networks. Well, it’s this discussion. However, at the first glance, we are getting confidentiality and we’re getting privacy when using DNS.

David Redekop: Right? And this is getting to be really important in more and more parts of the world where those in power realize the value of the data of the behavior. And so when internet service providers can actually sell the data of DNS queries or are getting orders from the authorities to reveal the data of traffic patterns. That’s of concern to those of us that live in a free world and want to keep living in a free world and want to have our next generation live in a free world. And so DoH is a welcome technology, a welcome advancement for that purpose. But to summarize what you just said, it is also a threat for an enablement of an attacker that can use DoH as a channel that’s not authorized unless there is mitigation against it. So it’s like the ultimate double-edged sword, right? It is good and it is bad, but we can now wield it for good and that’s what we’re after.

Road Warriors and IoT Security

David Redekop: So, speaking of wielding it for good, let’s talk about your experience in where all of the DNS security should be placed inside of an organization.

Johannes Weber: Yeah, I I think I I spoiled it already. So it depends on the customer whether or not it’s on the perimeter firewall, on the segmentation firewall or on the recursive resolver. It depends on the licenses, it depends on the cloud strategy or no cloud at all. It also depends on the size of the organization. And this question is not only for the enterprise but also for the road warriors. Where are your home office users sitting? Because when your client is moving all around the world, your best security at the enterprise firewall is not of interest anymore. So we have to use something like a secure DNS resolver via an agent, via full tunnel VPN, via a proxy solution. It’s all this SASE/SSE stuff which you have to keep in mind when you’re designing the DNS infrastructure because it’s not only for the on-premises enterprise worlds. However, we will still have some IoT devices in every single corner of your enterprise environment. So yeah, it’s still a problem there which we can solve but it’s not 100% of the scope to solve the DNS security stuff only on the enterprise network.

David Redekop: Right and of course traditionally organizations were deploying VPN technologies or even the always-on VPN technology that was matured both on Microsoft side as well as iOS. Um but anymore we’re moving towards a VPN-less protection. So that’s when a different kind of an agent instead of a VPN endpoint becomes really critical.

Home Lab Tools

Johannes Weber: Everyone uses his agent. So talking about enterprise networks now all the time but when you’re using a home office or when you’re some kind of nerdly network security guy back at your own home lab you can use for example the Pi-hole. I’m quite sure you’re aware of it because the Pi-hole already is able to block not only ads and tracking but also malware if you are feeding it with some non-malicious malware feeds. It’s also capable of doing DNSSEC validation. You can optionally use it with your own recursive resolver which is installed on the Pi-hole as well. So doing this you have some basic DNS security at your home network as well for almost free. The Pi-hole won’t block DGA DNS names for example because it doesn’t have the list and it won’t block any DNS exfiltration or DNS tunneling attempts but to be honest those attacks are not of interest for a private home network because if you have a malicious malware it will simply send gigabytes of data out the network without being blocked anyway.

David Redekop: Right? And that not to speak of just that, but also the advanced malware that doesn’t use DNS at all of any kind. It just says I don’t need DNS. I can just tunnel this out over an IP address that’s directly reachable by me.

Recommended Tools and Closing

Johannes Weber: Yeah. What’s else on my list is talk a little bit about tools just to link them in the show notes. I want to highlight like two or three tools. One of them is DNSviz. It’s an open source tool where you’re getting a graphic sketch out of the DNS tree for your host name. This is quite cool when it comes to DNSSEC because it points to problems where the DNSSEC chain of trust is wrong or is falsified. Another one is called DNSdiag and this is a small tool suite that has one tool called DNS ping. Everyone is aware of a normal ICMP ping but this one is a DNS ping. Every single second it queries a recursive resolver for the given DNS name and it also is capable of doing DoT or DoH for example. So by using DNS ping you are aware of some latency issues or if you’re an administrator rebooting a DNS server you know when the service is back online again.

David Redekop: You know this list of topics in the DNS is near and dear to my heart. Um and I really appreciate you preparing this for the podcast today and I’m wondering if there’s any piece of wisdom that you would like to leave with defenders globally.

Johannes Weber: I think which might be of interest is that I am providing a pcap which is like many many pcaps in one single download. It’s called the “Ultimate Pcap.” You can download it from my blog. I’ve been capturing packets for the last 10 or 15 years. Within this single pcap you have over 90 different network protocols both for IPv4 and IPv6. For example when you want to look how is OSPF for IPv6 on the network or how is W traffic analyzable within Wireshark. All of these different kind of DNS—I in this ultimate pcap we have different kinds of queries: DNS tunneling, DoT, and all of this stuff. You can practice your Wireshark skills by using the single pcap.

David Redekop: Very good. I will provide a link for that in the show notes and I think that’s of huge value. The way you’ve gone about making sure that the community has access to the rich content that lives inside your head has been a really good example. Um, I’m hoping that you have fun doing that because you keep doing that and every time you publish a blog article, I can see there’s so much heart, so much real life effort that has gone into it to make sure that it is easily consumable by people of different skill sets. So those that are in learning mode, that are getting into the defender space, part of me is actually always speaking to the next generation. My wife and I are blessed with five sons and it’s possible that none of them will end up in our industry. And so if they don’t, we have to find a way to raise the next generation outside of my family to continue to defend because as long as we continue to evolve, the attackers will continue to evolve. And so therefore, we have to stay current and continue to protect people, protect the devices that belong to them, protect our corporate networks, protect our assets everywhere, and have fun doing that because if it’s not enjoyable, then we’re not going to stick with it for the long haul. So, you’ve been a good example to the community of how to make it be enjoyable to learn.

Johannes Weber: Yeah, it’s my part of a contribution to the community because I cannot develop, I cannot code, but there are many many tools out there that are quite good but I cannot contribute to those tools because I cannot code—my kind of contribution is writing blog posts or being on a podcast. That being said, if you have some German listeners, I have an own podcast. It’s called “Security as a Podcast” (auf Deutsch). So, if you are interested in just another security or network security podcast, please have a look at this one. Thank you very much.

David Redekop: So, I’m looking forward to that. Thank you very much for your time today and have a wonderful 2026.

Johannes Weber: Yeah, thanks for having me. Bye.

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.