最初官方的代码没有找到，但是发现github里貌似有：

git clone https://github.com/splitbrain/dnstunnel.git

源码是perl写的，需要安装一些perl依赖包。

安装perl模块方法说明：

(sudo) perl -MCPAN -e shell

install Log::Log4perl

install HTML::TokeParser::Simple

h

q

   

The above will install Log4perl in /usr/lib/perl5/site_perl/5.6.1/Log/Log4perl.

需要注意的是必须使用root权限才能安装成功。

看源码dnstunneld：

use Fcntl;use Net::DNS;use Net::DNS::Nameserver;use LWP::UserAgent;use Time::HiRes qw ( usleep gettimeofday );use MIME::Base64;use MIME::Base32 qw ( RFC );use IO::Socket;use Class::Struct;use threads;use threads::shared;use Thread::Queue;use Getopt::Long;

需要安装Net::DNS， LWP::UserAgent，Time::HiRes ，MIME::Base64，IO::Socket，Class::Struct，Getopt::Long。 MIME::Base32不需要，直接注释掉源码！如果不注释掉，发现有导入包的错误。

dnstunnelc，客户端安装包类似：

 

use Fcntl;use Net::DNS;use MIME::Base64;use MIME::Base32 qw ( RFC );use Time::HiRes qw (usleep gettimeofday );use Getopt::Long;use threads;use Thread::Queue;

 

需要安装Net::DNS，MIME::Base64，Time::HiRes，Getopt::Long；同样注释掉use MIME::Base32 qw ( RFC ); 这行代码！

server端：

 

sudo perl dnstunneld -i 0.0.0.0 a.friendsxxx.com client端： ssh -o ProxyCommand="perl dnstunnelc  a.friendsxxx.com" root@xxx.com

没有成功！可能是被dns服务器给切断了。

 

The Fake Server

The fake server you can set up at your server to tunnel all the traffic through is a little program called , written in Perl (Client and Server together 642 SLOC) by DNS guru . The tool is split in four files, two of them being a file upload/download tool using DNS. Nice examples, but rather uninteresting for our approach.

The script nomde.pl is the server. Since the server binds to port 53 UDP on your server (which is a privileged port) you must be root to start the server. Also, make sure port 53 UDP is reachable from the outside (consider running nmap -v -sU host from a remote machine). You will usually want to start it as follows:

sudo ./nomde.pl -i 0.0.0.0 server.example.com

Here, the server will only listen to DNS requests for all subdomains of server.example.com. That way, people who don't know that exact address cannot use the service on your server.

The Client

The OzymanDNS client is just a perl script which encodes and transfers everything it receives on STDIN to it's destination, via DNS requests. Replys are written to STDOUT.

So this isn't particularly useful as a standalone program. But it was designed to be used together with SSH. And with SSH this works great. SSH has a config option, ProxyCommand, which lets you use OzymanDNS's droute.pl client to tunnel the SSH traffic. The command to connect to your server would look like this:

ssh -o ProxyCommand="./droute.pl sshdns.server.example.com" user@localhost

Note two things:

1. Add a sshdns. in front of the hostname you specified the server to listen to and
2. Since your connection will already have been tunneled through DNS (and thus has come out at your host already) there is no need to login as user@server.example.com (because that already is localhost)

Once the connection is established (you'll probably have to enter your password) you have a shell! The connection is a little bit droppy sometimes and has not got the best latency, but it is still good keeping in mind that connections to the internet are not allowed at this Cafe/Airport/....

Tunneling

Once you verified that the connection is actually working, you can set up a tunnel so that you may not only have shell, but complete web acces, can fetch mails using POP, etc., etc...

For this, I recommend to read my tutorial on .

Don't forget: It may provide great performance increases to use SSH's -C ("compress data") switch!

Communication between the Servers

So, now how might the servers communicate with each other, not being directly able to establish a connection?, you might ask now.

Well, since all subdomain resolve requests are delegatet (ie., relayed) to your host, you can include arbitrary data in the hostname which your server then can interpret and execute/relay.

The bytes you want to send to the server (upstream) will be encoded using Base32 (if you know what Base64 is, Base32 is just the same except there is no case sensivitiy, for EXAMPLE.COM ist just the same as example.com). After the data, there is a unique ID (since some DNS requests may take longer than others and the UDP protocol has no methods to check this) and either one of the keywords up or down, indicating whether the traffic's up- or downstream. Here is what an example request could look like (transferring something to the server):

ntez375sy2qk7jsg2og3eswo2jujscb3r43as6m6hl2wsxobm7h2olu4tmaq.lyazbf2e2rdynrd3fldvdy2w3tifigy2csrx3cqczxyhnxygor72a7fx47uo.nwqy4oa3v5rx66b4aek5krzkdm5btgz6jbiwd57ubnohnknpcuybg7py.63026-0.id-32227.up.sshdns.feh.dnstunnel.de

The server's response comes as a DNS TXT record. A TXT record can hold arbitrary ASCII data and can hold uppercase letters as well as lowercase letters and numbers (some other characters, as well). So the responses come Base64 encoded. Such a response might look like the following one:

695-8859.id-39201.down.sshdns.feh.dnstunnel.de.   0       IN      TXT"AAAAlAgfAAAAgQDKrd3sFmf8aLX6FdU8ThUy3SRWGhotR6EsAavqHgBzH2khqsQHQjEf355jS7cTG+4a8kAmFVQ4mpEEJeBE6IyDWbAQ9a0rgOKcsaWwJ7GdngGm9jpvReXX7S/2oqAIUFCn0M8=""MHw9tR0kkDVZB7RCfCOpjfHrir7yuiCbt7FpyX8AAAABBQAAAAAAAAAA"

That is, in rough outlines, how tunneling via DNS works.