How dnsdist Helped Us Reduce Unwanted DNS Traffic by 95%

As a managed hosting provider, DNS is one of the most critical services we run. If DNS becomes overloaded, websites stop loading, email fails, and customers quickly notice.

Over the past year, we observed a significant increase in unwanted DNS traffic hitting our authoritative DNS infrastructure. Much of this traffic wasn’t generated by our customers at all. Instead, it consisted of internet-wide scans, requests for domains we no longer hosted, misconfigured systems and automated bots querying our name servers for information they should never have been asking us for.

While each individual query was harmless, the combined volume was not.

This is the story of how we used dnsdist, alongside PowerDNS, to reduce unwanted DNS traffic by approximately 95%, improve service resilience and gain much greater visibility into what was really happening on our DNS platform.

The Problem

Our DNS servers host authoritative zones for thousands of customer domains.

As we monitored query rates, we noticed a large proportion of traffic was unrelated to any domain we actually managed.

Examples included:

• Requests for domains we had hosted years ago.

• Queries for domains hosted by completely different providers.

• Automated internet scanning activity.

• Misconfigured resolvers repeatedly asking us questions we could never answer.

• Random subdomain enumeration attempts.

From the DNS server’s perspective, every query still had to be processed.

Whilst PowerDNS handled the traffic efficiently, it was consuming resources unnecessarily and making it harder to identify genuine spikes or abuse targeting customer domains.

We wanted a way to:

• Identify and reject irrelevant traffic as early as possible.

• Reduce load on the authoritative servers.

• Improve visibility into attack patterns.

• Create a scalable solution that could be managed centrally.

Why We Chose dnsdist

dnsdist sits in front of PowerDNS and acts as a specialised DNS load balancer and traffic management layer.

Rather than allowing every request to reach the authoritative DNS service, dnsdist can inspect queries first and make policy decisions.

This gave us several advantages:

• Query filtering.

• Traffic shaping.

• Rate limiting.

• Logging and analytics.

• Load balancing.

• Response modification.

Most importantly, it allowed us to decide whether a query was relevant before PowerDNS ever saw it.

Understanding the Traffic

Our first step was visibility.

We enabled query logging within dnsdist and started analysing the results.

Very quickly a pattern emerged.

A substantial percentage of incoming DNS requests were for domains that simply did not exist within our PowerDNS cluster.

The requests fell into several categories:

Former Customer Domains

Domains that had once pointed to our infrastructure but had since moved elsewhere.

Unfortunately, many third-party systems still had our name servers configured or cached.

Internet Background Noise

A surprising amount of DNS traffic comes from automated systems scanning IP ranges looking for open resolvers, vulnerable systems or misconfigured infrastructure.

Misconfigured Services

Some external systems repeatedly queried our servers for zones we had never hosted.

These requests generated continuous NXDOMAIN responses.

Subdomain Enumeration

Automated tools regularly attempt to discover valid hostnames by querying thousands of possible subdomains.

This activity creates unnecessary load without providing any benefit to legitimate customers.

Building a Whitelist Approach

Instead of trying to block every possible bad domain, we chose the opposite strategy.

If a query wasn’t for a zone we host, there was little reason for it to reach PowerDNS.

To achieve this, we generated an authoritative zone whitelist directly from our PowerDNS environment.

The process was automated through Ansible.

Each time the zone list changed:

1. A fresh list of hosted zones was generated.
2. dnsdist configuration files were updated automatically.
3. The updated configuration was deployed to all DNS front-end servers.
4. Validation checks ensured the generated files were correct before deployment.

This meant dnsdist always knew exactly which domains belonged to legitimate customers.

Filtering Unwanted Queries

Once dnsdist had visibility of our authoritative zone list, the logic became extremely simple.

If a query matched one of our hosted zones:

• Pass it to PowerDNS.

If it did not:

• Respond immediately at the dnsdist layer.

The result was dramatic.

The authoritative server no longer wasted resources handling traffic that had nothing to do with customer services.

The Results

After deploying dnsdist in front of our PowerDNS infrastructure and enforcing authoritative zone filtering, we observed approximately a 95% reduction in unwanted DNS traffic reaching our authoritative servers.

The benefits extended beyond the traffic reduction itself.

Lower Load

PowerDNS spent significantly less time handling irrelevant requests.

Better Visibility

Real customer traffic became easier to identify and analyse.

Faster Incident Response

Because background noise had been reduced, unusual traffic patterns stood out much more clearly.

Improved Resilience

Large volumes of irrelevant requests were stopped before they could consume authoritative DNS resources.

Easier Monitoring

Metrics such as query-per-second rates became far more meaningful.

Lessons Learned

One of the biggest surprises was how much DNS traffic had nothing to do with our customers.

Without visibility at the edge, all of that traffic appears to be a DNS workload that needs servicing.

In reality, much of it can be safely discarded long before it reaches the authoritative platform.

dnsdist gave us the tools to make those decisions efficiently and at scale.

Combined with PowerDNS, automation via Ansible and comprehensive monitoring through Zabbix, it has become a key part of how we protect and operate our DNS infrastructure.

Final Thoughts

DNS is often treated as a “set and forget” service, but modern internet traffic patterns suggest otherwise.

As internet scanning, automation and background noise continue to increase, organisations running authoritative DNS services need greater control over what reaches their infrastructure.

For us, deploying dnsdist wasn’t just about performance.

It was about ensuring that our DNS servers spend their time answering questions for customers rather than processing requests that should never have reached them in the first place.

The result was a simpler, cleaner and more resilient DNS platform — with roughly 95% less unwanted traffic reaching the authoritative layer.