> In a pentest scenario, you sometimes have a shell on a system which has no route to the internet, and you lack permissions for a web proxy or you don't have access to one.

How would using a proxy masquerading as SMTP be any more viable in this situation than a proxy masquerading as HTTPS?

> Your next best bet is probably tunneling over DNS with Iodine or something similar.

DNS typically does not involve bidirectional transfer of large volumes of encrypted traffic. Doing this over DNS would stick out like a sore thumb to anyone doing traffic analysis, whereas this is exactly what you'd expect to see over HTTPS.

> Many internal DNS servers resolve external host names.

Sure, but the internal DNS in this scenario would typically be either forwarding external DNS requests to an outside resolver determined by its own configuration, or is itself hosting a full DNS table. How would you be able to use your own proxy masquerading as DNS in this situation?

The goto tool that practically anyone doing any DNS tunneling uses is dnscat2 (https://github.com/iagox86/dnscat2). It works fine through recursive/forwarding resolvers because those resolvers must recurse out to the authoritative nameserver for a given domain in order to resolve the name request. With dnscat2 you use the server component "hosting" a "zone" using a domain name you own / control (so that you can point the authoritative nameserver record to the dnscat2 server component). You then use the dnscat2 client to packages up TCP traffic into DNS specially crafted DNS requests to the domain you control where the server is listening. The design is very clever and has to solve a lot of tricky technical problems.

As for detection, you're entirely right that sending large volumes of traffic over DNS is both incredibly slow, and incredibly obvious to any network defenders paying attention to DNS.