[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"project-6333":3},{"id":4,"name":5,"fullName":6,"owner":7,"repo":5,"description":8,"homepage":9,"htmlUrl":10,"language":11,"languages":10,"totalLinesOfCode":10,"stars":12,"forks":13,"watchers":14,"openIssues":15,"contributorsCount":16,"subscribersCount":16,"size":16,"stars1d":17,"stars7d":18,"stars30d":19,"stars90d":16,"forks30d":16,"starsTrendScore":20,"compositeScore":21,"rankGlobal":10,"rankLanguage":10,"license":22,"archived":23,"fork":23,"defaultBranch":24,"hasWiki":23,"hasPages":23,"topics":25,"createdAt":10,"pushedAt":10,"updatedAt":31,"readmeContent":32,"aiSummary":33,"trendingCount":16,"starSnapshotCount":16,"syncStatus":34,"lastSyncTime":35,"discoverSource":36},6333,"iodine","yarrick\u002Fiodine","yarrick","Official git repo for iodine dns tunnel","https:\u002F\u002Fcode.kryo.se\u002Fiodine",null,"C",7898,595,125,14,0,1,11,48,4,39.33,"ISC License",false,"master",[26,27,28,5,29,30],"dns","dns-tunnel","hacktoberfest","tunnel","vpn","2026-06-12 02:01:18","iodine - \u003Chttps:\u002F\u002Fcode.kryo.se\u002Fiodine>\n=====================================\n\n\nThis is a piece of software that lets you tunnel IPv4 data through a DNS\nserver. This can be usable in different situations where internet access is\nfirewalled, but DNS queries are allowed.\n\n\nCOMPILING\n---------\n\nIodine has no configure script. There are two optional features for Linux\n(SELinux and systemd support) that will be enabled automatically if the\nrelevant header files are found in `\u002Fusr\u002Finclude`.\n(See script at `.\u002Fsrc\u002Fosflags`)\n\nRun `make` to compile the server and client binaries.\nRun `make install` to copy binaries and manpage to the destination directory.\nRun `make test` to compile and run the unit tests. (Requires the `check` library)\n\n\nQUICKSTART\n----------\n\nTry it out within your own LAN! Follow these simple steps:\n- On your server, run: `.\u002Fiodined -f 10.0.0.1 test.com`.\n  If you already use the `10.0.0.0` network, use another internal net like\n  `172.16.0.0`.\n- Enter a password.\n- On the client, run: `.\u002Fiodine -f -r 192.168.0.1 test.com`.\n  Replace `192.168.0.1` with your server's ip address.\n- Enter the same password.\n- Now the client has the tunnel ip `10.0.0.2` and the server has `10.0.0.1`.\n- Try pinging each other through the tunnel.\n- Done! :)\n\nTo actually use it through a relaying nameserver, see below.\n\n\nHOW TO USE\n----------\n\nNote: server and client are required to speak the exact same protocol. In most\ncases, this means running the same iodine version. Unfortunately, implementing\nbackward and forward protocol compatibility is usually not feasible.\n\n### Server side\nTo use this tunnel, you need control over a real domain (like `mydomain.com`),\nand a server with a public IP address to run `iodined` on. If this server\nalready runs a DNS program, change its listening port and then use `iodined`'s\n`-b` option to let `iodined` forward the DNS requests. (Note that this procedure\nis not advised in production environments, because `iodined`'s DNS forwarding\nis not completely transparent, for example zone transfers will not work.)\nAlternatively you can forward the subdomain from your DNS server to `iodined`\nwhich must then run on a different port (`-p`).\n\nThen, delegate a subdomain (say, `t1.mydomain.com`) to the iodined server.\nIf you use BIND for your domain, add two lines like these to the zone file:\n\n\tt1\t\tIN\tNS\tt1ns.mydomain.com.\t\t; note the dot!\n\tt1ns\t\tIN\tA\t10.15.213.99\n\nThe `NS` line is all that's needed to route queries for the `t1` subdomain\nto the `t1ns` server. We use a short name for the subdomain, to keep as much\nspace as possible available for the data traffic. At the end of the `NS` line\nis the name of your `iodined` server. This can be any name, pointing anywhere,\nbut in this case it's easily kept in the same zone file. It must be a name\n(not an IP address), and that name itself must have an `A` record\n(not a `CNAME`).\n\nIf your `iodined` server has a dynamic IP, use a dynamic DNS provider. Simply\npoint the `NS` line to it, and leave the `A` line out:\n\n\tt1\t\tIN\tNS\tmyname.mydyndnsprovider.com.\t; note the dot!\n\nThen reload or restart your nameserver program. Now any DNS queries for\ndomains ending in `t1.mydomain.com` will be sent to your `iodined` server.\n\nFinally start `iodined` on your server. The first argument is the IP address\ninside the tunnel, which can be from any range that you don't use yet (for\nexample `192.168.99.1`), and the second argument is the assigned domain (in this\ncase `t1.mydomain.com`). Using the `-f` option will keep iodined running in the\nforeground, which helps when testing. iodined will open a virtual interface\n(\"tun device\"), and will also start listening for DNS queries on UDP port 53.\nEither enter a password on the commandline (`-P pass`) or after the server has\nstarted. Now everything is ready for the client.\n\nIf there is a chance you'll be using an iodine tunnel from unexpected\nenvironments, start `iodined` with a `-c` option.\nResulting commandline in this example situation:\n\n\t.\u002Fiodined -f -c -P secretpassword 192.168.99.1 t1.mydomain.com\n\n### Client side\nAll the setup is done, just start `iodine`. It takes one or two arguments, the\nfirst is the local relaying DNS server (optional) and the second is the domain\nyou used (`t1.mydomain.com`). If you don't specify the first argument, the\nsystem's current DNS setting will be consulted.\n\nIf DNS queries are allowed to any computer, you can directly give the `iodined`\nserver's address as first argument (in the example: `t1ns.mydomain.com` or\n`10.15.213.99`). In that case, it may also happen that _any_ traffic is allowed\nto the DNS port (53 UDP) of any computer. Iodine will detect this, and switch\nto raw UDP tunneling if possible. To force DNS tunneling in any case, use the\n`-r` option (especially useful when testing within your own network).\n\nThe client's tunnel interface will get an IP close to the server's (in this\ncase `192.168.99.2` or `.3` etc.) and a suitable MTU. Enter the same password as\non the server either as commandline option or after the client has started.\nUsing the `-f` option will keep the iodine client running in the foreground.\n\nResulting commandline in this example situation, adding -r forces DNS tunneling\neven if raw UDP tunneling would be possible:\n\n\t.\u002Fiodine -f -P secretpassword t1.mydomain.com\n\nFrom either side, you should now be able to ping the IP address on the other\nend of the tunnel. In this case, `ping 192.168.99.1` from the iodine client, and\n`192.168.99.2` from the iodine server.\n\n\n### MISC. INFO\n\n#### IPv6\nThe data inside the tunnel is IPv4 only.\n\nThe server listens to both IPv4 and IPv6 for incoming requests by default.\nUse options `-4` or `-6` to only listen on one protocol. Raw mode will be\nattempted on the same protocol as used for the login.\n\nThe client can use IPv4 or IPv6 nameservers to connect to iodined. The relay\nnameservers will translate between protocols automatically if needed. Use\noptions `-4` or `-6` to force the client to use a specific IP version for its DNS\nqueries.\n\nIf your server is listening on IPv6 and is reachable, add an AAAA record for it\nto your DNS setup. Extending the example above would look like this:\n\n\tt1\t\tIN\tNS\tt1ns.mydomain.com.\t\t; note the dot!\n\tt1ns\t\tIN\tA\t10.15.213.99\n\tt1ns\t\tIN\tAAAA\t2001:db8::1001:99\n\n#### Routing\nIt is possible to route all traffic through the DNS tunnel. To do this, first\nadd a host route to the nameserver used by iodine over the wired\u002Fwireless\ninterface with the default gateway as gateway. Then replace the default\ngateway with the iodined server's IP address inside the DNS tunnel, and\nconfigure the server to do NAT.\n\nHowever, note that the tunneled data traffic is not encrypted at all, and can\nbe read and changed by external parties relatively easily. For maximum\nsecurity, run a VPN through the DNS tunnel (=double tunneling), or use secure\nshell (SSH) access, possibly with port forwarding. The latter can also be used\nfor web browsing, when you run a web proxy (for example Privoxy) on your\nserver.\n\n#### Testing\nThe `iodined` server replies to `NS` requests sent for subdomains of the tunnel\ndomain. If your iodined subdomain is `t1.mydomain.com`, send a `NS` request for\n`foo123.t1.mydomain.com` to see if the delegation works.\n`dig` is a good tool for this:\n\n\t% dig -t NS foo123.t1.mydomain.com\n\tns.io.citronna.de.\n\nAlso, the iodined server will answer requests starting with 'z' for any of the\nsupported request types, for example:\n\n\tdig -t TXT z456.t1.mydomain.com\n\tdig -t SRV z456.t1.mydomain.com\n\tdig -t CNAME z456.t1.mydomain.com\n\nThe reply should look like garbled text in all these cases.\n\n#### Mac OS X\nOn Mac OS X 10.6 and later, iodine supports the native utun devices built into\nthe OS - use `-d utunX`.\n\n\nOperational info\n----------------\n\nThe DNS-response fragment size is normally autoprobed to get maximum bandwidth.\nTo force a specific value (and speed things up), use the `-m` option.\n\nThe DNS hostnames are normally used up to their maximum length, 255 characters.\nSome DNS relays have been found that answer full-length queries rather\nunreliably, giving widely varying (and mostly very bad) results of the\nfragment size autoprobe on repeated tries. In these cases, use the `-M` switch\nto reduce the DNS hostname length to, for example 200 characters, which makes\nthese DNS relays much more stable. This is also useful on some “de-optimizing”\nDNS relays that stuff the response with two full copies of the query, leaving\nvery little space for downstream data (also not capable of EDNS0). The `-M`\nswitch can trade some upstream bandwidth for downstream bandwidth. Note that\nthe minimum `-M` value is about 100, since the protocol can split packets (1200\nbytes max) in only 16 fragments, requiring at least 75 real data bytes per\nfragment.\n\nThe upstream data is sent gzipped encoded with Base32; or Base64 if the relay\nserver supports mixed case and `+` in domain names; or Base64u if `_` is\nsupported instead; or Base128 if high-byte-value characters are supported.\nThis upstream encoding is autodetected. The DNS protocol allows one query per\npacket, and one query can be max 256 chars. Each domain name part can be max\n63 chars. So your domain name and subdomain should be as short as possible to\nallow maximum upstream throughput.\n\nSeveral DNS request types are supported, with the `NULL` and `PRIVATE` types\nexpected to provide the largest downstream bandwidth. The `PRIVATE` type uses\nvalue 65399 in the private-use range. Other available types are `TXT`, `SRV`,\n`MX`, `CNAME` and `A` (returning `CNAME`), in decreasing bandwidth order.\nNormally the “best” request type is autodetected and used. However, DNS relays\nmay impose limits on for example NULL and TXT, making SRV or MX actually the best\nchoice. This is not autodetected, but can be forced using the `-T` option.\nIt is advisable to try various alternatives especially when the autodetected\nrequest type provides a downstream fragment size of less than 200 bytes.\n\nNote that `SRV`, `MX` and `A` (returning `CNAME`) queries may\u002Fwill cause\nadditional lookups by \"smart\" caching nameservers to get an actual IP address,\nwhich may either slow down or fail completely.\n\nDNS responses for non-`NULL\u002FPRIVATE` queries can be encoded with the same set of\ncodecs as upstream data. This is normally also autodetected, but no fully\nexhaustive tests are done, so some problems may not be noticed when selecting\nmore advanced codecs. In that case, you'll see failures\u002Fcorruption in the\nfragment size autoprobe. In particular, several DNS relays have been found that\nchange replies returning hostnames (`SRV`, `MX`, `CNAME`, `A`) to lowercase only\nwhen that hostname exceeds ca. 180 characters. In these and similar cases, use\nthe `-O` option to try other downstream codecs; Base32 should always work.\n\nNormal operation now is for the server to _not_ answer a DNS request until\nthe next DNS request has come in, a.k.a. being “lazy”. This way, the server\nwill always have a DNS request handy when new downstream data has to be sent.\nThis greatly improves (interactive) performance and latency, and allows to\nslow down the quiescent ping requests to 4 second intervals by default, and\npossibly much slower. In fact, the main purpose of the pings now is to force\na reply to the previous ping, and prevent DNS server timeouts (usually at\nleast 5-10 seconds per RFC1035). Some DNS servers are more impatient and will\ngive SERVFAIL errors (timeouts) in periods without tunneled data traffic. All\ndata should still get through in these cases, but `iodine` will reduce the ping\ninterval to 1 second anyway (-I1) to reduce the number of error messages. This\nmay not help for very impatient DNS relays like `dnsadvantage.com` (ultradns),\nwhich time out in 1 second or even less. Yet data will still get trough, and\nyou can ignore the `SERVFAIL` errors.\n\nIf you are running on a local network without any DNS server in-between, try\n`-I 50` (iodine and iodined close the connection after 60 seconds of silence).\nThe only time you'll notice a slowdown, is when DNS reply packets go missing;\nthe `iodined` server then has to wait for a new ping to re-send the data. You can\nspeed this up by generating some upstream traffic (keypress, ping). If this\nhappens often, check your network for bottlenecks and\u002For run with `-I1`.\n\nThe delayed answering in lazy mode will cause some “carrier grade” commercial\nDNS relays to repeatedly re-send the same DNS query to the iodined server.\nIf the DNS relay is actually implemented as a pool of parallel servers,\nduplicate requests may even arrive from multiple sources. This effect will\nonly be visible in the network traffic at the `iodined` server, and will not\naffect the client's connection. Iodined will notice these duplicates, and send\nthe same answer (when its time has come) to both the original query and the\nlatest duplicate. After that, the full answer is cached for a short while.\nDelayed duplicates that arrive at the server even later, get a reply that the\niodine client will ignore (if it ever arrives there).\n\nIf you have problems, try inspecting the traffic with network monitoring tools\nlike tcpdump or ethereal\u002Fwireshark, and make sure that the relaying DNS server\nhas not cached the response. A cached error message could mean that you\nstarted the client before the server. The `-D` (and `-DD`) option on the server\ncan also show received and sent queries.\n\n\nTIPS & TRICKS\n-------------\n\nIf your port 53 is taken on a specific interface by an application that does\nnot use it, use `-p` on iodined to specify an alternate port (like `-p 5353`)\nand use for instance iptables (on Linux) to forward the traffic:\n\n\tiptables -t nat -A PREROUTING -i eth0 -p udp --dport 53 -j DNAT --to :5353\n\n(Sent in by Tom Schouten)\n\nIodined will reject data from clients that have not been active (data\u002Fpings)\nfor more than 60 seconds. Similarly, iodine will exit when no downstream\ndata has been received for 60 seconds. In case of a long network outage or\nsimilar, just restart iodine (re-login), possibly multiple times until you get\nyour old IP address back. Once that's done, just wait a while, and you'll\neventually see the tunneled TCP traffic continue to flow from where it left\noff before the outage.\n\nWith the introduction of the downstream packet queue in the server, its memory\nusage has increased with several megabytes in the default configuration.\nFor use in low-memory environments (e.g. running on your DSL router), you can\ndecrease USERS and undefine OUTPACKETQ_LEN in user.h without any ill conse-\nquence, assuming at most one client will be connected at any time. A small\nDNSCACHE_LEN is still advised, preferably 2 or higher, however you can also\nundefine it to save a few more kilobytes.\n\nOne iodine server can handle multiple domains. Set up different NS records\non the same domain all pointing to the same host, and use a wildcard\nat the start of the topdomain argument (example `*.mydomain.com`). iodine\nwill accept tunnel traffic for all domains matching that pattern. The wildcard\nhas to be at the start of the topdomain argument and be followed by a dot.\n\n\nPERFORMANCE\n-----------\n\nThis section tabulates some performance measurements. To view properly, use\na fixed-width font like Courier.\n\nMeasurements were done in protocol 00000502 in lazy mode; upstream encoding\nalways Base128; `iodine -M255`; `iodined -m1130`. Network conditions were not\nextremely favorable; results are not benchmarks but a realistic indication of\nreal-world performance that can be expected in similar situations.\n\nUpstream\u002Fdownstream throughput was measured by `scp`'ing a file previously\nread from `\u002Fdev\u002Furandom` (i.e. incompressible), and measuring size with\n`ls -l ; sleep 30 ; ls -l` on a separate non-tunneled connection. Given the\nlarge `scp` block size of 16 kB, this gives a resolution of 4.3 kbit\u002Fs, which\nexplains why some values are exactly equal.\nPing round-trip times measured with `ping -c100`, presented are average rtt\nand mean deviation (indicating spread around the average), in milliseconds.\n\n\n### Situation 1: `Laptop  ->   Wifi AP   ->  Home server  ->  DSL provider  ->  Datacenter`\n\n\t iodine    DNS \"relay\"        bind9           DNS cache        iodined\n\n\t                        downstr.  upstream downstr.  ping-up       ping-down\n\t                        fragsize   kbit\u002Fs   kbit\u002Fs  avg +\u002F-mdev   avg +\u002F-mdev\n\t-----------------------------------------------------------------------------\n\n\tiodine -> Wifi AP :53\n\t  -Tnull (= -Oraw)           982    43.6    131.0   28.0    4.6   26.8    3.4\n\n\tiodine -> Home server :53\n\t  -Tnull (= -Oraw)          1174    48.0    305.8   26.6    5.0   26.9    8.4\n\n\tiodine -> DSL provider :53\n\t  -Tnull (= -Oraw)          1174    56.7    367.0   20.6    3.1   21.2    4.4\n\t  -Ttxt -Obase32             730    56.7    174.7*\n\t  -Ttxt -Obase64             874    56.7    174.7\n\t  -Ttxt -Obase128           1018    56.7    174.7\n\t  -Ttxt -Oraw               1162    56.7    358.2\n\t  -Tsrv -Obase128            910    56.7    174.7\n\t  -Tcname -Obase32           151    56.7     43.6\n\t  -Tcname -Obase128          212    56.7     52.4\n\n\tiodine -> DSL provider :53\n\t  wired (no Wifi) -Tnull    1174    74.2    585.4   20.2    5.6   19.6    3.4\n\n\t [174.7* : these all have 2frag\u002Fpacket]\n\n\n### Situation 2: `Laptop  ->  Wifi+vpn \u002F wired  ->  Home server`\n\n\t iodine                            iodined\n\n\t                        downstr.  upstream downstr.  ping-up       ping-down\n\t                        fragsize   kbit\u002Fs   kbit\u002Fs  avg +\u002F-mdev   avg +\u002F-mdev\n\t-----------------------------------------------------------------------------\n\n\twifi + openvpn  -Tnull      1186   166.0   1022.3    6.3    1.3    6.6    1.6\n\n\twired  -Tnull               1186   677.2   2464.1    1.3    0.2    1.3    0.1\n\n\n### Notes\n\nPerformance is strongly coupled to low ping times, as iodine requires\nconfirmation for every data fragment before moving on to the next. Allowing\nmultiple fragments in-flight like TCP could possibly increase performance,\nbut it would likely cause serious overload for the intermediary DNS servers.\nThe current protocol scales performance with DNS responsivity, since the\nDNS servers are on average handling at most one DNS request per client.\n\n\nPORTABILITY\n-----------\n\niodine has been tested on Linux (arm, ia64, x86, AMD64 and SPARC64), FreeBSD\n(ia64, x86), OpenBSD (x86), NetBSD (x86), MacOS X (ppc and x86, with\n\u003Chttp:\u002F\u002Ftuntaposx.sourceforge.net\u002F>). and Windows (with OpenVPN TAP32 driver, see\nwin32 readme file).  It should be easy to port to other unix-like systems that\nhave TUN\u002FTAP tunneling support. Let us know if you get it to run on other\nplatforms.\n\n\nTHE NAME\n--------\n\nThe name iodine was chosen since it starts with IOD (IP Over DNS) and since\niodine has atomic number 53, which happens to be the DNS port number.\n\n\nTHANKS\n------\n\n- To kuxien for FreeBSD and OS X testing\n- To poplix for code audit\n\n\nAUTHORS & LICENSE\n-----------------\n\nCopyright (c) 2006-2014 Erik Ekman \u003Cyarrick@kryo.se>, 2006-2009 Bjorn\nAndersson \u003Cflex@kryo.se>. Also major contributions by Anne Bezemer.\n\nPermission to use, copy, modify, and\u002For distribute this software for any purpose\nwith or without fee is hereby granted, provided that the above copyright notice\nand this permission notice appear in all copies.\n\nTHE SOFTWARE IS PROVIDED \"AS IS\" AND THE AUTHOR DISCLAIMS ALL WARRANTIES WITH\nREGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY AND\nFITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR ANY SPECIAL, DIRECT,\nINDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM\nLOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE OR\nOTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR\nPERFORMANCE OF THIS SOFTWARE.\n\n\nMD5 implementation by L. Peter Deutsch (license and source in `src\u002Fmd5.[ch]`)\nCopyright (C) 1999, 2000, 2002 Aladdin Enterprises.  All rights reserved.\n","iodine 是一个允许通过DNS服务器隧道传输IPv4数据的软件。它利用了即使在网络访问被防火墙限制的情况下，DNS查询通常仍被允许的特点来实现这一功能。该项目使用C语言编写，支持Linux平台下的SELinux和systemd特性，并且提供了简单的编译与安装指南。iodine特别适合在互联网访问受限但DNS查询未被阻止的环境中使用，例如某些企业或学校网络环境。用户可以通过控制一个真实域名并在具有公网IP地址的服务器上运行iodine服务端程序来搭建自己的隧道，从而绕过常规网络限制进行通信。",2,"2026-06-11 03:06:32","top_language"]