DNS Servers in Isolated Networks — Will they Leak?

When it comes to isolating networks, DNS servers require special attention. DNS servers may leak information from isolated network by proxying queries all the way to the Internet. At worst, a malicious actor can smuggle secrets out.

A few days ago, I detected a +2dB increase in conversation volume somewhere nearby. I set out to investigate. It came from the office next to Badrap. SensorFu crew was celebrating like only the Finns can. Mildly. “They finally finished their installation of 24 Ramlösa cans and 8 Club Mate bottles”, I thought. I was wrong, they were celebrating their latest Beacon release.

SensorFu’s CEO Mikko ordered the crew to celebrate their new release for a minimum of two seconds before returning to work.

The first release of Beacon shipped with IPv4, IPv6, TCP and UDP tests to check the foundation of your network. The tests did include direct connections to the Internet using DNS ports TCP/53 and UDP/53. Now Beacon can talk to the DNS server used in the isolated network, to see if it relays messages to the Internet.


I asked why they picked DNS as the next target to test. Their answer was “past experience”. They have seen how DNS servers proxy messages in and out from otherwise well-isolated network. These leaks have come as a surprise to the network owners. “Sounds like a trivial mistake,” you say? On paper, yes, but if you look how things are deployed in practice, you start to see why they happen. I’ll give an example. Network owner buys a software solution from an Integrator. Integrator buys parts from vendors. Vendors use subcontractors to deploy their systems. Long communication chains and limited sharing of information between different actors easily lead to disconnects between policy and practice. Firewall admin may assume DNS server itself in the border between isolated and non-isolated network needs resolving capability. DNS admin thinks firewall admin takes care of the blocking and does not even think DNS server settings need attention.

This is not a DNS-specific problem. Network complexity provides a good cover for all sorts of seemingly simple mistakes. Oulu University Secure Programming Group researched this topic actively in 2002–2010.

Another challenge is the seemingly benign nature of DNS. They are just name-to-IP queries, right? In practice, even the legitimate queries from isolated networks are useful for all those eyes watching the Internet traffic. Outsiders can identify operating systems and software used in the isolated network. Queries also reveal some of the places people and machines in isolated networks connect to. At worst, a malicious actor has a route to smuggle information out from the network.

Prior Art

Tooling to catch DNS leaks is somewhat lacking, but not completely missing. On the other hand, tools to tunnel IP-traffic over DNS does exist and are being used to circumvent those pesky firewalls and poorly working authentication gateways in hotels.

Catch leaks

If you can’t block DNS in your isolated network, Detecting DNS Tunneling by Greg Farnham lists methods to detect misuse. If your setup is supposed to block all outside queries, Canarytokens allows you to create DNS traps and get alerts when specially crafted queries reach their servers.

Circumvent policies

DNS tunnelling utilities are typically used for circumventing firewalls and authentication gateways in hotels and airports. Iodine is one of them. Detecting DNS Tunneling also provides a list of DNS tunnelling tools.

SensorFu’s Ossi and Mikko talking about escape methods in Disobey 2018.

If you want to leak like a pro, check the Xipology blogs by SensorFu’s own Ossi Herrala and Marko Laakso. Or listen to Ossi talk about it in Disobey 2018. Typical DNS tunnelling tools require an external name server controlled by the attacker. Ossi and Marko build a practical implementation which uses caches of existing servers instead. The example implementation was for discovering peers in the net, but the same method applies for any communication over DNS caches. They based their work on a Phrack-article DNS Covert Channels and Bouncing Techniques.

How DNS server leaks work

The basic concept is simple. For readers who want to understand the nitty-gritty details, read how DNS works — a fun and colourful explanation of how DNS works. A short version for others below.

Probably the simplest way to leak is to ask an IP-address for a domain name which contains the secret and the attacker’s domain. See the example in Figure 1.

Figure 1: DNS-leak from the command line

The coordinates of an ancient treasure just got out. What happened? Hikileaks.test represents the attacker’s domain in this example. It is served from his DNS server (Rec) — see Figure 2. He made the query from the host (S), guarding that secret. (S) contacted resolver (Res) to get an answer. Resolver didn’t know it, so it asked root servers (R)s where to get the answer. Then the resolver contacted Leaker’s server and that’s it. Leaker returned an error message (NXDOMAIN), but that won’t matter, the secret is out.

Figure 2: DNS server leaks simplified.

How Beacon DNS test works

See Figure 3. You put the Beacon (B) in your isolated network. Beacon learns the local DNS server (Res) from the network by using DHCP or IPv6 autoconfiguration. If everything else fails, it attempts to query Google’s DNS It starts its relentless work, making periodic queries (1) to the resolver used in the network. If the resolver does not already know the IP-address of the authoritative DNS server of sensorfu.com, in this case (H), it will figure it out by asking DNS root servers (2). Finally resolver makes a query (3) and you will get an alert (4). Simple as that.

Figure 3: Beacon tests DNS leaks continuously. You will get an alert if it succeeds.

How they tried to make it simple

Customers can download a new image from Home and deploy. You will find a new configuration option called “DNS Escape Target Address”. By default, Beacon uses the domain served by the Home instance used by the user.

Figure 4: Settings related to DNS

The address refers to the domain served by the SensorFu’s Home (Figure 3). If you use DHCP or IPv6 autoconfiguration in the network, check that DHCP or IPv6 autoconfiguration is enabled from the settings. Otherwise, the Beacon conducts the test via Google’s resolver at address Beacon does not add any information about the isolated network, so from the outsider’s perspective it is just one query among others coming from that network.


If you need true isolation, pay attention to the DNS servers. If you have time on your hands, some do-it-yourself options for monitoring do exist. Among other tests, the Beacon now provides a hassle-free way to continuosly test if your DNS servers in isolated networks work as you expect. Just drop Beacons to your isolated environment and get alerts if you networks leak.

Disclaimer: Jani is not working for the SensorFu, but he has a stake in the company.