Methodology & Requirements
Development approach
The project followed an iterative software-engineering methodology. The aim was to investigate and implement a proof of concept rather than produce a deployment-ready DNS tunneling application.
Development began with research into DNS, existing tunnels, and detection techniques. This established the main technical constraints: label and name lengths, the restricted hostname alphabet, and the relationship between encoding choices and detection indicators. Functional and non-functional requirements were then defined to guide the implementation.
The later phases covered software architecture, cryptographic design, encoding, implementation, and evaluation. Experimental methods made a strictly linear process unsuitable. Some phases were revisited as practical limits emerged, particularly the expansion of encoded ciphertext and the amount of payload that could fit in a query name.
Initial project schedule. The Gantt chart served as a planning aid rather than a strict account of the final development timeline.
Scope
FTExfil transfers a file from a client to an authoritative server through DNS query names. It must split the input into manageable chunks, protect the chunks cryptographically, transform them into DNS-compatible names, and reconstruct the original bytes at the receiver.
The experimental focus is the encoding layer. Regex-based Format Transforming Encryption constrains the output language, while Huffman-based encoding shapes its character frequencies. A Base32 implementation provides a conventional performance baseline.
The project does not attempt to implement a complete general-purpose network tunnel, and it does not address every indicator used in DNS tunnel detection.
Functional requirements
| ID | Requirement |
|---|---|
| FR1 | Transfer data from a client to a server using DNS queries. |
| FR2 | Divide the input file into smaller chunks that fit into subdomains before transmission. |
| FR3 | Include metadata alongside the chunks so that the receiver can reconstruct the file. |
| FR4 | Transform the transmitted data into query names compatible with DNS constraints. |
| FR5 | Extract transferred data from incoming queries at the receiver. |
| FR6 | Reconstruct the original file from the data received in subdomains. |
| FR7 | Handle duplicate chunks and chunks arriving out of order. |
| FR8 | Support key exchange between client and server. |
The first seven requirements describe the necessary file-transfer behaviour. Key exchange was specified as a desirable feature and implemented with two elliptic-curve options.
Non-functional requirements
| ID | Requirement |
|---|---|
| NFR1 | Generated query names comply with DNS syntax and length constraints. |
| NFR2 | Reconstructed files are byte-identical to the original inputs. |
| NFR3 | Transmitted data is protected against unauthorized reading. |
| NFR4 | Unauthorized modification of transmitted data is detected. |
| NFR5 | The application is modular so components can be modified independently. |
| NFR6 | Runtime configuration does not require changes to source code. |
These requirements influence different parts of the design. DNS constraints determine encoding capacity. Byte-identical reconstruction requires explicit chunk indexes and payload lengths. Confidentiality and integrity require both encryption and authentication. Modularity separates the transport pipeline from the encoder so the alternatives can be evaluated within the same application.
The none key-exchange mode uses a fixed development key; confidentiality requires an appropriate session key rather than that debugging configuration.
Evaluation approach
The encodings were compared through repeated file transfers in an isolated Docker environment. Duration, throughput, packet count, and hostname entropy characterize the trade-off between transmission efficiency and the visible output representation.
The evaluation does not equate a lower entropy value with successful evasion of a detector. Testing against actual DNS tunneling detection systems remains a separate research question.