Difference between revisions of "DNS Tunneling"
(New page: A few years ago there was a proof-of-concept that it was possible to send and receive data packets over the Domain Name System (DNS). It utilizes the hostname for upstream data and the TXT...) |
|||
| Line 14: | Line 14: | ||
group.example.org. IN NS ns1.sample.org. | group.example.org. IN NS ns1.sample.org. | ||
The length of the entire hostname is limited to 255 octets/bytes [http://www.ops.ietf.org/lists/namedroppers/namedroppers.2003/msg00964.html]. And the TXT record has the same 255 bytes limit. | The length of the entire hostname is limited to 255 octets/bytes [http://www.ops.ietf.org/lists/namedroppers/namedroppers.2003/msg00964.html]. And the TXT record has the same 255 bytes limit. It's now somewhat apparent that it should be possible to transmit and receive data using the hostname and TXT records respectively, if a system or encoder/decoder is placed in each end. | ||
Now, this DNS tunnel is written in perl and includes a client and server. The server runs on port 53 and will answer DNS queries coming from the client (or anyone querying the hostname). A hostname has to be delegated to point to the server, e.g. the hostname of the server has to be the NS (record) for dtun.example.org. Thus forwarding, or delegating, any queries to *.dtun.example.org, e.g server.dtun.example.org, to the DNS tunnel server. | |||
== Delegate Zone == | == Delegate Zone == | ||
Revision as of 16:04, 28 July 2008
A few years ago there was a proof-of-concept that it was possible to send and receive data packets over the Domain Name System (DNS). It utilizes the hostname for upstream data and the TXT-field for downstream data, and s smart queuing system to split and order the packets. The speed is not good, but it opens an alternate way to connect to the Internet.
Technical Overview
The DNS system is hierarchy structured, beginning with the 13 root servers for top-level-domains (TLD) i.e., com, net, org, down to the domain name, i.e. example.org, and then sub-domains, i.e. group.example.org. Each sub-domain can be delegated to another domain server at a different location.
Each domain is configured in a zone file, each zone file contains different types of records, i.e. A for address record, CNAME for alias to an A record, MX for the mail exchange server, NS for the zone's name server, TXT for plain text description. The interesting records here is the NS and TXT records. Entries ending with a dot means end of domain, while no dot means add $ORIGIN to entry.
$ORIGIN example.org example.org. IN NS ns1.nameserver.com. example.org. IN A 192.168.1.99 example.org. IN TXT "Example.org sample domain" mx1 IN CNAME example.org. group.example.org. IN NS ns1.sample.org.
The length of the entire hostname is limited to 255 octets/bytes [1]. And the TXT record has the same 255 bytes limit. It's now somewhat apparent that it should be possible to transmit and receive data using the hostname and TXT records respectively, if a system or encoder/decoder is placed in each end.
Now, this DNS tunnel is written in perl and includes a client and server. The server runs on port 53 and will answer DNS queries coming from the client (or anyone querying the hostname). A hostname has to be delegated to point to the server, e.g. the hostname of the server has to be the NS (record) for dtun.example.org. Thus forwarding, or delegating, any queries to *.dtun.example.org, e.g server.dtun.example.org, to the DNS tunnel server.
Delegate Zone
dns-inet IN NS dns-inet-ns dns-inet-ns IN A 80.212.232.81
