DNS is a service that is used on every system to provide basic functions of the Internet. Therefore, it is a popular target for misuse. Such misuse can be the so-called DNS tunneling. In DNS tunneling, another protocol is “tunneled” through DNS. A DNS tunnel can be abused for command and control, data exfiltration, or tunneling other Internet Protocol (IP) traffic. DNS tunneling can achieve a bandwidth of 110 KB/s with a latency of 150 ms.
Tunnel Basics
Many of the tools used to create DNS tunnels were developed with the intent, Bypass portals for paid Wi-Fi services. If one of these systems allows outbound DNS traffic, a DNS tunnel can be created that tunnels IP traffic so that one can use the service for free.
Some of the DNS tunnel utilities create a tun or tap interface locally on the endpoint systems. A tun or tap device is also created on the DNS server that hosts the DNS tunneling tool. This allows the user to tunnel IP traffic to the Internet. This technique can be compared to how VPN software works. There are even commercial providers that offer a server-side tunnel as a service and market this service as “VPN over DNS”. The user can use such software to connect to the service provider’s server, which then runs the server-side tunneling.
These services are now available for various operating systems, including Android, for example. It is known that such tunneling sotware (e.g., Iodine) has been used in some attacks.
Tunneling components
A number of DNS tunneling programs have been developed since the late 1990s. All of the programs use similar techniques in doing so, but have variations in coding and other implementation details. The core techniques used by all DNS tunneling utilities include a controlled domain or subdomain, a server-side component, a client-side component, and data encoded in DNS payloads. The controlled domain is used to define the authoritative name server for that domain or subdomain. The server-side component is called the DNS tunnel server. The DNS tunnel server is the authoritative name server for the controlled domain. It is typically an Internet-accessible server that is controlled by the user. The client-side component hosts the other end of the tunnel. For example, this could be an endpoint in a security-controlled enterprise environment. The tunnel enables communication between the controlled endpoint and any host on the Internet. The client-side component initiates a DNS request for which the DNS tunneling server assumes the role of name server.
Encoding and techniques
One of the core techniques of tunneling programs is the encoding of data into “DNS payloads”. From a highly simplified point of view, a client wants to send data to the server. In doing so, this data is encoded in the “DNS payload”. For example, the client might send an “A record request”, where the data in host MRZGS3TLEBWW64TFEBXXMYLMORUW4ZI.t.example.com. The server
could respond with a CNAME response: NVWW2IDPOZQWY5DJNZZSQ.t.example.com. In this way, any data can be encoded and sent to the server. The server can also respond with data. However, if there is a need to initiate communication for the server, this cannot be done directly. Clients do not have services listening for DNS requests, plus they are usually behind a firewall. However, server-initiated communication can be achieved by the client making regular requests to the server. Then, if the server has data for the client, it can send it in response to the request. As mentioned earlier, the various DNS tunneling utilities differ in their implementation details.
DNS utilities differ in their implementation language, with tools being implemented using, for example, C, Java, Perl, and Python, to name a few. Some utilities use a “tune or tap” to create a local interface and IP address for the tunnel on the hosts. Others tunnel only the binary data, which can be used similarly to Netcat to issue operating system commands and transfer files. The encoding method – including the DNS record type – is one area where different tools differ fundamentally. Some utilities use common record types such as “A” records.
Others use experimental data types such as ‘null’ records and EDNS to improve performance.
Base32 encoding
Base32 or 5-bit encoding is commonly used for queries from the client. Although DNS names have upper and lower case letters, this is to be ignored so that 26 letters are available. In addition, numbers and the character “-” are allowed. This gives a total of 37 unique characters. Therefore, we can record data in 5 bit increments, which gives us 32 possible values. These 32 values fit into our 37 available characters. We can then build a series of nested subdomains from the encoded data. In doing so, DNS allows us up to 255 characters, with each subdomain (aka label) containing 63 characters or less.
Base64 encoding
Base64 or 6-bit encoding can be used for “TXT” record responses. A “TXT” record can have upper and lower case letters, which gives 52 characters. The digits 0-9 give us 10 more. If we consider two additional characters like “-” and “+”, we come to 64 unique values that can be used for Base64 encoding. Similar to Base32 encoding, request can be encoded and sent 6 bits at a time.
Binary (8 bit) encoding
Binary 8 bit encoding can be used. Although not compatible with every DNS server, it is possible to use 8 bits per character for encodings if a larger bandwidth is supported by the tunnel. In this case, Iodine uses “null” type records for responses to allow 8-bit encoding.
NetBIOS encoding
NetBIOS encoding is another method used for data encoding. For NetBIOS encoding, each byte is divided into 4-bit nibbles. To each of these nibbles, decimal 65 is added. Each byte is then encoded in a DNS label of two characters. However, this method is only used by DNScat-B.
Hex Coding
Hex encoding is another encoding method. With hex coding the two hex values of the characters are used to represent each byte. This method is only used by DNScat-B.
Techniques
DNS tunneling utilities may use different DNS record types and encoding methods. In some cases, such as with Yod, the utility automatically detects the best possible encoding. There are a number of other implementation techniques that deserve mention. DNS tunneling utilities can use EDNS, which allows them to use payloads that exceed the 512 bytes limit, improving performance. Another DNS tunneling utility, Heyoka, spoofs the source IP addresses for requests to the server (upstream data) to reduce the client’s visibility.
