What Is pDNS?

Passive DNS, short for Passive Domain Name System, is a tool commonly used for security and network monitoring purposes. While DNS (Domain Name System) serves as the protocol that translates human-readable domain names (such as www.google.com) into IP addresses for enabling communication between devices over the internet, pDNS goes a step further. Instead of actively querying DNS servers, pDNS passively records DNS query data that has already been made, either by other users, systems, or devices.

With pDNS, security teams can track the queries made to malicious domains, detect patterns of suspicious behavior, and even investigate incidents after they occur, without compromising the privacy of users. Usually, pDNS does not collect personally identifiable information; instead, it logs only anonymized DNS query data, making it an effective tool for cybersecurity monitoring while respecting user privacy.

Why pDNS privacy matters

As cyberattacks have become more sophisticated, modern threat actors often begin with reconnaissance, using techniques like T1590.002 (Gather Victim Network Information – DNS) and T1596.001 (Active Scanning – DNS/Passive DNS) from the MITRE ATT&CK framework to leverage DNS data for gathering critical information, affecting individual user browsing privacy and organization security.

Individual User browsing Privacy

pDNS records when accessed from the database can reveal browsing activities of users, which can be exploited by advertisers, trackers and malicious actors. This prevents users' anonymity and leaks sensitive behavioral information that can lead to phishing and targeted exploitation

Organizational Security

For organization unprotected pDNS data exposes valuable insights about their internal networks, external communication that attackers can use to either exploit business relations or plan intrusions like watering hole attacks

Project Components

Sensor

The sensor sits near the DNS resolver and batches up dns queries and sends them over to privacy shield.

Privacy Shield

The Privacy Shield ensures that pDNS data is anonymized and secured to protect user privacy. It acts as a filter that prevents personally identifiable information (PII) or sensitive internal data from being exposed while still allowing the analysis of DNS queries for security purposes. This shield is essential for ensuring compliance with data privacy laws and maintaining confidentiality while using pDNS data for network monitoring and threat detection.

Collector

The pDNS collector is responsible for storing and aggregating the DNS query data captured by sensors. It organizes and stores the data in a centralized database for further analysis. The collector helps maintain historical records of DNS queries, which can be used for forensics, incident response, and identifying long-term patterns or trends in network behavior.

Data processing

The sensor sends DNS queries to the shield via UDP packets. This data is then stored in a database. The privacy shield then extracts necessary information to maintain anonymity and is then stored back into the database. The pDNS Collector then retrieves the stored data which is subsequently used for analysis. Throughout the process, a heartbeat mechanism is used to ensure continuos monitoring and synchronisation of the system, allowing real-time data updates.

Pursuing ISP Authorization for Controlled IP Spoofing

Our team aims to gain recognition for its efforts in contributing to a safer cyberspace by encouraging broader participation from pDNS data providers. However, to reduce maintenance costs and streamline long-term operations, it is desirable to secure support from a trusted local entity to serve as an intermediary for hosting the Passive DNS Privacy Shield. This would enable local pDNS data providers to route their data through this entity instead of relying on a foreign VPS. To realize this approach, cooperation from local ISPs would be necessary—specifically, to grant special permissions for allowing packets with spoofed IP addresses from a designated address pool to be transmitted to these trusted intermediaries.

Enhancing Sensor Compatibility and Deployment Efficiency

Our team acknowledges the complexity involved in developing pDNS data sensors compatible with a wide range of platforms and hardware used by different organizations. To support the majority of enterprise and commercial-grade routers, future work will focus on identifying commonly used models, understanding their requirements and limitations, and providing precompiled versions of the pDNS data sensor. This would eliminate the need for organizations to perform compilation or cross-compilation themselves. Instead, they would simply select the appropriate version from a list of supported sensors, deploy it to their system, and execute it.

Maintenance Framework for Long-Term Sustainability

For the proposed initiative to be scalable and viable for long-term adoption, particularly by larger and/or international organizations, it is essential to establish a robust maintenance and support framework for all project components. This includes the continual maintenance and expansion of the pDNS data sensor repository, as well as the regular updates and patch management for the Passive DNS Privacy Shield. Without such a system in place, the effectiveness and reliability of the solution would diminish over time as new technologies and platforms emerge.

Regular update of pDNS data respository

As new operating systems and router firmware versions, and embedded platforms are released, new versions of sensors will need to be developed, compiled, and made available. There must be a process in place to track these updates and ensure the range of supported environments for the sensors are supported. In parallel, the Passive DNS Privacy Shield needs to undergo regular updates as well. These updates may include new forms of encryption and performance improvements. To manage this effectively, a formal versioning system should be implemented, along with thorough changelog documentation and testing protocols to ensure stability and backward compatibility.

Standard Operating Procedures(SOPs)

A set of Standard Operating Procedures (SOPs) established to govern the maintenance process and cycle. These SOPs should define how frequently the components should be reviewed or updated, and who is responsible for these tasks. For instance, a quarterly update schedule may be adopted for regular enhancements, while critical issues should trigger immediate patching workflows.

Feedback and pDNS data provider support system

There should be a feedback and pDNS data provider support system implemented to address the queries and technical difficulties. This would help foster trust, encourage continued participation, and ensure smoother integration and troubleshooting processes. However, it is important to note that during this process, the identity of the pDNS data provider is not exposed at any point.

Maintaining anonymity with TOR

The Privacy shield can be further enhanced by encorporating TOR to maintain anonymity of organizations. BY routing DNS queries through th TOR network, we can ensure that the user's real IP address is hidden and that their online activity remains anonymous. This prevents third parties from tracing the origin of the query. Furthermore, by employing DNS-over-Tor (DoT) or DNS-over-HTTPS (DoH) protocols, you can encrypt DNS traffic and prevent eavesdropping while it traverses the Tor network. This end-to-end encryption and routing through Tor's anonymous network significantly mitigate the risk of identity exposure and traffic analysis, thus enhancing the overall privacy and anonymity of your users

Expanding the network

Sensor Usability

We are now aiming to expand usability by including alternative sensors like IOS and android.This expansion aims to make the Privacy Shield more accessible to a broader range of users and organizations, ensuring that privacy protection is seamless across various platforms. Additionally, we plan to integrate mobile-specific features, including privacy alerts and device-specific optimizations, to further enhance both anonymity and the overall user experience. This will allow us to provide a more robust, versatile, and user-friendly privacy solution, catering to the evolving needs of users across diverse devices.

Co-working sensors and shields

We are also aiming on xpanding the Privacy Shield into a distributed and collaborative network consisting of multiple sensors and multiple Privacy Shield instances operating together. Instead of a single centralized deployment, sensors may be deployed across different organizations, networks, and geographical locations, each forwarding anonymized pDNS data to one or more Privacy Shields

In this expanded architecture, multiple Privacy Shields can operate in parallel and exchange selected anonymized threat intelligence, enabling broader visibility into emerging DNS-based threats while avoiding a single point of failure. This federated approach improves scalability, resilience, and fault tolerance, allowing the system to grow as participation increases.

Sensors form the data collection layer of the pDNS Privacy Shield architecture and are responsible for forwarding passive DNS data to the Privacy Shield. These sensors are deployed across heterogeneous environments, ranging from desktop computers and servers to embedded network routers. These platforms differ significantly in CPU capability, available memory, storage capacity, and supported software dependencies. As a result, a single sensor implementation would be inefficient or infeasible across all deployment scenarios.

To address this, multiple sensor implementations were developed and tailored for both resource-rich PC/server environments and resource-constrained routers. This design ensures efficient operation across diverse platforms without compromising performance, reliability, or privacy guarantees.

To evaluate these design choices, different packet sniffing implementations were benchmarked and compared in terms of CPU load, memory usage, storage consumption, and traffic captured, as summarised in the table below

Sensors Used

PC/Servers (Python Based)

The PC/server sensor was implemented in Python and serves as the primary platform for development, testing, and full-scale deployments in resource-rich environments. As shown in the table above, the Python Scapy sniffer incurs higher CPU load, memory usage, and storage consumption compared to lightweight native sniffers. This overhead is primarily due to the Python interpreter and its associated libraries.

Despite this, Python was selected for its flexibility, extensive library ecosystem, and ease of debugging, which enabled rapid development and iteration of encryption, anonymization, and data transmission logic. In PC and server environments, where CPU, memory, and storage resources are readily available, these overheads remain acceptable and do not impact system stability or performance. As a result, the Python-based sensor is well suited for development, testing, and feature-rich deployments where maintainability and extensibility are prioritised.

Routers (Compiled Binary)

Routers are typically front-line devices that capture DNS traffic at the network edge. They operate in highly resource-constrained environments, often offering limited RAM, flash storage, and minimal software support. This is evident from the router configuration shown, where only approximately 30 MiB of RAM and 7.5 MiB of storage remain available.

To accommodate these constraints, the router sensor was implemented as a compiled binary targeting the aarch64 architecture. This approach eliminates the need for an interpreter or external runtime dependencies, significantly reducing both memory and storage requirements.

As reflected in the performance table, tools such as tcpdump and PassiveDNS exhibit substantially lower CPU and memory usage compared to the Python-based Scapy sniffer. These tools are implemented in C, a compiled language that is highly efficient and well suited for constrained environments. Their low overhead enables continuous packet capture on routers without degrading packet forwarding performance or system stability

In addition, packages like Tcpdump installed via package managers such as apk are extensively tested and maintained by official developers. They are optimized for performance, built with minimal dependencies, and free from unnecessary or redundant code that could introduce overhead. In contrast, open-source tools like PassiveDNS may include extra code for flexibility or extended features, which, while useful, can result in slightly higher resource usage and less streamlined performance

Summary

In conclusion, supporting multiple sensor implementations is necessary to ensure compatibility across a wide range of deployment environments. While Python-based sensors are suitable for PCs and servers due to their flexibility and ease of development, routers require lightweight, resource-efficient solutions. Since embedded systems typically lack a Python interpreter and operate under strict resource constraints, compiled C-based sniffers provide superior performance, lower memory usage, and greater compatibility. This platform-specific approach enables efficient and reliable pDNS data collection across the entire Privacy Shield architecture