Location Research Breakthrough Possible @S-Logix pro@slogix.in

Deep Learning-Based Detection of Botnet DNS Communication Against a BIND9 DNS Server on Ubuntu Using Multilayer Perceptron (MLP)

Description

Botnets are networks of compromised systems that communicate with other systems to coordinate malicious activities. Some botnets use the Domain Name System (DNS) to resolve domain names associated with their communication infrastructure. DNS traffic can therefore provide useful information for investigating potentially suspicious network activity.

DNS is an essential component of normal network operations. Applications use DNS queries to resolve domain names into IP addresses, and legitimate systems generate DNS requests as part of routine communication. However, botnet-related DNS activity may exhibit unusual characteristics, including repeated queries, irregular query patterns, unexpected domain characteristics, or abnormal distributions of DNS requests.

Traditional security mechanisms may identify known malicious domains through blocklists or predefined rules. However, these approaches may not identify every suspicious DNS communication pattern, particularly when the domain or query behavior is not already represented in existing detection rules.

Deep learning-based classification provides an additional approach by learning relationships between multiple DNS traffic features and their associated labels. In this use case, a Multilayer Perceptron (MLP) is developed to classify DNS traffic as normal or botnet-related based on the available labeled observations.

A public botnet DNS traffic dataset is used as the existing data source for the machine-learning stage. The available records are inspected to determine whether they contain sufficient DNS-specific features and reliable labels for the intended classification task. Suitable features are extracted and transformed into numerical representations for model development.

A BIND9 DNS server is deployed on Ubuntu within an isolated VirtualBox laboratory. The DNS server provides the target environment for observing legitimate DNS queries and responses. Controlled DNS activity is generated from an authorized laboratory client, and the resulting traffic is captured for analysis.

The MLP model is trained using suitable labeled DNS traffic records from the public dataset. The trained model is then evaluated using held-out labeled records. Compatible DNS observations from the laboratory are processed through the same feature-extraction workflow to assess whether the model can analyze traffic generated in the target environment.

The model produces a classification result for each evaluated observation. The predictions are compared with known labels where available to measure classification performance, false-positive behavior, and false-negative behavior.

The complete DNS-based botnet-detection workflow is:

Public Botnet DNS Traffic Dataset → Dataset Inspection → DNS Record Selection → Data Preprocessing → DNS Behavioral Feature Extraction → MLP Model Training → Ubuntu BIND9 DNS Server → Legitimate DNS Query Generation → DNS Traffic Capture → DNS Feature Extraction → MLP Classification → Botnet-Related DNS Traffic Identification → Performance Evaluation → Controlled Detection Validation

Existing Security Problem

Application: BIND9 DNS Server on Ubuntu

BIND9 is an open-source DNS server that can be deployed on Ubuntu to provide DNS resolution within a controlled laboratory network. In this use case, it serves as the target DNS environment for generating legitimate DNS queries, capturing DNS traffic, and validating the traffic-analysis workflow.

The application is deployed within an isolated VirtualBox laboratory to ensure that all testing remains within the authorized environment.

Existing Problem :

DNS traffic is generated by normal applications and operating-system services. Because DNS is routinely used for domain-name resolution, suspicious DNS activity may be mixed with legitimate queries.

Botnet-related DNS communication may involve repeated requests, unusual query distributions, suspicious domain characteristics, or other behavioral patterns. However, an individual DNS query does not necessarily indicate malicious activity, and many suspicious-looking patterns can also occur during legitimate operations.

Traditional DNS security mechanisms may depend on known malicious domains, threat-intelligence feeds, or predefined detection rules. Such mechanisms may not identify suspicious DNS behavior that does not match existing indicators.

Deep learning-based classification can provide an additional detection approach by analyzing multiple DNS traffic characteristics together. Its effectiveness depends on the quality of the training dataset, the selected features, the reliability of the labels, and the similarity between training and evaluation traffic.

The security problem is:
Ubuntu BIND9 DNS Server
→
Legitimate DNS Query Activity
→
Potential Botnet-Related DNS Communication
→
Overlapping Normal and Suspicious DNS Characteristics
→
Limitations of Known-Domain Detection
→
Potentially Unidentified Botnet DNS Activity
→
DNS Behavioral Classification Requirement
→
Deep Learning-Based Detection

The proposed solution uses an MLP classifier trained on a public botnet DNS traffic dataset to distinguish normal DNS observations from botnet-related DNS observations.

Attack

Specific Attack: Controlled Botnet-Related DNS Traffic Detection Scenario

The security assessment focuses on identifying DNS traffic patterns associated with botnet communication.

Real botnet malware and live command-and-control infrastructure are not required. The machine-learning model is trained and evaluated using appropriately labeled public DNS traffic records. The laboratory is used to generate legitimate DNS traffic and validate the DNS collection and feature-processing workflow.

A BIND9 DNS server is deployed on Ubuntu, and legitimate DNS queries are generated from an authorized laboratory client. DNS requests and responses are captured and inspected to identify the fields and behavioral characteristics available for analysis.

Where suitable labeled DNS observations are available, recorded botnet-related DNS traffic is used for model training and testing. Laboratory-generated DNS traffic is processed separately unless reliable labels and compatible features are available for evaluation.

The objective is to determine whether the trained MLP can distinguish DNS observations associated with botnet activity from normal DNS traffic under the tested conditions.

Attack Behavior :
Public Botnet DNS Traffic Records
→
Normal and Botnet-Related DNS Record Identification
→
DNS Feature Extraction
→
MLP Model Training
→
Ubuntu BIND9 DNS Server
→
Legitimate DNS Query Generation
→
DNS Traffic Capture
→
DNS Feature Extraction
→
MLP Classification
→
Normal or Botnet-Related Prediction
→
Comparison with Known Labels
→
Detection Performance Validation

Security Concept

Deep Learning-Based DNS Traffic Classification

The primary security concept is deep learning-based classification of DNS traffic for botnet detection.

The first objective is to establish a suitable collection of labeled DNS traffic observations. The public dataset is inspected to determine whether it provides DNS-specific attributes and reliable normal and botnet-related labels. Records that do not support the intended classification task are excluded.

The second objective is to train a Multilayer Perceptron classifier. An MLP is a feed-forward neural network that learns relationships between input features and class labels through interconnected layers of computational units. The model learns from the numerical representations of the selected DNS traffic features.

The third objective is to evaluate the trained classifier using held-out labeled observations. Predictions are compared with known labels to calculate classification metrics and identify false positives and false negatives. DNS traffic captured from the BIND9 laboratory environment is used to validate the traffic collection and feature-processing workflow, provided that the captured observations can be represented using features compatible with the trained model.

The assessment follows:
Public Botnet DNS Traffic Dataset
→
DNS Dataset Inspection
→
Traffic Label Verification
→
Data Preprocessing
→
DNS Behavioral Feature Extraction
→
Training and Test Data Separation
→
Multilayer Perceptron Training
→
Trained DNS Traffic Classifier
→
Ubuntu BIND9 DNS Server
→
DNS Query and Response Capture
→
Compatible Feature Extraction
→
MLP Prediction
→
Comparison with Known Labels
→
Detection Performance Evaluation

Defensive Mechanism

The security concept defines the overall detection strategy.

The following are the specific defensive mechanisms implemented in this use case.

Labeled DNS Traffic Baseline

Suitable normal and botnet-related DNS observations are selected from the public dataset.

Purpose: Establish labeled DNS traffic examples for supervised model training and evaluation.

DNS Behavioral Feature Extraction

DNS-related attributes are extracted and converted into numerical features suitable for the MLP classifier.

Purpose: Represent DNS communication in a consistent numerical format for deep learning.

Multilayer Perceptron Classification

The MLP learns relationships between the selected DNS features and their associated traffic labels.

Purpose: Classify DNS observations according to their learned behavioral characteristics.

Consistent Feature Processing

The feature-extraction and preprocessing workflow is applied consistently to training and evaluation records.

Purpose: Maintain compatibility between the model's training inputs and its evaluation inputs.

DNS Traffic Monitoring

DNS queries and responses are captured from the authorized BIND9 laboratory environment.

Purpose: Provide DNS traffic evidence for validating the data-collection workflow.

Classification Performance Evaluation

The predicted traffic classes are compared with known labels using appropriate evaluation metrics.

Purpose: Measure detection performance, false positives, and false negatives.

Controlled Detection Validation

The trained model is evaluated using held-out dataset observations and compatible laboratory traffic features.

Purpose: Determine whether the detection workflow identifies the intended DNS traffic patterns under the tested conditions.

Security Tools

Target Environment: Ubuntu Linux

Ubuntu provides the operating system for the BIND9 DNS server and the machine-learning environment.

Purpose
  • Host the BIND9 DNS server.
  • Generate and capture legitimate DNS activity.
  • Execute Python-based data processing and model evaluation.
  • Support the isolated DNS security experiment

DNS Server: BIND9

BIND9 provides the DNS service used as the target application in the laboratory.

Purpose
  • Resolve DNS queries within the laboratory.
  • Generate legitimate DNS request and response traffic.
  • Provide the environment for DNS traffic observation.
  • Support controlled DNS testing.

Laboratory Virtualization Platform: VirtualBox

VirtualBox provides the isolated environment for the Ubuntu DNS server and the Kali Linux testing system.

Purpose
  • Deploy the laboratory virtual machines.
  • Configure isolated virtual networking.
  • Separate testing activities from external systems.
  • Support repeatable DNS traffic experiments.

Network Testing Platform: Kali Linux

Kali Linux provides the authorized testing environment for accessing the laboratory DNS service and inspecting DNS behavior.

Purpose
  • Generate permitted DNS queries.
  • Verify connectivity to the laboratory DNS server.
  • Support controlled DNS testing.
  • Assist with traffic validation.

Machine-Learning Environment: Python

Python provides the programming environment for dataset processing, DNS feature extraction, model training, and classification evaluation.

Purpose
  • Implement the DNS traffic classification workflow.
  • Prepare numerical model inputs.
  • Train and evaluate the MLP classifier.
  • Analyze the detection results.

Deep Learning Library: TensorFlow/Keras

TensorFlow/Keras provides the framework for developing and training the Multilayer Perceptron model.

Purpose
  • Define the MLP network architecture.
  • Train the neural network using labeled DNS features.
  • Generate classification predictions.
  • Evaluate model performance.

Data Processing Tool: Pandas

Pandas is used to load, inspect, filter, and organize the public botnet DNS traffic dataset.

Purpose
  • Inspect dataset columns and labels.
  • Select suitable DNS observations.
  • Identify missing or inconsistent values.
  • Prepare records for feature extraction.

Numerical Processing Tool: NumPy

NumPy supports the numerical operations required for feature preparation and neural-network input processing.

Purpose
  • Perform numerical feature transformations.
  • Prepare array-based model inputs.
  • Support data validation.
  • Assist with evaluation calculations.

Machine-Learning Evaluation Tool: Scikit-learn

Scikit-learn provides data-splitting utilities and classification metrics for evaluating the MLP model.

Purpose
  • Separate training and test records.
  • Support preprocessing and feature scaling.
  • Calculate precision, recall, and F1-score.
  • Generate confusion matrices and classification reports.

Network Traffic Analysis Tool: Wireshark

Wireshark is used to inspect DNS traffic captured from the laboratory environment.

Purpose
  • Inspect DNS queries and responses.
  • Review DNS message fields.
  • Validate the traffic observed between the client and BIND9 server.
  • Support DNS traffic analysis.

Packet Capture Tool: tcpdump

tcpdump captures network packets from the authorized laboratory network interface.

Purpose
  • Capture legitimate DNS traffic.
  • Preserve packet-capture evidence.
  • Provide DNS packet data for inspection.
  • Support repeatable traffic observations.

Network Discovery Tool: Nmap

Nmap is used to verify the exposure of the authorized laboratory DNS service.

Purpose
  • Identify the intended DNS service port.
  • Verify network reachability.
  • Document the laboratory service exposure.
  • Confirm the expected network configuration.

Network Traffic Dataset: Public Botnet DNS Traffic Dataset

A public botnet DNS traffic dataset provides the labeled DNS observations required for model development.

Purpose
  • Supply suitable normal DNS traffic observations.
  • Supply labeled botnet-related DNS observations.
  • Support supervised MLP training.
  • Provide held-out records for evaluation.

Data Visualization Tool: Matplotlib

Matplotlib is used to visualize the classification metrics and experimental findings.

Purpose
  • Display classification performance.
  • Visualize the confusion matrix.
  • Compare precision, recall, and F1-score.
  • Present the experimental results.

Process

STEP 01

Prepare the Isolated Laboratory Environment

  • Create the laboratory using VirtualBox.
  • Deploy Ubuntu as the BIND9 DNS server and machine-learning environment.
  • Deploy Kali Linux as the authorized testing system.
  • Configure an isolated virtual network so the systems can communicate as required.
  • Verify the network configuration and IP addresses.
  • Confirm that the DNS testing environment is not unintentionally exposed to the public internet.
Tools: VirtualBox + Ubuntu + Kali Linux
STEP 02

Install and Configure the BIND9 DNS Server

  • Install BIND9 on the Ubuntu virtual machine using the available package-management method and authorized administrative access.
  • Configure the DNS service for the intended laboratory environment.
  • Start the DNS service and verify its status.
  • Configure the necessary network access for the authorized laboratory client
  • Check that the server listens on the intended laboratory interface.
  • Keep the DNS service restricted to the laboratory network and avoid creating an open resolver accessible
Tools: Ubuntu + BIND9
STEP 03

Validate Normal DNS Resolution

  • Use the authorized laboratory client to issue legitimate DNS queries to the BIND9 server.
  • Test resolution for domain names configured for the laboratory.
  • Observe the corresponding DNS responses.
  • Verify that successful queries return the expected results.
  • Record the DNS server address and the relevant network configuration.
  • Preserve the normal DNS behavior as the initial laboratory baseline.
Tools: Ubuntu + Kali Linux + BIND9
STEP 04

Identify the Laboratory DNS Service Exposure

  • Identify the IP addresses assigned to the Ubuntu and Kali Linux virtual machines.
  • Verify connectivity between the authorized client and the DNS server.
  • Perform controlled Nmap service discovery against the laboratory DNS server.
  • Confirm that the intended DNS service is reachable from the authorized testing system.
  • Record the exposed service port and network configuration.
  • Verify that the observed exposure matches the intended laboratory architecture.
Tools: Kali Linux + Nmap + Ubuntu
STEP 05

Obtain the Public Botnet DNS Traffic Dataset

  • Obtain the selected public botnet DNS traffic dataset from its authorized distribution source.
  • Inspect the available files and data formats.
  • Determine whether the dataset contains DNS-specific records, packet captures, or processed DNS features.
  • Review the available labels and their meanings.
  • Check whether the data includes sufficient examples of normal and botnet-related DNS activity.
  • Preserve the original dataset before processing it.
Tools: Python + Pandas
STEP 06

Inspect and Validate the DNS Traffic Labels

  • Load the available dataset records into the Python processing environment.
  • Inspect the columns, data types, record counts, and label values.
  • Identify the labels representing normal DNS traffic and botnet-related DNS traffic.
  • Review the number of observations in each class.
  • Identify missing fields, duplicate records, and records that cannot be reliably classified.
  • Confirm that the selected data supports the intended binary classification task.
Tools: Python + Pandas + NumPy
STEP 07

Select Suitable DNS Observations

  • Select the normal and botnet-related DNS observations required for supervised training.
  • Retain the DNS-related attributes needed for the planned behavioral analysis.
  • Exclude records with missing or unreliable labels when they cannot be safely resolved.
  • Remove irrelevant identifiers and fields that could introduce label leakage.
  • Verify that the selected records represent DNS traffic rather than unrelated network protocols.
  • Document the selection criteria and preserve the selected records for preprocessing.
Tools: Python + Pandas
STEP 08

Preprocess the DNS Dataset

  • Clean the selected DNS records.
  • Handle missing values and invalid numerical entries where appropriate.
  • Convert the target labels into the class representation required by the MLP.
  • Convert suitable categorical features into numerical representations where necessary.
  • Remove unsuitable identifiers and fields that should not be used as predictive features.
  • Split the data into training, validation, and test sets before fitting data transformations.
  • Fit feature scaling using the training data and apply the same fitted transformation to the validation and test data.
Tools: Python + Pandas + NumPy + Scikit-learn
STEP 09

Extract DNS Behavioral Features

  • Identify the DNS-specific characteristics available in the selected dataset.
  • Depending on the available records, these may include query type, response code, query length, domain-name characteristics, query frequency, response size, and other relevant DNS attributes.
  • Use only features that are actually available and consistently defined in the selected data.
  • Transform the selected attributes into numerical feature vectors.
  • Verify that the features do not contain the target label or other information that directly reveals the expected classification.
  • Preserve the feature names, data types, and processing configuration.
Tools: Python + Pandas + NumPy
STEP 10

Prepare the MLP Training and Evaluation Data

  • Separate the processed DNS records into training, validation, and test datasets.
  • Use an appropriate splitting strategy to reduce the risk of duplicate or closely related records appearing across the partitions
  • Where the dataset supports it, separate observations by capture scenario or time to evaluate generalization more realistically.
  • Apply the preprocessing transformations fitted on the training data.
  • Verify that the input features contain valid numerical values and have compatible dimensions.
  • Check the class distribution in each partition.
Tools: Python + NumPy + Scikit-learn
STEP 11

Configure and Train the MLP Model

  • Define a Multilayer Perceptron architecture using TensorFlow/Keras.
  • Configure the input layer to match the number of selected DNS features.
  • Configure the hidden layers, activation functions, output layer, and training parameters for the binary classification task.
  • Train the model using the labeled training observations.
  • Use the validation dataset to monitor model performance and guide parameter selection.
  • Avoid using the held-out test labels during training or model selection.
  • Preserve the trained model and its preprocessing configuration.
Tools: Python + TensorFlow/Keras + NumPy
STEP 12

Evaluate the Initial Classification Results

  • Provide the held-out DNS test features to the trained MLP model.
  • Generate the predicted class or class probabilities for each test observation.
  • Convert the model output into class predictions using a documented decision threshold.
  • Compare the predictions with the known test labels.
  • Calculate accuracy, precision, recall, and F1-score.
  • Generate a confusion matrix and inspect false-positive and false-negative classifications.
Tools: Python + TensorFlow/Keras + Scikit-learn + Matplotlib
STEP 13

Generate Legitimate DNS Traffic in the Laboratory

  • Use the authorized Kali Linux client to issue legitimate DNS queries to the Ubuntu BIND9 server.
  • Generate multiple normal DNS query and response exchanges.
  • Capture the corresponding packets using tcpdump or Wireshark.
  • Preserve the packet-capture files for analysis.
  • Verify that the captured traffic corresponds to the intended laboratory DNS activity.
  • Document differences between the captured traffic and the public dataset.
Tools: Ubuntu + Kali Linux + BIND9 + Wireshark + tcpdump
STEP 14

Capture and Extract DNS Features from Laboratory Traffic

  • Inspect the captured traffic and identify the DNS packets relevant to the experiment.
  • Extract the required DNS message fields and behavioral characteristics.
  • If the trained model uses aggregated DNS statistics, calculate those statistics using a documented and consistent observation window.
  • Transform the captured observations into the same feature representation used during training.
  • Apply the saved preprocessing and feature-scaling transformations.
  • Verify that the resulting feature vectors have the correct structure and feature order.
Tools: Python + Pandas + NumPy + Wireshark + tcpdump
STEP 15

Classify Compatible DNS Observations

  • Provide the processed DNS feature vectors to the trained MLP model.
  • Generate the predicted class or class probabilities for each evaluated observation.
  • Apply the documented decision threshold to produce the final classification.
  • Record the prediction and corresponding observation information.
  • Check whether the model can process the laboratory features without missing fields or incompatible data types.
  • Treat predictions as indicators for further investigation rather than definitive proof of malicious activity.
Tools: Python + TensorFlow/Keras + Pandas
STEP 16

Validate Botnet-Related DNS Detection

  • Evaluate the MLP classifier using held-out DNS observations with known labels.
  • Measure how many botnet-related observations are correctly classified
  • Measure how many normal observations are incorrectly flagged.
  • Review false-negative cases to identify botnet-related observations classified as normal.
  • Review false-positive cases to identify normal observations classified as botnet-related.
  • Use the laboratory's legitimate DNS traffic to validate the capture and preprocessing workflow, but do not claim that normal-only laboratory traffic proves successful detection of live botnet DNS communication.
Tools: Python + TensorFlow/Keras + Scikit-learn + Matplotlib
STEP 17

Analyze and Correlate the Experimental Findings

  • Review the dataset, selected features, model configuration, and evaluation metrics.
  • Examine the confusion matrix and classification report.
  • Compare performance across the normal and botnet-related classes.
  • Assess the effect of class imbalance and possible data leakage.
  • Determine whether the public dataset and laboratory DNS observations use compatible feature definitions.
  • Document the differences between measured test-set performance and the behavior observed in the laboratory.
  • Record the detection limitations and conditions under which the model may fail.
Tools: Python + Pandas + Scikit-learn + TensorFlow/Keras + Matplotlib
STEP 18

Perform Final Detection Validation and Security Review

  • Repeat the evaluation where required to check reproducibility.
  • Verify that the test dataset was kept separate from model training and parameter selection.
  • Review the DNS feature-extraction procedure and preprocessing configuration.
  • Confirm that the trained MLP receives compatible feature vectors during evaluation.
  • Record the final classification metrics, false-positive rate, false-negative rate, and relevant limitations.
  • Document the model's detection capabilities and the differences between dataset evaluation and laboratory validation.
  • Finalize the deep learning-based DNS traffic classification assessment.
Tools: Python + TensorFlow/Keras + Scikit-learn + Pandas + NumPy + Matplotlib + Ubuntu + Kali Linux + BIND9 + Wireshark + tcpdump

Outcome

A BIND9 DNS server is successfully deployed on Ubuntu within an isolated VirtualBox laboratory, providing a controlled environment for legitimate DNS communication and traffic-analysis experiments.

A public botnet DNS traffic dataset is obtained and inspected to identify the normal and botnet-related DNS observations required for supervised deep learning.

The selected DNS records are preprocessed, and suitable DNS behavioral features are transformed into numerical representations for training and evaluation.

A Multilayer Perceptron model is developed and trained using labeled DNS traffic observations, enabling the model to learn relationships between DNS features and their corresponding traffic classes.

The trained MLP classifier is evaluated using held-out labeled records, providing measurable results for accuracy, precision, recall, F1-score, and classification errors.

Legitimate DNS queries and responses are generated within the Ubuntu laboratory and captured using network traffic analysis tools, validating the DNS traffic collection process.

The captured DNS traffic is inspected and processed into compatible feature representations, demonstrating how laboratory DNS observations can be prepared for analysis by the trained model.

The trained MLP generates classification predictions for compatible DNS observations, enabling the identification of patterns associated with the botnet-related class learned during training.

The experimental results are analyzed using classification metrics and a confusion matrix to identify detection effectiveness, false positives, false negatives, and potential limitations caused by differences between the public dataset and laboratory traffic.

The complete workflow of public dataset processing, DNS behavioral feature extraction, MLP training, BIND9 DNS traffic capture, classification, detection evaluation, and security-result analysis is documented, establishing a practical foundation for further research into deep learning-based botnet DNS communication detection.