root hints vs RFC 8806

An interesting discussion came up at a nerd dinner :-), where, the argument was that a recursive resolver already knows where the root servers are (root hints ) i.e the IPv4 and IPv6 addresses, so then what is the purpose of running a local copy of the root zone in the recursive resolver aka RFC 8806?

What are the root hints?

The root hints are a list of the servers that are authoritative for the root domain “.”, along with their IPv4 and IPv6 addresses. In other words, this is a collection of NS, A, and AAAA records for the root nameservers.
Source

Coming back to the question, to answer this, let’s look at a few assumptions,

  1. The root servers are going to be available at all times
  2. Even if the DNS query is not for a fully qualified domain name(FQDN), send the query to the root aka send junk to the root
  3. Because my recursive resolver knows the IPv4 and IPv6 addresses of the root servers, and, there are local instances of the root servers in the country, the DNS query to the root will hit the local instance

All the above assumptions are the reason recursive resolvers must embrace RFC 8806. For now, let’s focus on the third point because just knowing the IP addresses of the root servers is not enough. Packets need to traverse to the right address.

Aye Aye BGP!

Even if there’s a local root server instance in your country and your recursive resolver knows its IP address (from the root.hints file), the actual query might still transit outside the country due to BGP path selection inefficiencies. Case in point.

All root servers use IP anycast, which means:

  • The same IP address (e.g., for F-root: 192.5.5.241) is announced by multiple physical servers worldwide.
  • BGP determines which instance your resolver talks to, based on routing.

So even if:

  • A root server instance is in your country,
  • Your resolver queries 192.5.5.241 (from root hints),

…it could still be routed to another country, depending on how BGP steers the traffic at that time.

RFC 8806 suggests keeping a local copy of the root zone, which allows the resolver to:

  • Provide the same referrals the root server would give, but from memory/disk instead of waiting for a network response.

A recursive resolver with a local copy of the root zone is shaving off the round-trip time(RTT) to the root servers entirely, thereby eliminating any inefficiency in BGP routing. This may not mean much in low-traffic environments, but if you are an ISP/network operator, shaving even 20–50ms per resolution adds up.

Despite high TTLs on DNS A and AAAA records, a local root zone is especially beneficial during a cold start, when the resolver has no cached data.

Stop sending junk DNS queries to core Internet infrastructure

While it may not be possible to fix all software and ensure full RFC compliance, we can certainly put measures in place to mitigate unwanted or intentional or unintentional abuse of core Internet infrastructure.

An added benefit? It also eliminates junk traffic to the root servers. From a make-the-internet-better perspective, that’s a net win!

If you found this blog post useful, you might find RBI Cyber Security policy .bank.in and .fin.in interesting.

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.

Media and AI workshop to journalists

I was invited by the Department of Information & Public Relations, Belagavi to deliver a workshop on Media and AI to print and new media journalists.

My objective was to demonstrate a few different ways of how I use various AI chatbots and point out some of the issues one needs to be careful about.

Figure 1: Swapneel Patnekar presenting a workshop on Media and AI

Image of presentation agenda, Media and AI

Figure 2 – Agenda of the workshop

OpSec best practices

The first thing that I spoke was about being cognizant of the fact on the information that is shared with the AI chatbot. From an operational security (OpSec) perspective, this is extremely important.

I’ve seen people putting in PII and other sensitive information into the AI chatbot without knowing the implications of it.

Media and AI – Biases, logical fallacies and misinformation

Then, I introduced the journalists to Spinscore. Using AI chatbots, the creation and modification of content is extremely easy, thus, it’s important to separate the facts and the misinformation.

Welcome to SpinScore – an advanced AI tool designed to analyze and score potential biases, logical fallacies, and misleading information in content. Our system uses a combination of state-of-the-art Large Language Models and sophisticated mathematical algorithms to deliver comprehensive insights into the content you explore.

I’ve personally used Spinscore in the past few months and I have found it quite useful to uncover potential biases and incorrect information. I also tend to use it lately with my own writing to find my blind spots, so that I can improve my writing.

I encourage anyone, not just journalists to use this tool to optimize their reading/writing of news on the Internet.

A large focal point of my presentation was spent on using various chatbots for translating text from a link or a video from English to Kannada or Marathi language. If you have used an AI chatbot for translation of text, you will know, it’s not a hundred percent perfect.

I also spent sometime in prompt engineering, explaining the methodology and demonstrating a few use cases to generate content based on topics such as industrial waste, climate change etc.

Self-hosted AI chatbot

And lastly, I showed what a self-hosted LLM using Ollama and OpenWebUI looks like.

Image of presentation slide outlining options for Self-hosted AI Chatbot

Figure 3: Self-hosted AI Chatbot

The benefits of self-hosting and running a local AI chatbot are many.

The workshop gave an exploratory tour of using AI chatbots for translation of text, video and generation of text based using prompt engineering.

My gratitude to the Department of Information & Public Relations, Belagavi for having me.

If you enjoyed reading this blog post, you might find Why I’m rejoining social media 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