APRICOT 2025 – DNS RPZ tutorial

I recently delivered a hands-on tutorial at APRICOT 2025 on Blocking Threats at the DNS Layer: Using Response Policy Zones (RPZ) for Threat Detection & Mitigation. Thanks to CISA, DNS RPZ is now widely recognized under the broader umbrella of Protective DNS.

The goal was to introduce the power of DNS RPZ and demonstrate practical ways to deploy a DNS Firewall for blocking and mitigating threats at the DNS layer.

Swapneel Patnekar delivering a tutorial at APRICOT

Figure 1: Swapneel Patnekar delivering a tutorial

While network operators understand the critical nature of DNS infrastructure, few realize that DNS can also serve as a chokepoint—or sinkhole—to disrupt malicious communications.

Aside from the usefulness of DNS RPZ in an enterprise network, DNS RPZ has immense value for a network operator.

Why network operators should leverage DNS RPZ?

One of the persistent challenges for network operators is that IP addresses from their customer networks end up on blocklists. This typically occurs due to malicious traffic (e.g., spam, malware, botnet C2) originating from infected or compromised devices within their network.

The upstream impact of this can be severe:

  • The customer is unable to access a particular website/service on the Internet.
    Web Application firewalls(WAF) deploy blacklisting/threat intelligence to block access to the website/application
  • The Customer is unable to make a payment online
    Fraud detection algorithms at payment deploy blocklist/threat intelligence to block access
  • An enterprise customer is unable to sending and receive email
    IP address assigned to the customer is listed in blocklist database/threat intelligence

A network operator can choose to:

  1. Block DNS queries to known malicious domains, or
  2. Redirect them to a sinkhole for analysis or remediation

This helps contain abuse before it results in IP reputation damage. For large-scale operators, contacting individual customers is not scalable.

⚠️ Important Caveat: DNS RPZ is effective only when the communication uses domain names. It does not block direct IP-based malicious communication.

If you found this blog post useful, you might find APNIC 52 – Threat Hunting using DNS or RPZ Feed list: OSINT Threat Intelligence for DNS Security or Open resolvers in India interesting.

Cybersecurity awareness session at St. Joseph’s Canossian Convent Higher Secondary School

I was tasked with educating bright young minds at St. Joseph’s Canossian Convent Higher Secondary School on the do’s and don’t in terms of cyber security hygiene. As the saying goes, catch them young!

Teaching and explaining Cyber security concepts and best practices to different age groups is a challenging exercise.

From setting unique passwords and enabling 2FA to the dangers of sideloading apps on Google Android phones etc. I covered a lot of ground and had an engaging session with lots of interesting questions.

Photo of Cyber security awareness workshop at St Joseph's Convent School, Belagavi



I am grateful to Sr. Mary Abraham, Principal, St. Joseph’s Canossian Convent Higher Secondary Schooland the PTA members for inviting me and organizing this.and

The event has been covered by The Hindu

If you would like to organize my session at your school/college in Belgaum, please contact me

RBI Cyber Security policy .bank.in and .fin.in

The Reserve Bank of India (RBI) in its latest cyber security policy released on 7th February 2025, has mandated all banks to use .bank.in and non-banks(other financial institutions) to use .fin.in. The goal of the measures is to curb phishing attacks against citizens of India.

RBI Cyber Security policy for banks to use .bank.in and non-banks to use fin.in

Figure 1: Snippet of RBI’s Cybersecurity policy

Notably, Institute for Development and Research in Banking Technology (IDRBT) will be the registrar for the parent domain names (.bank.in and .fin.in)

Technical details

In a DNS context, I am guessing IDRBT would control the parent zones .bank.in and .fin.in and delegate for example icici.bank.in to ICICI Bank authoritative nameservers.

Similarly, zerodha.fin.in would be delegated to Zerodha authoritative nameservers.

IDRBT would be able to control the namespace and delegate child zone to the respective bank or financial institution.

Delegation of DNS namespace from the root to .in and .bank.in and .fin.in

Figure 2: Diagrammatic representation of possible delegation of bank.in and fin.in domain namespace

Limitations of the cyber security policy

In my opinion, this is an excellent move at the policy level from a cybersecurity perspective. There will be operational challenges from the perspective of the banks or financial institutions. I will reserve them for another blog post.

However, this measure will not eliminate all types of phishing/impersonation , typo-squatting or domain shadowing attacks

Despite this, the RBI Cyber Security Policy aims to build trust in the namespace by restricting domain names for banks and non-banks to .bank.in and .fin.in, respectively. From a consumer’s perspective, this simplifies decision-making. As I mentioned earlier, this won’t eliminate all threats, but it is a good start and certainly better than the common advice banks give—checking for the padlock to ensure a website uses HTTPS!

At the time of writing, the delegation from .in at NIXI to IDRBT was not yet operational.

Delegation of bank.in and fin.in not yet implemented in .in namespace at NIXI

Figure 3: Delegation of bank.in and fin.in not yet implemented at NIXI

It is to be noted, that the RBI cyber security policy implementation will start April 2025 onwards.

If you liked this blog post, you might also enjoy reading Jio VoWiFi issue – It’s always DNS! or The curious case of esic.in DNS