DNS blocking in practice: PDNS in a Research and Education Network

As malicious domains continue to pose a threat across the Internet, security professionals are left to consider the measures that can effectively defend their organizations from these threats. Research and Education Networks (RENs), whose mission is to support the networking needs of K-12 (kindergarten to year 12) schools and institutions of higher education, are uniquely poised to provide secure Internet services to a vast user demographic.

Given this scale, the range of Domain Name System (DNS) queries sent by REN users is as diverse as the demographic of users that RENs support. To mitigate the risk of users accessing malicious sites, a subset of security measures can be employed, with a noteworthy example being the incorporation of a Protective Domain Name System (PDNS) service.

PDNS blocklists are curated with intent

PDNS is a recursive DNS service that restricts users from accessing potentially malicious sites by refusing to fulfil domain requests that match preconfigured blocklists. This security measure typically operates in one of two ways:

1. By providing a user with an alternative response (for example, IP address), typically directing the user to an internal ‘website blocked’ resolution page.
2. By outright refusing to resolve the requested domain altogether.

While these approaches differ in implementation, both restrict a user’s ability to connect to a service via a domain name that has been categorized as malicious.

Despite their relative simplicity, PDNS blocklists are not a catch-all security solution; blocklists differ in their goals, threat categorization, maintenance frequency, and community support. Therefore, an organization must understand its threat landscape and users’ expectations when identifying the types of blocklists to use.

A good choice of blocklists for a user’s home network that serves a single family may be a poor choice for an academic institution, having thousands of students and staff.

This distinction in blocklist intent led us to ask the following questions: Does the varying scope of a blocklists lead to disagreements on the meaning of a threat? How does the operational context of an organization impact curation strategies and filtering requirements?

Passively measuring three PDNS blocklists

Our team performed a passive measurement study of real user DNS queries within a REN. The study aimed to quantify the volume of DNS resolutions that matched entries within a set of threat-based blocklists, and analyse the overlap of flagged domains across those lists. The goal of this study was to provide insight into the effectiveness of these openly available blocklists and draw conclusions regarding their scope, overlap, and limitations.

This investigation started with a preliminary analysis of three threat-oriented blocklists:

• LevelBlue Open Threat Exchange (OTX) Phishing and Scam Domain Names
• HaGazi Threat Intelligence Feed (TIF)
• Université Toulouse Capitole’s Prigent Malware

Each of these blocklists is consistently maintained, incorporating user feedback to tailor their entries. The OTX blocklist is unique in that it is the only blocklist in our collection that is commercially curated while still being openly available for public use. TIF and Prigent Malware have an archive of timestamped entries ideal for the purposes of research and lookback.

Even before investigating user queries, these blocklists themselves showed surprisingly little overlap. Figure 2 is a proportional Venn diagram that summarizes the set of blocklists with respect to unique domain names and intersecting entries. The intersection of these blocklists is also summarized in Table I:

• 2,009 domain names occur in both OTX and TIF.
• 1,670 in both OTX and Prigent Malware.
• 55,451 in both TIF and Prigent Malware.
• 665 entries occur in all three sets.

Exemplifying a previously mentioned topic, these blocklists vary widely in size and have limited intersections — ultimately suggesting differing goals, selection criteria, and performance, all while similarly categorizing their entries under the labels of ‘Threat’ and ‘Malware’.

With the blocklist sources identified, we proceeded with collecting REN users’ DNS queries and responses from 19 to 25 June 2025, and obtained versions of each blocklist dated 13 June. The dataset of DNS responses consisted of over 890 million packets with 1.79 million unique domain queries. Before analysis, the destination client IP addresses within these recursive DNS responses were anonymized so that DNS responses would not be attributed to individual organizations.

Digging deeper into blocklist overlap

To conduct this measurement analysis, we employed a custom tool, TreeTop, originally based on dnstop, to filter and parse relevant information from the captured packets of DNS responses. Treetop is a passive DNS monitoring tool that processes packet capture (pcap) files, reconstructing their domain-IP relationships into tree-based data structures. In this study, Treetop was used to analyse the pcap files by matching observed domain names against those within the provided blocklists. This technique enabled the collation of matched domains and quantification of domain intersections between blocklists.

In Figure 3, we show the intersection of unique blocklist domain names that appear within the 890 million DNS queries encountered over the one-week capture period:

• 27 unique domains matched OTX.
• 2,907 matched TIF.
• 236 matched Prigent Malware.
• 3 domains were contained in both OTX and TIF.
• 27 were in both the TIF and Prigent Malware.
• There was no overlap between OTX and Prigent Malware, which also ensured no overlap between all three datasets.

The intersection of these blocklists filtered against the list of DNS responses is also summarized in Table I.

Table 1 — Blocklist comparison summary table.

Overlap values indicate the number of shared entries between datasets. ‘Overlap All’ represents entries common to OTX, TIF, and Prigent. Pre-measurement values reflect the raw blocklist dataset entries, while post-measurement values reflect the number of unique DNS entries for each of the blocklists that were flagged as present within the 890 million responses.

Although this analysis is limited to a single week of captured REN traffic, several conclusions can be drawn from the observed results. Most notably, each blocklist within the evaluated set claims to provide protection against ‘threats.’ However, they exhibit significant differences in domain coverage and in the volume of observed threats from real user traffic. These discrepancies suggest that blocklist entries are influenced partially, if not entirely, by the curator-specific methodologies and a subjective definition of what constitutes malicious behaviour.

Limited transparency into blocklist curation

Expanding further into the issue of subjective curation, we observe the limited transparency into a blocklist’s curation strategy and taxonomy. Consistent with commercial PDNS solutions, these openly available blocklists provide minimal insight into the criteria leading to the classification of a malicious site and the category of ‘threat’ for an entry.

This lack of transparency fundamentally limits a security professional’s ability to determine whether selected lists will adequately protect their organization, which may inadvertently result in the overblocking or underblocking of domains. A blocklist curated for one organization may not meet the requirements of an organization in a different sector (for example, banking, education, healthcare, government, and so on), as each has distinct security requirements that may not translate across industries.

Lastly, the increasing reliance on AI-driven practices for threat categorization and classification may lead to greater uncertainty in the realm of PDNS blocklist curation. Although AI solutions offer ease of implementation, they may inadvertently increase these issues related to curation, transparency, and taxonomy. Without clear definitions, automated domain blocking risks amplifying ambiguous decision-making, rather than resolving it.

This leads back to the central question of how security professionals can protect their organizations from potentially malicious domains. These limitations underscore the need for tailored curation strategies to support the needs of individual sectors. Specifically, RENs, with their shared mission and aligned goals of user safety, are well-positioned to develop and curate security solutions that better adhere to the unique networking needs required by their users.

We are expanding this work by continuing to explore the unique opportunity presented by REN traffic. Future research will examine whether queried services are internal to the REN or resources from other RENs, as well as the geographic locations of service infrastructure associated with queried domains.

This work was conducted in collaboration with WiscNet and Marquette University and presented at the IMC PRIME 2025 Workshop (pre-print). A sincere thanks to WiscNet Principal Research Scientist Dr David Plonka and Marquette University Associate Professor Dr Debbie Perouli. Computational resources were provided by the Open Science Pool (OSPool), a resource provided by the Open Science Grid (OSG) Consortium.

Branden Palacio is a Master’s student at Marquette University studying Computer and Information Science, specializing in Information Assurance and Cyber Defence.

---

The views expressed by the authors of this blog are their own and do not necessarily reflect the views of APNIC. Please note a Code of Conduct applies to this blog.