大家为了网站页面的美观，一般都会在文章中插入图片，但是有时候插入的图片却无法显示或者出现乱码，笔者 就遇到过这样的问题。后来偶然间发现，自己上传的英文名图片却毫无问题，很明显就能知道问题的症结，由于wordpress是外国人开发的软件，虽说是中 文版，但是对中文的支持还是不怎么友好，控制上传文件的系统文件里面的源代码并不支持中文编码。在这里提醒大家，在wordpress网站的数据库里不要 出现中文名的文件夹和文件，如果你实在想用中文命名数据库里面的文件和文件夹，你必须按下面的方法修改你的wordpress中文件的源代码。

1、首先修改一下上传，打开 wp-admin/include/file.php文件，找到

$new_file = $uploads['path'] . “/$filename”;

将这一行修改为：

$new_file = $uploads['path'] .”/” .iconv(“UTF-8″, “GBK”, $filename);

这样修改后就将上传的文件的文件名转换成了GBK编码，服务器就能够正确的识别文件名了。

2、然后找到

return apply_filters( ‘wp_handle_upload’, array( ‘file’ => $new_file, ‘url’ => $url, ‘type’ => $type ), ‘upload’ );

将这行修改为:

return apply_filters( ‘wp_handle_upload’, array( ‘file’ => $uploads['path'].”/$filename”, ‘url’ => $url, ‘type’ => $type ), ‘upload’);

3、但是存放于数据库的文件名依然是UTF-8的，所以，在使用 basename() 函数时，文件名再次解析错误。

打开 wp-admin/include/media.php 文件，找到

$filename = basename($post->guid);

修改为:

$filename = substr($post->guid, strrpos($post->guid, ‘/’)+1);

我用sae的wordpress测试后，发现第三步中的内容不能在wordpress3.2中找到，因此只修改了前两步，并实现了相同的效果。

————————————————————

另外一种方法：

要修改的是wordpress\wp-admin\includes\file.php

查找：

$filename = wp_unique_filename( $uploads['path'], $file['name'], $unique_filename_callback );

在其后加上：

$fileTypeNameArr =explode("." , $filename);

$countNum=count($fileTypeNameArr)-1;

$fileExt =  $fileTypeNameArr[$countNum]; //取得所上传文件后缀名

$filename = time().'-'.rand(0,999999999).'.'.$fileExt;//将文件由原名改为时间戳

这样上传的文件不再以中文存储，而是以时间戳为名称存储。

上传中文名的文件后，依然能够将原中文文件名作为文件的标题。

现转一篇关于解决此方法的文章来备用。

这个问题很烦.
最初的代码是:
sql=”select * from [Product] where (id is null)”
rs.open sql,conn,1,3
rs.addnew
Call savedata()
rs.update
rs.close
set rs=nothing
提示的错误就是:
Microsoft OLE DB Provider for ODBC Drivers ’80004005′

我郁闷啊,检查代码好似没有问题啊!这个过程是枯燥,痛苦的!~~~
然后又到网上搜索了半天,结果有:
使用rs.Update()的时候，发现如下错误：

[Microsoft][ODBC Microsoft Access Driver]行中有错误

1、开始怀疑参数的问题，在进行数据更新的时候发生参数不符合数据库内的类型或其他的要求。
比如：id字段一般用int或自动编号的，但是如果你传入了char或string的类型，那么更新就会失败。
通过检查程序，排出怀疑；

2、数据库锁定。看是否有其他的程序在使用数据库。检查排出。

3、还是回到第一个。只不过是怀疑数据库。数据库建立的时候有问题。通过仔细的检查，发现数据库内有一个字段的数据建立的“索引：有（无重复）”，而需要更新的时候发生了重复，所以无法更新；修正后，更新成功；

然后我把conn,1,3改为conn,2,3哈哈错误更加详细了~~~~~看来参数也很有用的哦
[Microsoft][ODBC Microsoft Access Driver] 字段 ‘Product.Spec’ 不能是零长度的字符串。

\admin\ProductSave.asp, line 60

1、在点击开机菜单后，选择菜单中的“运行”栏目。在运行栏目的输入框内键入“regedit”，回车即可打开注册表编辑器。

2、打开注册表编辑器之后，进入“HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services \Msahci”键值。在右边窗口中双击名称为“Start”的项目，会弹出一个对话框，将默认的参数由3更改为0。点击“确定”并且保存之后，重新启动 电脑。

3、重启电脑之后，进入BIOS，在“Integrated Peripherals”页面中，将“SATA RAID/AHCI Mode”更改“AHCI”（不同BIOS选项名称会有细微差别）。保存重启，进入系统后系统会自动安装AHCI的驱动程序。安装好后系统会要求再次重 启，重启之后，硬盘的AHCI模式就打开了。

硬盘在更改为AHCI模式之后，系统启动的速度变化不大。不过在进行大文件拷贝时，速度由原来的60MB/S提升到了71MB/S，性能提升约 20%。硬盘在Windwos7中的系统评分中，也由开始的5.9分提升到了6.5分。由此可见硬盘开启AHCI之后，效果是不错的。

In this post, I will try to explain how to setup NAT64 & DNS64 in order to enable an IPv6 LAN (no IPv4 enabled) to talk to a mixed IPv4 en IPv6 Internet. It is assumed that there are no IPv4 hosts left in the LAN. In the setup there is one gateway for both native IPv6 traffic and translated (NAT64) IPv4 traffic. This gateway is also the DNS64 server.

Operating system and packages
The setup was built using Ubuntu 10.04 server, using the following packages:

• Router Advertisements: RADVD (available via ubuntu package manager)
• DNS64: TOTD (available via ubuntu package manager)
• NAT64: TAYGA (available here as a package)
• DHCPv6: WIDE-DHCPV6-SERVER (available via ubuntu package manager)

Interfaces & prefixes
The following interfaces & prefixes were used (replace values by your own where needed):

• Assigned IPv6 subnet: 4000:0:0::/48
• LAN IPv6 subnet : 4000:0:0:1::/64
• LAN interface: eth4
• IPv4 Internet interface: eth0
• NAT64 tunnel interface: nat64
• 6to4 NAT range: 4000:0:0:2:EEEE::/96 (should be within your own subnet)
• GW IP: 4000:0:0:1::1/64
• An Internet based DNS server with IP 99.99.99.99

RADVD & DHCPv6 configuration
RADVD will take care of sending Router Advertisements to the clients, enabling SLAAC (Stateless Address Auto-configuration). Is should be configured like this (/etc/radvd.conf):

interface eth4
{
    AdvSendAdvert on;
    AdvManagedFlag off;     //stateless autoconfiguration
    AdvOtherConfigFlag on;  //clients get extra parameters via DHCPv6
    MaxRtrAdvInterval 10;   //resend RA @ random times, max 10sec delay
    prefix 4000:0:0:1::/64  //announce prefix to clients
    {
        AdvOnLink on;
        AdvAutonomous on;
    };
    RDNSS 4000:0:0:1::1
    {
    };
};

While the RDNSS messages are sufficient for some operating systems like iOS and Linux (with extra rdnssd packages), others need their DNS via DHCPv6 (such as Windows 7). Mac OS X doesn’t listen to any of them and needs a manual DNS configuration.
The DHCPv6 configuration is rather simple. Put the following line in /etc/wide-dhcpv6/dhcp6s.conf:

option domain-name-servers 4000:0:0:1::1;

DNS64: TOTD
The TOTD package is a DNS64 + forwarding daemon (it doesn’t handle DNS itself):

• If an AAAA request is made for a hostname that has AAAA records, the original AAAA record is returned
• If an AAAA request is made for a hostname that only has an A record, TOTD will translate the original A record (holding an IPv4 address) into an IPv6 record, using the prefix configured in its configuration file (/etc/totd.conf) :

forwarder 99.99.99.99 port 53   //forward DNS requests to this server
prefix 4000:0:0:2:EEEE::        //this prefix is used for translation
port 53

NAT64: TAYGA
The TAYGA package takes care of the NAT64 process. Whenever DNS64 returns a translated address to a client, it connects to the newly generated IPv6 address through its default GW. The GW itself sends the package to his nat64 tunnel interface which is managed by the TAYGA daemon. The daemon creates a mapping between the IPv6 address of the client computer and an IPv4 address of the private address range, as configured. As a last step, the IPv6 address as returned by DNS64 is translated back to the original IPv4 address and sent out to the Internet, using normal NAT44.
This is how it’s configured:
Create the following configuration file (/etc/tayga.conf):

tun-device nat64              //name of the NAT64 tunnel device
ipv4-addr 172.16.254.1        //IP address of the remote tunnel endpoint
prefix 4000:0:0:2:EEEE::/96   //IPv6 prefix of translated IPv4 addresses
dynamic-pool 172.16.254.0/24  //pool for mapping IPv6 client <-> IPv4

Next, let TAYGA create the tunnel device and add the necessary IP addresses & routes:

tayga --mktun                               //create tunnel devices
ip link set nat64 up
ip addr add 172.16.0.1 dev nat64            //local endpoint of the tunnel
ip addr add 4000:0:0:1::1 dev nat64         //same IP as GW
ip route add 172.16.254.0/24 dev nat64      //send through tunnel
ip route add 4000:0:0:2:EEEE::/96 dev nat64 //send through tunnel
tayga -d

(or use /etc/init.d/tayga start – the -d option gives some debugging information)

The translated (IPv4) packets will be sent to the default GW for IPv4 connectivity. The only thing left is to translate the source address (the local IPv4 endpoint address of the nat64 tunnel) to the public IPv4 address of your internet interface. This is done with IPTABLES:

iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
iptables -A FORWARD -i eth0 -o nat64
                    -m state --state RELATED,ESTABLISHED -j ACCEPT
iptables -A FORWARD -i nat64 -o eth0 -j ACCEPT

IP Forwarding
If you haven’t done so already, turn on IP forwarding on the gateway:

echo 1 > /proc/sys/net/ipv4/conf/all/forwarding
echo 1 > /proc/sys/net/ipv6/conf/all/forwarding

(can also be done via sysctl commands etc…)

Debugging

• To check if the DNS64 is working correctly, try doing some nslookup’s (or dig). Hostnames that normally do not return an AAAA record should now return a “fake” one with a value within the configured range. If that’s not happening, first check your /etc/resolv.conf on your local machine to see if it points to the correct server
• NAT64 problems can be checked by running tcpdump on your gateway, especially on the nat64 tunnel interface

netsh， interface， ipv6

之后输入：

便可以将对应DNS服务器添加到“本地连接”了

下面是一种解决办法，供参考，一方面自己做个记录，另一方面希望能帮助其他人。

找到wp-includes文件夹的classes.php文件(注意,在最新wordpress中已经没有classes.php,是classer-wp.php,盲目升级会使以前的中文链接失效,应尽快修改,以免影响浏览和SEO(异泪修改于2.26-2011))。使用“PATH_INFO”作为关键字搜索，定位到154行，注释掉此行，并加入相应代码，如下：

使用“REQUEST_URI”为关键字搜索定位到160行，注释掉，加入相应代码，如下：

修改以上代码后,WordPress便支持中文链接了….

我们是世界首家提供公共IPv6 Email 的服务. 现在已经可以同时支持IPv6 IPv4
的邮件收发.

如果你申请使用后缀为ipv6china.com的邮箱，那么现在已经自动支持双网收发.
如果你使用的后缀为ipv6bbs.com的邮箱,需要稍后配置.

目前我们已经增加后缀为vp6.org的邮箱，这样短的域名也许你更喜欢使用.

如果你有什么好的建议，请直接联系我们：

Email: info@ipv6china.com
QQ:9371121
www.xiaoyu.net

预祝你们圣诞快乐.  稍后我们将建立邮件列表方便大家交流.

2011.12.23

管理员：小鱼虾

Problem

You’re sitting in an airport or in a cafe, and people want your money for Internet access. They do allow DNS traffic, though.

If the ISP allows DNS traffic to any DNS server (and not just their own), you might consider running OpenVPN on UDP port 53 (thanks to Norman Rasmussen for this suggestion). If they don’t, however, NSTX comes to the rescue. NSTX is a hack to tunnel IP traffic over DNS. NSTX (IP-over-DNS) seems cool, but you cannot get it to work. You’ve downloaded the latest version, maybe because you saw it mentioned on Slashdot. You’ve looked at the nstx project page and the freshmeat page. You even tried reading some confusing documentation. Maybe you gave up and tried OzymanDNS. But curiousity got the better of you. You really want to use this.

Once you’ve followed these instructions, you basically have a remote proxy, providing you with access to the Internet. Communication between you and the remote proxy is over NSTX.

If DNS traffic does not work, but ICMP traffic (i.e., ping) works, try ICMPTX: IP-over-ICMP. Note that these instructions play nicely with ICMPTX. You can run both on one proxy.

Keywords

nstx, ip-over-DNS, tunnel, firewall piercing, ifconfig, route, tun/tap, tun0.

Solution

You need several things to get going:

• a DNS server that you can configure, (we’ll call this ns.example.com)
• another server, one not running DNS. We’re going to assume the IP address of this machine is 1.2.3.4. The reason you cannot run DNS on the same machine, is that you’re going to run nstx on this machine. Nstx must run on port 53, like DNS.
• a crippled Internet connection, i.e., one that only allows you to issue DNS queries.

Configure a new DNS subdomain

Let’s assume you’re running the domain “example.com”. The nameserver for this domain is, as mentioned before, “ns.example.com”. Configure “ns.example.com” by adding a subdomain, “tunnel.example.com”. You do this by appending the following DNS records at the end of the zone file for “example.com”:

;
; subdomain for IP-over-DNS tunnelling
;
$ORIGIN tunnel.example.com.
@               IN      NS      ns.tunnel.example.com.
ns              IN      A       1.2.3.4

In other words. We configured 1.2.3.4 to be the name server for a new subdomain “tunnel.example.com”.

Install and configure the bogus DNS server

On the machine 1.2.3.4, make sure your kernel supports the TUN/TAP network device. If you installed a standard 2.6 kernel image, it does. You may have to manually /sbin/modprobe tun. Install the nstx Debian package:

# apt-get install nstx

Edit /etc/default/nstx and set NSTX_DOMAIN to “tunnel.example.com” and set start_nstxd to “yes”. Finally, set ifup_tun0 to “yes”. In /etc/network/interfaces, define a new interface tun0, as follows:

iface tun0 inet static
  address 10.0.0.1
  netmask 255.0.0.0

Now start the server by running:

# /etc/init.d/nstxd restart

If you’re not running Debian, you can skip all that and just download the code, compile it manually, and start the server by hand and then configure the tun0 network device:

# nstxd tunnel.example.com
# /sbin/modprobe tun
# /sbin/ifconfig tun0 up 10.0.0.1 netmask 255.255.255.0

Whether you’re running Debian or not, after running the nstx server, make sure you now have a tun0 device:

# /sbin/ifconfig tun0
tun0      Link encap:UNSPEC  HWaddr XX-XX-XX-XX-XX-XX-XX-XX-XX-XX-XX-XX-XX-XX-XX-XX
          inet addr:10.0.0.1  P-t-P:10.0.0.1  Mask:255.0.0.0
          UP POINTOPOINT RUNNING NOARP MULTICAST  MTU:1500  Metric:1
          RX packets:50 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:10
          RX bytes:0 (0.0 b)  TX bytes:0 (0.0 b)

Now you need to enable forwarding on this server. I use iptables to implement masquerading. There are many HOWTOs about this (a simple one, for example). On Debian, the configuration file for iptables is in /var/lib/iptables/active. The relevant bit is:

*nat
  REROUTING ACCEPT [6:1596]
  OSTROUTING ACCEPT [1:76]
:OUTPUT ACCEPT [1:76]

-A POSTROUTING -s 10.0.0.0/8 -j MASQUERADE
COMMIT

Restart iptables:

/etc/init.d/iptables restart

and enable forwarding:

echo 1 > /proc/sys/net/ipv4/ip_forward

You can make sure this is permanent by editing /etc/sysctl.conf:

net/ipv4/ip_forward=1

Configure the client

Make sure the kernel on the client machine also supports the TUN/TAP network device. If you installed a standard 2.6 kernel image, it does. You may have to manually /sbin/modprobe tun. Install the nstx Debian package:

# apt-get install nstx

Edit /etc/default/nstx and set NSTX_DOMAIN to “tunnel.example.com” and set start_nstxcd to “yes”. Finally, set ifup_tun0 to “yes”. In /etc/network/interfaces, define a new interface tun0, as follows:

iface tun0 inet static
  address 10.0.0.2
  netmask 255.0.0.0
  mtu 500 # optional, may solve ssh problems

Marc Merlin points out that you may you want to add something like (below the mtu line)

  post-up route del default; route add -net default gw 10.0.0.1

Many thanks to Marc, also for pointing out the mtu option to solve potential ssh issues.

Alright, now you’re sitting at an airport or in a cafe, and you have internet access and they want your money before allowing you on the Internet. However, you noticed that you can issue DNS queries.

Assuming you got an IP address through DHCP, you should now know the IP address of the DNS server they want you to use. Your /etc/resolv.conf will contain at least one “nameserver” entry. Make sure you use the first nameserver entry in /etc/resolv.conf and remove the others. For the sake of this example, let’s call the first and remaining nameserver 66.77.88.99. Edit /etc/default/nstx and change set NSTX_DNS_SERVER to “66.77.88.99″. The latest nstx Debian package obviates this manual step as follows:

NSTX_DNS_SERVER=`grep nameserver /etc/resolv.conf |head -1|awk '{print $2}'`

That is, it simply sets NSTX_DNS_SERVER to the IP address of the first nameserver entry in/etc/resolv.conf.

Now, (re)start the nstx client:

# /etc/init.d/nstxcd restart

If you don’t have Debian, start the client manually:

# nstxcd tunnel.example.com 66.77.88.99
# /sbin/modprobe tun
# /sbin/ifconfig tun0 up 10.0.0.2 netmask 255.255.255.0

Make sure you now have a tun0 device:

# /sbin/ifconfig tun0
tun0      Link encap:UNSPEC  HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
          inet addr:10.0.0.2  P-t-P:10.0.0.2  Mask:255.0.0.0
          UP POINTOPOINT RUNNING NOARP MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:500
          RX bytes:0 (0.0 b)  TX bytes:0 (0.0 b)

By running /sbin/route -n, figure out what your gateway is. It’s the record with the “UG” Flags field. For example:

# /sbin/route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
192.168.1.0     0.0.0.0         255.255.255.0   U     0      0        0 wlan0
0.0.0.0         192.168.1.1     0.0.0.0         UG    0      0        0 wlan0

OK. So “192.168.1.1″ is our gateway. Assuming your wireless network device is called “wlan0″ (but it might well be “eth1″, or whatever), run:

# /sbin/route del default
# /sbin/route add -host 66.77.88.99 gw 192.168.1.1 dev wlan0
# /sbin/route add default gw 10.0.0.1 tun0

Notice that “192.168.1.1″ is the IP address of the gateway we learned by running “/sbin/route -n”. Similarly, “66.77.88.99″ is the nameserver from /etc/resolv.conf. Make sure you plug in the correct IP address in both cases.

You should now be all set. All DNS traffic is going straight to 66.77.88.99. All other traffic will be tunnelled through 1.2.3.4, via DNS.

iodine lets you tunnel IPv4 data through a DNS server. This can be usable in different situations where internet access is firewalled, but DNS queries are allowed. 

It runs on Linux, Mac OS X, FreeBSD, NetBSD, OpenBSD and Windows and needs a TUN/TAP device. The bandwidth is asymmetrical with limited upstream and up to 1 Mbit/s downstream. 

Compared to other DNS tunnel implementations, iodine offers:
Higher performance
iodine uses the NULL type that allows the downstream data to be sent without encoding. Each DNS reply can contain over a kilobyte of compressed payload data.
Portability
iodine runs on many different UNIX-like systems as well as on Win32. Tunnels can be set up between two hosts no matter their endianness or operating system.
Security
iodine uses challenge-response login secured by MD5 hash. It also filters out any packets not coming from the IP used when logging in.
Less setup
iodine handles setting IP number on interfaces automatically, and up to 16 users can share one server at the same time. Packet size is automatically probed for maximum downstream throughput.
See the README, the CHANGELOG and the man page 

Wiki, bug tracker, source browser and more is available at our trac page. iodine is released under the ISC license. 

Test your DNS setup here: http://code.kryo.se/iodine/check-it/ 

We have a mailing list: iodine-users at lists.wpkg.org. You can send to it without joining. Archive is at: http://lists.wpkg.org/mailman/listinfo/iodine-users. Thanks to Tomasz Chmielewski for hosting it. 

We are probably idling in #iodine on ircnet if you want to talk. However, please dont just ask a question and leave if you get no reply for 2 minutes, it may take some time before we see it.

iodine-0.6.0-rc1-win32

http://dnstunnel.de/

Did you ever sit at the airport or at a cafe and there was a unencrypted wireless access point nearby, but whenever you wanted to visit a site their website would pop up asking for a fee to use the internet through their AccessPoint (aka. Captive Portal)?

Well, I did, several times. But in most cases you are able to look up arbitrary hostnames, ie. google.com. That is because if you cannot resolve a host name your browser won't display any site. So these providers usually allow to look up hostnames to then filter whether they are allowed to access the site or not. In the latter case, their pay-to-get-access site pops up.

But you can use the fact that you can resolve arbitrary hostnames to gain free connection to the internet. Not a very fast one, though, but still a free internet connection.

The Idea

The Idea is to tunnel all outgoing traffic through DNS. Yes, you heard right, through DNS, the Domain Name System, used to translate human-readable hostnames to numerical IP addresses and vice versa.

To understand how this'll work, you need a little knowledge of DNS. The DNS system has quite a lot of so-called types of records, such as A for address record, NS for nameserver record, CNAME for canonical name record etc. The most commonly used record is the A record. To let the hostname example.com point to 192.0.34.166 you'd set up the following in your DNS server's config:

example.com.    IN  A   192.0.34.166
Usually, such entries are stored at your provider's nameserver and you don't have any/full control over them (most likely if you bought a rather cheap webhosting package). But to allow DNS tunneling to work, there has to be a little bit more advanced setup.

What we'll do is delegate all requests to a certain subdomain (or, subzone) to another nameserver. That means: People want to look up your IP, get to your ISP's nameserver and will be redirected to your own nameserver which can then answer the request. For this, of course, you'll need a server running the client where you can become root.

Keep in mind: All requests to a certain subdomain are relayed to your host, which then answers them. And you won't look up ordinary hostnames, I tell you. Hope you got the idea.

Technical Setup

To delegate all requests to sub.example.com to ns.anothernameserver.com, you first have to delegate all requests to that server (NS record, line 1) and then send a so-called GLUE record (that is, glued to the record before because it's most likely the asking server will need this info as well) with your server's IP (line 2, A record).

sub.example.com.              IN      NS      ns.anothernameserver.com.
ns.anothernameserver.com.     IN      A       192.0.34.166
If you just have a DynDNS account and no static IP, you'd set up the delegation using a CNAME record. As mentioned above, CNAME is a canonical name (speak: an alias). So when a server gets back a CNAME instead of an A record (IP address) he continues to look up this hostname. That brings us to the following:

sub.example.com.              IN      NS      ns.extern.example.com.
ns.extern.example.com.        IN      CNAME   foo.bar.dyndns.org.
The Fake Server

The fake server you can set up at your server to tunnel all the traffic through is a little program called OzymanDNS, written in Perl (Client and Server together 642 SLOC) by DNS guru Dan Kaminsky. 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:

Add a sshdns. in front of the hostname you specified the server to listen to and
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 How to Tunnel Everything through SSH.

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):

ntez375sy2qk7jsg2og3eswo2jujscb3r43as6m6hl2ws
xobm7h2olu4tmaq.lyazbf2e2rdynrd3fldvdy2w3tifi
gy2csrx3cqczxyhnxygor72a7fx47uo.nwqy4oa3v5rx6
6b4aek5krzkdm5btgz6jbiwd57ubnohnknpcuybg7py.6
3026-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
"AAAAlAgfAAAAgQDKrd3sFmf8aLX6FdU8ThUy3SRWGhotR6EsAavqHgBzH2khqsQHQjEf355jS7cT
G+4a8kAmFVQ4mpEEJeBE6IyDWbAQ9a0rgOKcsaWwJ7GdngGm9jpvReXX7S/2oqAIUFCn0M8="
"MHw9tR0kkDVZB7RCfCOpjfHrir7yuiCbt7FpyX8AAAABBQAAAAAAAAAA"
That is, in rough outlines, how tunneling via DNS works.

Security Issues

There are a few security issues you'll have to think about before letting the server run permanently:

As soon as some people guess which subdomain you use to tunnel DNS they can send arbitrary commands to the server. I haven't reviewed the code for too long, but there might be the possiblity of a bug which could be exploited to gain access to your system. But that ist just a unlikely hypothesis.
The software still is very experimental and crashes every now and then (see below for a workaround).
Consider that the server puts a high load on your system while actively surfing.
I own a Server but my ISP doesn't allow me to change (the relevant) DNS settings

Well, that is the reason I created this website. I offer to set up a subdomain for you which delegates all requests (see above) to your fake nameserver.I cannot handle the mass of requests coming in; doing the communication and (manually!) setting up the records is just too much.

Therefore, I advise you to check at free DNS providers first, for example:

http://free.editdns.net/

http://freedns.afraid.org/

If you're willing to pay a little money (like 5 EUR) you could just as well register a domain name at INWX, which is the provider I use for hosting the DNS of this domain.

If you have no whatsoever means to do the setup on your own write me an email at <request AT dnstunnel.de>. You should include your full name, your server's static IP or DynDNS hostname and the desired subdomain name (name.dnstunnel.de; I encourage you to keep this secret for your own security). Be prepared to wait a few days or even weeks until I get around to setting up the records!

Legal Warning

Circumventing the AP's access controls (that includes DNS tunneling) is most probably considered to be a crime, depending on the country you live in. I am not responsible for whatever you do with your tunnel. I am just providing two simple entries in my ISP's DNS server to let a hostname point to your server's IP.

Helper Script

Here are two little helper scripts that'll allow you to automatically start OzymanDNS on system boot through initd. This is my /etc/init.d/ozymandns file:

#!/bin/sh
# Written by Julius Plenz

set -e

case "$1" in
  start)
    echo -n "Starting ozymandns listener..."
    screen -d -m /usr/local/bin/ozymandns-listener
    echo "."
    ;;
  stop)
    echo -n "Stopping ozymandns listener..."
    kill `cat /var/run/ozymandns.pid`
    echo "."
      ;;
  restart)
    /etc/init.d/ozymandns stop
    /etc/init.d/ozymandns start
    ;;
  reload|force-reload)
    echo "cannot do that"
    echo "."
    ;;
  *)
    echo "Usage: /etc/init.d/$NAME {start|stop|restart}"
    exit 1
    ;;
esac

exit 0
Of course, you'll have to make the script executable. Then I'd suggest to put two links to automatically start and terminate the server on bootup/shutdown:

~# cd /etc/rc0.d/; ln -s ../init.d/ozymandns K15ozymandns
~# cd /etc/rc2.d/; ln -s ../init.d/ozymandns S99ozymandns
The program called from the init script (/usr/local/bin/ozymandns-listener) looks like this:

#!/bin/sh

REPLYIP=0.0.0.0
DNSHOST=name.dnstunnel.de

echo $$ > /var/run/ozymandns.pid

while [[ -e /var/run/ozymandns.pid ]] ; do
    cd /usr/local/bin/
    nomde.pl -i $REPLYIP $DNSHOST >/dev/null 2>&1
done
Note: This script again assumes you have installed the nomde.pl server in /usr/local/bin/ as well.

Example Video

I made an example video: DNS Tunneling Example Video (1:30, 20MB)

Documentation

There are a few other documents on the net explaining how DNS tunneling works. Some of these documents describe how DNS tunneling works with nstx, which is a different application, but basically also does the same as OzymanDNS.

Quick tunneling IP over DNS guide at digitalsec.es
NSTX (IP-over-DNS) HOWTO at thomer.com
Public Access to TOR via DNS at afs.eecs.harvard.edu
PPP over SSH over DNS Howto at ecs.soton.ac.uk
Dan Kaminsky's PowerPoint Slides at doxpara.com
Counter-measurements against DNS tunneling at daemon.be/maarten

2006-2011 Julius Plenz <julius * dnstunnel.de>

Google DNS
Primary: 8.8.8.8
Secondary: 8.8.4.4

Australia

QLD
144.140.70.29
144.140.71.15
144.140.70.16

Westnet (ADSL)
203.21.20.20
203.10.1.9

Canada

Shaw Cable
64.59.144.16
64.59.144.17

Telus(BC)
154.11.128.129
154.11.128.150
154.11.128.1
154.11.128.2
154.11.128.130
209.53.4.150

China

I-Cable
(Hong Kong)
210.80.60.1
210.80.60.2

Italy

Alice
212.216.112.112
212.216.172.62

Malaysia

Schoolnet (ADSL)
202.75.44.18
203.106.3.171
202.75.44.20

Tmnet Streamyx (ADSL)
202.188.0.132
202.188.0.133
202.188.0.147
202.188.0.161
202.188.0.181
202.188.0.182
202.188.1.4
202.188.1.5
202.188.1.23
202.188.1.25

Mexico

Cablemas (Cable 128kbps)
69.44.143.245
200.79.192.3

Nederland
Hetnet
10.0.0.5
10.0.0.2
10.0.0.3

Planet Internet
195.121.1.34
195.121.1.66

New Zealand

Xtra (DSL)
202.27.158.40
202.27.156.72

Paradise (DSL)
203.96.152.4
203.96.152.12

Portugal

Netvisão (Cable)
213.228.128.6
213.228.128.5

TVTel
195.22.0.204
195.22.0.205

Sweden

Tele2
130.244.127.161
130.244.127.169

United Kingdom

AOL
205.188.146.145

Blueyonder/Telewest (Cable)
193.38.113.3
194.177.157.4

BTInternet
194.73.73.172
194.73.73.173
194.72.9.44
194.72.9.38 (Cardiff, S.Wales)
194.72.9.39 (Cardiff, S.Wales)

Bulldog Broadband
Ns3.bulldogdsl.com . 83.146.21.5 (South)
Ns4.bulldogdsl.com . 83.146.21.6 (South)
Ns5.bulldogdsl.com . 212.158.248.5 (North)
Ns6.bulldogdsl.com . 212.158.248.6 (North)

Nildram (ADSL)
213.208.106.212
213.208.106.213

NTL (Cable) and Virgin.net (ADSL)
194.168.4.100
194.168.8.100

Pipex (ADSL)
62.241.162.35
62.189.34.83

Silvermead (Satellite, DSL, ISDN)
62.55.96.226
62.55.96.109 (unchecked)

Telewest (Cable)
62.31.176.39
194.117.134.19

Tiscali, Screaming.net, Worldonline, Lineone
212.74.112.66
212.74.112.67
212.74.114.129 (Cambridge)
212.74.114.193 (Cambridge)

Wanadoo UK (ADSL)
195.92.195.94
195.92.195.95

Zen Internet
Primary DNS: 212.23.8.1
Secondary DNS: 212.23.3.1

United States of America

Adelphia
67.21.13.4 Los Angeles, CA
67.21.13.2 Los Angeles, CA
24.48.217.226 Santa Monica, CA
24.48.217.227 Santa Monica, CA
68.168.1.42 Florida
68.168.1.46 Florida

Bellsouth Fast access DSL:
Georgia
205.152.37.23
205.152.37.24
205.152.37.25
205.152.144.24
205.152.144.25

Charter Comms (Cable)
68.116.46.70

Comcast (pick the nearest!)
68.87.66.196 Comcast (national) Primary DNS Server.
68.87.64.196 Comcast Secondary DNS Server.
68.57.32.5 (Virginia)
68.57.32.6 (Virginia)
216.148.227.68 (Denver, Colorado)
204.127.202.4 (Denver, Colorado)
68.42.244.5 (Taylor, Michigan)
68.42.244.6 (Taylor, Michigan)
68.62.160.5 (Huntsville, Alabama)
68.62.160.6 (Huntsville, Alabama)
68.87.96.3 (Pennsylvania)
68.87.96.4 (Pennsylvania)

Cox HSI (Cable)
68.12.16.25 (Oklahoma – Primary)
68.12.16.30 (Oklahoma – Secondary)
68.2.16.30 (Oklahoma – Tertiary)

Cox.net
68.10.16.25
68.10.16.30
68.9.16.30

Earthlink – seem to be shared by Cable and DSL users in several states. Georgia and Florida confirmed.
207.69.188.187
207.69.188.186
207.69.188.185
209.86.63.217 (Cable) – Charlotte, NC

Harrisonville Telephone Company (HTC)
216.114.114.130 (Illinois)
216.114.114.132 (Illinois)

Horry Telephone Coop
66.153.128.98 (Horry County, South Carolina)
66.153.162.98 (Horry County, South Carolina)

ORSC Public Access DNS Nameservers (Anyone can use these, no matter what ISP)
199.166.24.253
199.166.27.253
199.166.28.10
199.166.29.3
199.166.31.3
195.117.6.25
204.57.55.100

Roadrunner (Cable)
24.25.195.1 (San Diego, CA)
24.25.195.2 (San Diego, CA)
24.25.195.3 (San Diego, CA)

SBC Yahoo DSL
206.13.31.13
206.13.28.60
206.13.31.5
206.13.28.31

Speakeasy (pick any two!)
66.93.87.2 (Washington state and Oregon)
216.231.41.2 (Washington DC – probably)
216.254.95.2 (NY, Massachusetts and Pennsylvania)
64.81.45.2 (Los Angeles, California)
64.81.111.2 (Denver, Colorado)
64.81.127.2 (Dallas, Texas)
64.81.79.2 (Sacramento, California)
64.81.159.2 (Baltimore and Washington DC)
66.92.64.2 (Boston, Massachusetts)
66.92.224.2 (Philadelphia)
66.92.159.2 (Washington DC)
216.27.175.2 (Atlanta, Georgia. Serves Florida too)

Sprintlink (nationwide)
204.117.214.10
199.2.252.10
204.97.212.10

TimeWarner
24.93.1.119 (Rochester, NY)

Unicom
216.104.64.5 (Grants Pass, OR)
216.104.72.5 (Portland, OR)

FrontierNet / Citlink / New North DNS addresses:
66.133.170.2 (Rochester, NY)
170.215.255.114 (Rochester, NY)
216.67.192.3 (Arizona)
207.173.225.3 (Arizona)
207.173.225.3 (California)
216.67.192.3 (California)
170.215.255.114 (New York (areas other than Rochester))
66.133.170.2 (New York (areas other than Rochester))
170.215.184.3 (West Virginia)
170.215.126.3 (West Virginia)
170.215.126.3 (Tennessee, Georgia)
170.215.184.3 (Tennessee, Georgia)
67.50.135.146 (Illinois)
66.133.191.35 (Illinois)
66.133.191.35 (Wisconsin, Minnesota, Iowa, North Dakota and Nebraska)
170.215.255.114 (Wisconsin, Minnesota, Iowa, North Dakota and Nebraska)

Suddenlink DNS Numbers
209.55.0.110
209.55.1.220
Verizon (Level3) – these are not restricted to Verizon customers
4.2.2.1
4.2.2.2
4.2.2.3
4.2.2.4
4.2.2.5
4.2.2.6

Wave Broadband
24.113.32.29
24.113.32.30

156.154.70.1
156.154.71.1

An APK file is an archive that usually contains the following folders:

• META-INF
• res

and files:

• AndroidManifest.xml
• classes.dex
• resources.arsc

An .apk file can be opened and inspected using common archive tools such as 7-Zip, Winzip, Winrar and Ark.

The MIME media type for .apk is application/vnd.android.package-archive.^[3]

[edit] References