Sensors form the data collection layer of the pDNS service 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 systems. 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 embedded systems, such as network 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 script)

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 (Native passivedns)

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 below, 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 ARM64 (also known as AArch64) architecture. This approach eliminates the need for an interpreter or external runtime dependencies, significantly reducing both memory and storage requirements. The same code can be compiled for other architectures such as variants of MIPS32/MIPS64, RISC-V, as well as Intel/AMD

As reflected in the performance table, tools such as tcpdump and native 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 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 native 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 (native passivedns). 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.

Ideas & Roadmap

Passive DNS Privacy Shield is an evolving project. Beyond its current capabilities, we see several promising directions that can further strengthen privacy, usability, and deployment flexibility.

Privacy focused pDNS collection system must be based on the three key layers or components: sensor, shield, and collector.

Sensor

The sensor sits near the DNS resolver and batches up DNS responses 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 responses 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. It also serves as a mixer for several source streams making it even harder to even guess a possible source of the pDNS record.

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 responses, which can be used for forensics, incident response, and identifying long-term patterns or trends in network behavior.

Data protocols

The sensor sends DNS responses to the shield via encrypted UDP packets. The data is accumulated for some time before being submitted to the pDNS Collector. The Collector receives, decrypts and validates the data integrity. The data is subsequently stored and used for analysis. Throughout the process, a heartbeat mechanism is used at all levels to ensure liveness of the system components and allowing real-time response to potential network issues or a hardware malfunction.

What Is pDNS?

The pDNS is short for Passive Domain Name System, a technique commonly used for security and network monitoring purposes. While DNS (Domain Name System) serves as the protocol that translates human-readable domain names (i.e. www.mydomain.com) into IP addresses for enabling communication between devices over the internet, pDNS goes a step further. Instead of actively querying DNS servers, pDNS sensors observes and records DNS response data that has already been made, either by other users, systems, or devices. pDNS is written with a lowercase "p" to be recognizable among other projects which using the same acronym. It also highlights the "passive" nature of the technique which helps lowering the workload from the DNS servers.

With pDNS, security teams can discover potential access to a malicious infrastructure, detect suspicious behavior, and even investigate incidents after they occur, without compromising users' communication privacy. In the recommended setup, pDNS does not collect personally identifiable information; instead, it logs only anonymized DNS server response data. This can be turned into 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. The pDNS Shield project is an enabler that is aimed to encourage users provide pDNS data openly without compromise of their privacy and 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 potenial 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.